【架构】初创团队架构演变历程          返回主页

    本文是在项目中对于架构的演变的一些心得感悟,可能在高手看来有些幼稚,不过确实是在实践的过程中和探索的过程中的个人心得。相信以后会对架构有更为丰富的认识。
                                                                        --写在开头

1.初始阶段:集中式架构

团队初创时需要快速产出产品原型并上线,此时多采用敏捷或半敏捷 方式开发,保证产品本身能够正常运行并能支撑常规的并发访问即 可。因此此时的架构形式多为集中式架构

./架构演变/1.png

架构特点:

优点:集中式,便于管理,紧凑型应用,一个后台面向多个终端,不 必专门面向某一个终端进行开发。只需要在项目内部进行逻辑划分。 手工部署,更容易控制。

缺点:耦合程度过大,单数据库面向多终端,容易出现并发问题。 代码package 过多,长期发展之后不易管理。

单服务器,不容易做到持续集成和持续部署。

不支持热部署。

适合场景:

项目初期的短时间内。


2.发展阶段:逻辑拆分

当访问量到达一定瓶颈,此时单个数据库不足以支撑整个业务逻辑的 发展。

而且应用内部的耦合逻辑也在一定程度上阻碍了传输速度和运行效 率的发展,因此此时应当进行逻辑拆分。在业务上逐步促进业务逻辑 的解耦。

./架构演变/2.png

架构特点:

优点:使用主从库设置,进行读写分离,使得后台压力适度减少。 在业务层对后台中间的逻辑进行适度切分解耦了中间逻辑层。两端能 够适度公用DAO 中间层使得冗余代码得到减少。

缺点:虽然逻辑上已经有分层的体现,但是整个应用架构仍旧是集中 式的单机架构,中间层的分离已经能够抵挡部分的流量压力。但是仍 旧未能解决部署时候需要手动上下线的问题。


3.进阶阶段B:水平拆分,前后端分离

前一阶段的内部分层解决的瓶颈压力不能满足之后的流量压力的时 候。此时应当考虑对应用整体采用水平拆分的操作。

该阶段,后台基本接近完全的服务化,因此需要对WEB 前后端进行 完全的解耦,

./架构演变/3.png

架构特点:

优点:考虑到之前的应用上下线需要依靠手动的方式进行部署,因此 这个阶段可以采用应用的水平拆分,将多个等价应用并列部署,并在 入口位置采用负载均衡服务器,如Apache、Ningx。

通过负载均衡将 流量导向不同的服务器,这样使得服务器整体的抗并发能力提升。

而且在部署的时候能够分阶段分版本进行部署。

缺点:此种方式虽然能够大大的提升应用的抗并发能力及稳定性。

到 这个层次上,服务本身的解耦已经比第一阶段提高很多。

但是仍旧未 能充分使各个端之间达到更为深入的解耦。


4.进阶阶段C:垂直拆分,物理拆分

上一阶段已经能够满足一定程度的并发访问请求,到该阶段,软件内 部的拆分包括优化起到的作用已经达到瓶颈,继续优化已经不足以看 到明显的效果,因此应该进行物理层面的扩充了。

所以引入这个阶段的架构演化,即垂直拆分,物理拆分。

具体而言就是后台剥离具体到业务逻辑,这个可以在之前做,也可以 在该阶段做。

剥离之后,分别以网页后台、手机APP 后台、手机端网页后台分别部 署为集群。而且集群之间应当互相分离,这是从硬件本身的性能所考 虑的。

到这里,数据库应当也已经以单独的服务器所部署了。数据库专门作 为一个单独的服务器供上层应用服务器远程调用。

也就是说,水平上,通过拆分应用分别在不同的服务器中进行集群部 署,垂直上,将数据存储,数据处理分别以不同的服务器部署。达到 垂直的分离。到这里,基本上的架构已经很庞大了。

需要继续完善的有,分布式日志系统,分布式消息队列,分布式集成 以及分阶段测试的演进。

./架构演变/4.png


5.总结:关键词:拆分+解耦

一路下来,应用结构从集中式到水平拆分再到垂直拆分,从内部业务 拆分到物理结构拆分,业务架构从集中式的一站式应用走向了分布式 的应用架构。

总而言之,架构演变的关键,我的理解在于“拆分”+“解耦”

其中,拆分包括逻辑业务的拆分以及物理结构的拆分; 解耦包括业务结构及端与端之间的解耦。

最终,后台将走向服务化,从而使前后端之间的耦合度大大降低, 真正做到了前后端的分离