学习分布式架构感悟

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

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

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

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

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

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