WEB 系统架构演变

最近几年来，随着互联网的飞速发展，软件应用的规模不断增大，需求的激增更是如雨后春笋，同时也带来了技术上的压力。系统的架构也因此在不断的演进、升级、迭代。**微服务（Micro Services）**无疑是最近几年技术圈里非常火热的系统架构解决方案，将服务都切分开来，每一个业务都可以拥有自己的服务边界与生命周期，且各个业务又可以相互协作完成服务。

微服务其实并不是半路“出道”的，而是伴随着 SOA（Service-Oriented Architecture）、CI/CD（持续继承/持续交付）、容器技术、分布式系统等众多技术的百花齐放，自然而然的微服务孕育而生。

对于互联网企业来说，如何应对百万级甚至千万级活跃用户的访问量和并发请求，协调好企业内部各部门负责的应用进行协同研发，可以快速的应对系统业务的变化和拓展成为了尤为重要的问题。

当网站 QPS(Queries-per-second) 数值不高时，将所有功能都部署在单一应用即可，这样可以有效减少部署节点与难度也大大降低了成本。此时，敏捷开发框架就成为了影响项目研发的关键了。如下图所示：

通过对集中式架构的描述并结合上图可以总结出集中式应用架构存在的诟病如下：

代码间耦合成度高，导致维护困难。不便针对不同模块进行针对性优化。水平扩展困难。并发能力几乎没有，同时单点的容错率极低。 垂直拆分

当网站 QPS 逐渐增大，单一架构的应用无法满足业务与用户体验，此时为了应对更高的 QPS 和复杂业务场景，需要让应用根据业务功能进行拆分。垂直拆分架构大致如下图所示：

垂直拆分架构相比集中式架构进行对比可以看出明显的变化，因此可以看出垂直拆分架构具备了哪些优点与缺点：

优点

系统拆分后解决了部分并发问题，也实现了流量的分担。可以针对性的对不同的模块进行优化处理。提升了应用的容错率、水平扩展性，可以做负载均衡。 缺点

系统间过于相互独立，会带来很多重复的开发工作，影响研发周期。 分布式服务

当垂直应用随着业务的拓展与迭代与日俱增时，系统之间互相调用开始不可避免，需要将核心业务逻辑封装出来，作为独立的公共服务，逐步形成稳定的服务中心，可以让前端应用能达到更迅速的响应去面对多变的市场需求。此时，提高业务复用率及整合的分布式协作调用是关键。分布式服务大致如下图所示：

分布式分架构在垂直拆分架构上带来的优势：将基础服务进行了独立封装，应用间相互协作调用，提高了代码复用率和缩短了研发周期。事物往往都存在“两面性”，从上图可以看出分布式架构带来了应用间耦合度升高，协作调用关系盘根错节，逐步提升了维护难度。

当服务开始盘根错节，服务容量的评估、小服务闲置服务器资源分配等问题暴露出来，此时需增加一个调度中心服务基于访问 QPS 实时进行监控集群容量，提升集群的利用率。在这些环境的压力下，用于提高机器利用率的资源分配和治理中心(SOA)是关键。治理中心与服务资源调度关系可以用下图来绘述：

到这儿，可以先看看从集中式架构到分布式服务演进过程中经历了哪些问题？首先，产生的服务蜂拥而至，需要管理每个服务的地址；其次，调用关系盘根错节，依赖关系难以理清；最后，难以管理服务状态，无法动态管理服务情况。这些诟病的层层暴露也就引出了服务治理。服务治理在应用中扮演什么样的角色？首先，注册中心实现了自动注册服务和自动发现服务，不再需要人为记录与监控服务地址以及服务状态；其次，自动订阅服务、自动推送服务列表、透明化服务之间协作等等不再花费过多的成本去处理依赖关系；最后，服务状态监控报告动态生成，服务状态可以人为控制。

从上图可以分析出服务治理带来了一些问题：

服务间产生了相互依赖关系，某个环节出错可能会带来雪崩效应。服务关系盘根错节，测试、部署运维与困难，不符合 DevOps 思想。 微服务

上一小节阐述的服务治理，英文直译为面向服务。微服务，字面意思似乎也是服务，其实都是进行拆分系统。所以两者容易混淆，但其实从下图与下表的服务治理（SOA）与微服务对比图中可以清晰的看出确实是有一些差别：

通过与服务治理（SOA）的比较可以看出微服务的所包含特性：

单一职责：微服务的所有服务都具备单一职责的业务能力。微：微服务可拆分粒度极小。面向服务：面向服务指每个服务都可以向外提供API。不要求服务的实现技术，只需提供Rest接口交互即可。自治：服务间可以“自扫门前雪”：

团队独立：所有服务都可以是独立的研发团队。技术独立：采用Rest接口交互。前后端分离：后端可与不再为PC、移动端开发不同接口。数据库分离：所有服务可以独立管理数据源。部署独立：可以做到服务重启不影响其它服务。有利于CI/CD。