分布式架构的演变过程

我们都知道一个大型成熟网站的系统架构并非一开始就设计得非常完美，而是随着用户量的增加、业务量的扩展逐渐完善的。随着社会的发展，我们对系统的高性能、高并发、高可用、安全性等特性提出了更高的要求，分布式架构便成了当下最火的架构。接下来我们就来聊聊分布式架构的演变过程。

单应用架构

早期的系统大部分都是单应用架构，所有的模块集成在一个应用里面，只需要一台应用服务器和一台数据库服务器，随着访问量的增加，服务器负载的慢慢提高，解决性能瓶颈的方案是不断提高服务器的配置。

应用服务器集群

随着访问量的继续增加，单台应用服务器已经无法满足需求，假设我们的数据库服务器还没遇到性能问题，我们可以通过增加应用服务器的方式来将应用服务器集群化，这样用户可以分流到各个应用服务器中，从而达到提升系统负载能力的目的。

但是应用服务器集群会带来的问题：

1. 用户请求如何分流到各个应用服务器？
2. 用户如果的两次请求被分配到不同的服务器，如果做到session共享？

为了解决第1个问题，需要在用户请求和应用服务器中间增加负载均衡，负载均衡分硬负载和软负载，硬负载可以选择F5等，软负载可以选择nginx、Apache等，增加了负载均衡后系统架构便变成下面这样。

而第2个关于session共享问题，我们可以通过配置tomcat的session共享或者缓存服务器来实现。

数据库读写分离

应用服务器集群提升了应用层的负载能力，但是数据库的负载能力并没有得到提升，那如何去提高数据库的负载能力呢？是不是也能参照应用服务器集群的方式，通过增加数据库服务器来实现呢？数据库读写分离被提了出来：

同样读写分离也会带来新的问题：

1. 主库如何及时将数据同步到读库
2. 应用服务器如何知道要调用哪个数据源

针对第1个问题，各数据库都提供了主从复制的解决方案，如mysql自带master-slave方式实现主从复制。

针对第2个问题，可以使用多数据源或者引入第三方数据库中间件，例如mycat。

缓存技术引入

随着访问量的持续增加，会出现许多用户访问统一内容的情况，对于这些数据，没必要每次都去数据库获取，这个时候引入应用层的缓存技术是个很好的选择，例如redis、memcache等。

应用拆分

随着业务的继续发展，应用的压力再次增大，同时不断增加的模块使系统变得越来越臃肿，维护工作量也越来越大。这个时候就可以考虑将应用系统进行拆分，按照领域模型拆分成多个子系统。

应用拆分后会带来新的问题，如子系统一中的一个查询在子系统二中也需要查询，是不是这些查询在两个子系统中都分别写一套呢？当然是不行的，一定要把这些抽象出来做成一个服务，这样又生成一个新的问题，多个子系统之间怎么相互访问呢？为了解决这个问题，RPC技术是个很好的选择，比较典型的有：dubbo、webservice、hessian、http、rmi等。

数据库垂直拆分

同样的，应用层面性能瓶颈解决后，又轮到数据库了，我们能将应用按照领域模型拆分成一个个应用子系统，数据库也是一样，根据不同的业务拆分成不用的数据库。拆分后数据库可以和拆分后的应用一一对应。

数据库水平拆分

数据库进行读写分离、垂直拆分后基本上解决了负载的问题，但是随着业务量的增加，表的数据不断增长，数据查询性能便成了问题，所以必须要多数据库进行水平拆分。水平拆分是将单个表的数据拆分到多个数据库中，如1亿数据的表拆分到10个数据库后，每个表就只有1000w了。

数据库水平拆分后，数据源就变得非常复杂了，让业务系统去控制查询哪个数据源变得不现实，这个时候需要引入第三方的数据库中间件，例如mycat、阿里的drds等。

最后演变出来的便是上图这个相对比较全的分布式架构了，但并不是说最后这个分布式架构一定是最优解决方案，具体选择哪个架构还是要结合业务系统的业务需求和业务量来分析。