架构演进

原文：https://www.cnblogs.com/hafiz/p/9222973.html（可学习其他文章）

阶段一：单应用架构

阶段二：应用服务器和数据库服务器分离

大大减少了网站宕机的风险。

阶段三：应用服务器集群

将用户请求分流到各个服务器中，从而达到继续提升系统负载能力的目的。此时各个应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。

新问题：

• 用户请求交由谁来转发到具体的应用服务器上(谁来负责负载均衡)

• 用户如果每次访问到的服务器不一样，那么如何维护

  session，达到session共享的目的。
  方案：负载均衡又可以分为软负载和硬负载。软负载我们可以选择Nginx、Apache等，硬负载我们可以选择F5等。而session共享问题我们可以通过配置tomcat的session共享解决。

阶段四：数据库压力变大，数据库读写分离

提高数据库层面的性能

• 主从数据库之间的数据需要同步(可以使用 mysql 自带的 master-slave 方式实现主从复制 )
• 应用中需要根据业务进行对应数据源的选择( 采用第三方数据库中间件，例如 mycat )

阶段五：使用搜索引擎缓解读库的压力

搜索引擎能够大大提升我们系统的查询速度，但同时也会带来一 些附加的问题，比如维护索引的构建、数据同步到搜索引擎等。

阶段六：引入缓存机制缓解数据库的压力

热点数据，没必要每次都从数据库重读取，这时我们可以使用到缓存技术，比如 redis、memcache 来作为我们应用层的缓存。另外在某些场景下，如我们对用户的某些 IP 的访问频率做限制， 那这个放内存中就又不合适，放数据库又太麻烦了，那这个时候可以使用 Nosql 的方式比如 mongDB 来代替传统的关系型数据库。

阶段七：数据库的水平/垂直拆分

交易、商品、用户的数据都还在同一 个数据库中，尽管采取了增加缓存，读写分离的方式，但是随着数 据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我 们可以考虑对数据的垂直拆分和水平拆分。

垂直拆分:把数据库中不同业务数据拆分到不同的数据库。

水平拆分:把同一个表中的数据拆分到两个甚至更多的数据库中，水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈，这时可以采取将表拆分到多个数据库中。

阶段八：应用的拆分

拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来，否则就是一个坑。所以通过走服务化路线的方式来解决。

服务拆分以后，各个服务之间如何进行远程通信呢? 通过 RPC 技术，比较典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通过这些技术能够很好的解决各个服务之间通信问题，但是， 互联网的发展是持续的，所以架构的演变和优化也还在持续。

总结：大致的系统优惠方案如上，推荐画架构图工具：VISIO

附上一个好的文章：https://blog.csdn.net/everythingss/article/details/78749247