今天开始写一个新的系列的文章,就是围绕着分布式系统说说它的技术栈、实现思路和问题挑战等等。这个内容不是很好写,太大太广,而且在技术日新月异的今天它也在不断发展探索更好的实现。我只能尽我所知,尽可能把这部分内容整理汇总在这里。我也不清楚什么时候可以整理完,但是会尽快。
发展历程
在一个网站发展初期,访问量和数据量还没有上升到一定的量级之前,系统都是以一个单体应用(比如一个war包)形式部署在tomcat的。据说在2003年淘宝最初上线的时候,就是以一套以当时十分风靡的LAMP架构(Linux+Apache+MySQL+PHP)实现并部署的。单体应用架构的特点就是功能和代码集中、一个发布包部署后运行在一个进程内的应用程序。
需要注意的一点时,单体应用内部可能也实现了我们常说的分层的概念,比如MVC(Modal-View-Controllor)。此时其实分层的概念只是实现了逻辑上的分层,也就是说不论是web层、service层还是dao层,代码依然是部署在一起的。所以说分层只是说是对于一个系统来说只是一种逻辑上的水平划分。
后期当业务发展,网站的访问量上升后,由于单个应用上的并发访问瓶颈,可能会导致系统响应速度下降甚至无响应。此时就需要对系统做一些升级以支撑高访问量,此时有两种方案可考虑:
1.垂直拓展
砸钱上更NB的服务器,提升性能;
2.水平拓展
将单体应用部署更改为集群部署,并根据情况增减节点;
一般情况下都会选择第二个方案进行拓展,但注意此时的集群还是单体应用的集群。而单体应用说穿了,仍然是一个单进程的应用,也就是说应用内所有的业务操作(可以理解为线程)都共享这个进程的资源和内存空间,如果业务量进一步急剧上升,那么单纯地靠集群扩容也将很难去解决问题。
这个时候,我们就需要将这个单体应用拆分成多个应用,多个应用(集群)协同提供服务。系统拆分的维度有如下的总结:第一是系统维度,也就是简单地按业务边界去拆分;第二是功能维度,对一个业务内的不同功能进行拆分;第三是读写维度,进行读写的分离;第四是模块维度,对已经拆分的模块再按MVC分层部署。