学习分布式架构感悟
学习分布式架构感悟
luoxiaojun1992 发表于2年前
学习分布式架构感悟
  • 发表于 2年前
  • 阅读 2205
  • 收藏 170
  • 点赞 8
  • 评论 13

标题:腾讯云 新注册用户域名抢购1元起>>>   

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

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

本文从大致三个方面谈谈分布式架构的概念、原理和相关的解决方案。为什么要做分布式?举个栗子,就好比原来城市的道路是双车道,同一时间只能容纳很小一部分车流量,但是改成多车道后,道路的容量就提升了几倍,网站也是相同的道理,用户的访问请求就是汽车,分布式架构就是在构建一个多车道的网站系统。接下来我们具体聊一聊各个层面的分布式技术解决方案。首先讲业务层的分布式,最简单的就是部署几台业务服务器,部署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等技术的分布式解决方案。

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

 

共有 人打赏支持
粉丝 9
博文 12
码字总数 7745
评论 (13)
DavidWho
79说得很清晰,不涉及具体业务的架构思想,验证了很多自己的想法
成长中的小白
挺好,普及了一下这方面的知识,赞
hyx216
写得太好了,收获很多,大赞79
GuoYJ
普及了很多知识79
baozhuni
空谈误国,实干兴邦
tomener
写的深入点更好
zcoder
感谢分享 赞一个
小虫0302

引用来自“DavidWho”的评论

79说得很清晰,不涉及具体业务的架构思想,验证了很多自己的想法
haha
51pansou
写的赞
commonum
牛逼逼!
ericsoul
多车道的距离不够贴切,加油站,收费站等都比多车道的举例要好
ivxivx1234
按列的拆分是垂直拆分
luoxiaojun1992

引用来自“ivxivx1234”的评论

按列的拆分是垂直拆分
多谢,已更正!
×
luoxiaojun1992
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: