随着公司业务规模的扩大，网站访问量日益剧增，最初的系统架构可能已经没办法满足业务发展的需求了。这时候就要考虑将系统架构改造成扩展性更强，能够承受更大访问量的分布式架构。

本文从大致三个方面谈谈分布式架构的概念、原理和相关的解决方案。为什么要做分布式？举个栗子，就好比原来城市的道路是双车道，同一时间只能容纳很小一部分车流量，但是改成多车道后，道路的容量就提升了几倍，网站也是相同的道理，用户的访问请求就是汽车，分布式架构就是在构建一个多车道的网站系统。接下来我们具体聊一聊各个层面的分布式技术解决方案。首先讲业务层的分布式，最简单的就是部署几台业务服务器，部署Apache或者Nginx，配置相同（vhost、域名解析、代码目录等），然后使用负载均衡技术将这几台服务器组成集群，达到对用户分流的效果。需要注意的是SESSION会话需要保存到数据库或者缓存系统中，保证SESSION的一致性，至于数据库，有统一的数据层，不需要担心数据不一致的问题。负载均衡有很多种解决方案，比较常见的是LVS（阿里巴巴章文嵩博士开发）、Nginx（阿里巴巴优化的Tengine）、HAProxy等。LVS是负责在4层网络实现负载均衡，有DR、隧道等方式，可以根据自身需求选择合适的方式。Nginx和HAProxy是负责7层网络的负载均衡，可以和LVS配合组成一套覆盖4层和7层网络的负载均衡解决方案。当然还可以配合Keepalived和Heartbeat等技术实现对后端业务服务器的健康检查，对出现故障的服务器，可以及时从集群中剔除，保证整个系统的高可用。如果还是不能满足流量的需求，还可以考虑在业务层的负载均衡之前再部署一套代理缓存服务器（Varnish、Squid等），代理缓存服务器也可以实现负载均衡，方法与业务服务器相同。

接下来谈谈服务层的分布式，与服务层相关的技术也有很多，比如SOA、Docker、Webservice、RPC、SOAP、消息队列（ActiveMQ、RabbitMQ、ZeroMQ、Kafka、Redis等）等，实现服务层的目的是降低系统的耦合度，便于扩展和维护，在必要时还可以降级提供服务，保证系统的高可用，提高系统的可靠性。目前比较流行的是Docker技术，许多互联网大厂，例如阿里巴巴、新浪云、网易云、灵雀云等都推出了基于Docker的云服务，没有推出Docker服务的也都在研发或者计划研发。网上关于Docker实现微服务的技术文章也有很多（Mesos、Kubernetes等），这里就不在赘述了。这些服务层技术都有各自内置的分布式解决方案可供选择，这里就不在详细展开论述了。

最后谈谈数据层的分布式，数据库可以简单地分为关系型数据库（SQL型）和非关系型数据库（NoSQL型）。最常用的关系型数据库是MySQL。MySQL的分布式技术有主从复制、分库分表等等。数据库的主从就是部署一台主数据库和若干台从数据库（具体数量可以根据业务需求决定），从数据库利用主数据库的bin日志同步数据，主数据库可以提供读写服务，从数据库只提供读的服务。但是，主从并不能缓解数据库的写入压力，可以采用分库分表的技术。分库指将数据库拆分几个小数据库（根据业务模块划分，比如订单模块、评论模块、购物车模块等），当然业务层也需要配合做调整才行。分表就更复杂一些，要对数据表做水平拆分，比如会员表member有id、name、age、mobile、sex等字段，比如可以拆分成member1（id、name、age）和member2（id、mobile、sex），当然拆分方式和数量也需要根据实际的业务需求决定。由于数据表的拆分，会使业务层的逻辑变得十分复杂，因此一般采用MySQL分布式代理中间件，来完成对查询语句的适配，降低业务层的复杂度。比如Corbar是阿里巴巴开源的兼容MySQL协议的分布式数据库中间件，但是遇到join、group等查询时不能实现跨表。除此以外，也可以采用同城双活、异地多活等技术实现容灾备份。除了MySQL，还有MongoDB、Redis、Memcache等非关系型数据库。MongoDB有内置的分布式解决方案，比如主从（不推荐）、sharding和副本集，主副本集挂了，会自动选举新的主福本集，可以通过设置W和J参数保证数据的一致性和完整性。Redis本身也有内置的主从方案，类似MySQL的主从，也有豌豆荚公司开源的Codis数据库中间件，可以根据需要选用。Memcache本身不支持分布式，但是可以通过一些中间件，比如PHP的Memcached扩展（与Memcache扩展不同），或者自己用一致性hash算法实现。

除了后端的分布式技术，还有与前端相关的单个CDN、对象存储、块存储、多CDN等等技术。涉及到大数据，还有Hadoop、HDFS、Spark、Storm等技术的分布式解决方案。

总结一下，没有最完美的分布式结构，架构设计必须从业务需求出发，逐步演进，不断调整。但是遵循一些经验规律，可以为今后的扩展打下坚实的基础。在必要时可以选用云服务来降低架构实现的难度，也可以省去一部分研发和运维成本，专注于自己的核心业务系统的研发。最后声明，本人水平有限，请勿吐槽，如有建议，欢迎交流，如有雷同，纯属巧合。