分布式系统漫谈【壹】_发展历程

今天开始写一个新的系列的文章，就是围绕着分布式系统说说它的技术栈、实现思路和问题挑战等等。这个内容不是很好写，太大太广，而且在技术日新月异的今天它也在不断发展探索更好的实现。我只能尽我所知，尽可能把这部分内容整理汇总在这里。我也不清楚什么时候可以整理完，但是会尽快。

发展历程

在一个网站发展初期，访问量和数据量还没有上升到一定的量级之前，系统都是以一个单体应用(比如一个war包)形式部署在tomcat的。据说在2003年淘宝最初上线的时候，就是以一套以当时十分风靡的LAMP架构(Linux+Apache+MySQL+PHP)实现并部署的。单体应用架构的特点就是功能和代码集中、一个发布包部署后运行在一个进程内的应用程序。

需要注意的一点时，单体应用内部可能也实现了我们常说的分层的概念，比如MVC(Modal-View-Controllor)。此时其实分层的概念只是实现了逻辑上的分层，也就是说不论是web层、service层还是dao层，代码依然是部署在一起的。所以说分层只是说是对于一个系统来说只是一种逻辑上的水平划分。

后期当业务发展，网站的访问量上升后，由于单个应用上的并发访问瓶颈，可能会导致系统响应速度下降甚至无响应。此时就需要对系统做一些升级以支撑高访问量，此时有两种方案可考虑：



1.垂直拓展

砸钱上更NB的服务器，提升性能；

2.水平拓展

将单体应用部署更改为集群部署，并根据情况增减节点；

一般情况下都会选择第二个方案进行拓展，但注意此时的集群还是单体应用的集群。而单体应用说穿了，仍然是一个单进程的应用，也就是说应用内所有的业务操作(可以理解为线程)都共享这个进程的资源和内存空间，如果业务量进一步急剧上升，那么单纯地靠集群扩容也将很难去解决问题。

这个时候，我们就需要将这个单体应用拆分成多个应用，多个应用(集群)协同提供服务。系统拆分的维度有如下的总结：第一是系统维度，也就是简单地按业务边界去拆分；第二是功能维度，对一个业务内的不同功能进行拆分；第三是读写维度，进行读写的分离；第四是模块维度，对已经拆分的模块再按MVC分层部署。

以上的拆分维度不一定需要完全实现，可以根据具体业务量和实际情况进行处理。当系统走到这一步的时候，我们可以说这已经是一个分布式系统了。可以总结出，所谓分布式就是将不同模块部署在不同的服务器上，通过远程调用协同工作。

继续优化

以上是我们将一个单体应用逐渐去拆分成了一个分布式应用的过程，也是我们队应用部署层面的一个优化。那么当业务不断发展，用户量上升到新的一个层级的时候，为了解决高并发访问、海量数据存储、高可靠运行等问题，我们可能还需要进一步从如下方面进行优化：

动静分离

对于业务加载需要的一些不经常改变的静态数据，可考虑将其缓存到CDN服务器上而不是每次都到我们的应用服务器进行获取，这样可以减少服务器的压力。CDN(内容分发网络) 是运营商提供的服务，服务器部署在机房，可以根据用户访问的链路直接选择最近的CDN服务器将已缓存的静态数据返回，加快静态数据加载速度。

负载均衡

体现在两个方面，一是用户对服务器的请求均衡，二是服务器与服务器之间的调用请求均衡。可通过轮询、加权或指定规则将请求平均地分散到每台服务器上。

分库分表

数据量进一步增多，当单库已经成为数据访问或操作的性能瓶颈的时候，我们就需要对数据进行分库分表操作。分库就是依据不同业务，将不同的业务数据保存到不同的业务数据库中；分表就是，当统一业务数据表(比如订单表)数据量巨大单标无法承受的时候，就将其按照一定规则拆分为多个同构的表分散存储。

缓存

对于一些经常访问的热点数据(读多写少)，就不适合每次都从数据库进行获取，一来是速度慢，二来是消耗数据库链接资源。进行读写缓存后，可显著提升数据读写速度。缓存可以分为本机缓存和分布式缓存。

异步

将一个复杂的业务操作转换为多个阶段操作，每个阶段的操作通过消息队列进行异步处理。可以理解为生产者-消费者模式，好处是加快系统响应速度和消除并发高峰(消峰)。

冗余

为抵抗一些不可控因素，如自然灾害(火灾、地震)等因素导致系统不可用，应考虑异地建立容灾中心，数据实时备份，可参考阿里提出的“两地三中心”概念。

自动化

让系统在无人值守的情况下仍可以正常运行。自动化包括监控、告警、失效转移恢复、降级等功能。

分布式系统的优点

性能提升

相比单体应用而言可以支撑更高的并发访问

技术异构

每个服务的技术实现可以不同，只要约定好相互的调用接口即可；

弹性扩展

根据业务需要可以灵活地上线下线集群内的节点；

简化部署

节点间部署互不影响

当然，凡事有利也有弊，我们使用分布式系统也会引入一些单体系统没有的问题，下文中我们将详细探讨。