学习分布式架构感悟

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

本文从大体三个方面谈谈分布式架构的概念、原理和相关的解决方案。为何要作分布式？举个栗子，就比如原来城市的道路是双车道，同一时间只能容纳很小一部分车流量，可是改为多车道后，道路的容量就提高了几倍，网站也是相同的道理，用户的访问请求就是汽车，分布式架构就是在构建一个多车道的网站系统。接下来咱们具体聊一聊各个层面的分布式技术解决方案。首先讲业务层的分布式，最简单的就是部署几台业务服务器，部署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分布式代理中间件，来完成对查询语句的适配，下降业务层的复杂度。好比Cobar是阿里巴巴开源的兼容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等技术的分布式解决方案。

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