1. 单机架构
只有一台机器，这个机器负责所有的工作
（这里假定一个电商网站）
现在大部分公司的产品都是单机架构 。
2. 分布式架构
一台机器的硬件资源是有限的，服务器处理请求是需要占用硬件资源的，如果业务增长，用户量和数据量变多，一台机器可能会出现难以应对的情况，要解决这种情况要么优化软件，找到性能平均做优化，要么就引入更多的硬件资源，也就是加机器，引入多个主机的系统就称为分布式系统。
2.1 应用服务与数据库服务分离
应用服务器需要处理很多的业务请求，那么就更需要CPU和内存资源，数据库服务器则更侧重硬盘的大小和读写速度，由此就可以更具用途来定制机器达到更高的性价比。
2.2 引入更多的应用服务器
如果请求数量过多，那么应用服务器可能还是会撑不住，此时可以引入更多的应用服务器来处理请求：
这里还引入了负载均衡来根据服务器的负载清理来分发请求：
负载均衡算法一般单独运行在一个服务器上用于接收请求并分发给应用服务器。
**注意：**负载均衡只负责请求的分配并不会处理请求所以资源消耗是比较小的，不用过于担心性能问题。如果请求真的多到负载均衡器压力过大也可以引入多个负载均衡器。
2.3 读写分离
在上面的情况里，如果请求数增多了，那么通常对数据库的操作也会更频繁，就可能导致数据库服务器成为性能瓶颈。
在实际的应用场景下，读的频率是要比写的频率高得多的， 于是可以引入多个数据库服务器，一个主数据库，用于处理写操作，多个从数据库用于处理读操作（这里也可以通过负载均衡的方式管理从数据库的访问），从数据库会在合适的时机再去同步主数据库中的数据：
2.4 引入缓存
由于数据库是把数据放在硬盘中，所以对数据库的操作都是较慢的。但在实际情况中，并不是所有的数据都会被频繁的访问，一小部分的热点数据，通常可以支持大多数请求，所有可以引入一个缓存服务器，把一些访问频繁的数据放在缓存中，就可以大大提高平均响应速度（可以使用Redis）
2.5 分库分表
用户量过多也会导致数据量过大，大到一个服务器存不下，就可以通过对数据库进行拆分，通过多个主机来存储：
这里的存储集群即上面的主从数据库服务器共同组成 ，每个集群包含了对应表的主数据库服务器和从数据库服务器。
如果某个表特别大，也可以对表进行拆分。不过具体的分库分表要根据实际的业务来决定。
3. 微服务架构
在上面的架构模式中，关于用户信息的请求，商品的请求，订单的请求，都是由同一种服务器做的，随着业务需求增多，代码会变得越来越复杂，为了更方便代码的维护，就可以把这样一种复杂的服务程序拆分为多个功能不同的服务器，这种架构就叫做微服务：
引入微服务可以更方便的组织人员对代码进行管理，以及功能的复用， 但是确大大提高了系统的复杂程度，也就更容易引发问题，同时系统之间依赖网络通信，可能会造成性能下降。