0. 前言

时至今日微服务架构已经成为了互联网公司的标配，好像如果你不采用微服务架构，你都不好意思说自己是互联网公司。但是一说到微服务架构，大多数人联想到的都是微服务框架、RPC远程调用协议、服务发现、服务治理、服务监控、网关、限流、熔断、分布式事务解决方案等一系列技术术语。但是微服务的本质是什么？微服务要解决什么问题？微服务架构如何落地？以上的问题似乎不是靠一大堆中间件和框架就能回答的。下面我就这些问题聊一聊自己的理解。



1. 互联网架构的演化

任何一个的架构模式都不是平白无故的出现的，他的出现一定是为解决某一个问题而逐步演化过来的。接下来我们就来将时间倒退，看一下互联网架构的演化的过程。



1.1 单体应用架构

十几年前各大网站几乎都单体应用架构，整个网站的工程都打成一个大包部署在web容器中，web容器部署在多台机器上，实现一个集群统一对外提供服务。





随着业务不断进行，架构的缺点逐渐暴露：

• 技术扩展性：

• 打包编译困难：工程越来越大，打包编译时间越来越长，工作效率越来越低。

• 版本管理困难：多个团队、分支冲突越来越多，光是合并代码就需要耗费大量的时间。

• 发版上线困难：代码耦合在一起，上线时无论影响范围，都需要各个团队开发人员参与待命。

• 无法针对性性能优化：代码全部耦合在一起且都部署与同一台机器上，无论软件层面的调优或硬件层面的调优都变得机器困难

• 业务扩展性：

• 业务推进缓慢，新增功能困难：正式因为以上技术扩展性问题，导致团队整体开发效率急剧下降，而且通过添加人员无法解决这种问题。

单体应用架构导致团队效率下降，无法支撑快速变化的市场需求。既然单体应用因为工程复杂庞大和代码耦合造成诸多问题，我们很自然的想到应用分而治之的思想，对工程进行拆分，于是乎诞生了分布式架构。



1.2 分布式架构

解决复杂问题最好的方式就是拆分，对于一个复杂的系统也是如此。

分布式架构就是将原先复杂的大工程拆分为一个个小工程中，拆分后的工程由相互独立的团队开发，部署在不同的机器上，这样从需求分析、设计、开发、测试、上线、部署、运维等系统的各个生命阶段都是解耦的，既降低了工程的复杂程度，又解决了技术、业务扩展性性问题。

通常分布式服务拆分的依据按照产品线或业务模块进行纵向拆分。



如上图采用纵向拆分后的系统像一个个烟囱一样，人们给这样的系统起了一个形象的名字就叫“烟囱系统”，“烟囱系统”由于拆分粒度比较大，会产生如下问题：

• 每个应用都是从头到尾，自搭一套完整的体系，导致业务之间重复造轮子，造成资源浪费

• 各个应用数据相对集中且对外的服务和接口不完善，容易造成应用系统间东西向集成困难，产生信息孤岛

为了解决以上问题，我们还是使用分而治之的概念，衍生出SOA即面向服务架构。



1.3 SOA——面向服务

分布式架构采用面向业务线纵向对系统进行拆分，但是拆分后的应用系统间一定会依赖共同的服务，所以我们采用横向分层的方式对系统进一步拆分，将公共的服务拆分出来为上层应用提供能力支撑。



SOA架构的优点：

• 业务封装：通过服务化思想，提供更好的业务封装性，并通过标准技术，能更友好地对外输出业务能力

• 业务独立：SOA 服务不依附于某个具体应用，它可以独立地部署和扩展，这样避免了直接影响现有的系统

• 业务共享：服务通过封装通用的业务逻辑，可以供所有应用共享，解决了重复造轮子的问题



1.3 微服务架构

我们通过分布式架构解决了业务耦合的问题，通过SOA解决了服务耦合的问题，微服务架构解决什么问题或者说给我们带来了什么好处呢？

微服务重点在一个“微”上，它可以有两种含义，一种是“小”——小服务，另一种是“简单”——简单的服务：

• 小服务+小应用

经过我们上面的一横一纵两次拆分，系统已经构成了上层应用和底层服务的网格状架构。但是随着业务的进步增长，原先的“格子”可能会越来越臃肿，此时需要进一步的拆分重构。将服务和应用拆分的更细，不在以产品或业务维度，而是以模块或功能维度进行拆分。目的是为了将服务的职责进一步精细哈，单一化，简单化

• 简单的技术实现手段

微服务更加强调简单的轻量级的实现方式，例如简单的网络协议依赖（通常HTTP），高效的消息传输格式（JSON）。目的也是尽量降低微服务实现和使用的成本。





所以从本质上说的微服务架构并没有引入新的概念，而是对分布式架构中服务拆分粒度和技术实现提出落地指导原则。这些原则的根本目的就是打造一个快速支持业务，容易扩展的分布式系统架构。



2. 微服务架构评判标准

在说这个问题之前，我们还要说一下微服务中间件。在系统设计之初，大家的关注点都在各种中间件的实现原理，性能比较和使用方法优劣上。好像只要选对了一款中间件，系统就成功了大半。

什么是中间件？

简单说中间件只是一种工具。系统分布式之后，原来的本地调用模式变成远程调用模式，无形中增加了系统实现的复杂性。分布式中间件就是解决这种复杂性，让调用远程方法像调用本地方法一样简单的技术手段。中间件只是为了简化开发工作而已。有了中间件程序员可以更加关注业务而无需关注技术实现细节。

微服务评判标准

对于一个微服务系统衡量标准，不是系统采用什么先进的技术，也不是系统的性能如何，能支持多少并发用户。当然这些很重要，但不是最重要的。

一个微服务系统最重要的是，系统当前能支持现有业务，能带来收益。系统未来能方便扩展，持续带来收益。而要满足这个目标，微服务系统服务的拆分和关系至关重要。这也是微服务架构落地的难点。

微服务架构的指导思想只告诉我们服务粒度要尽量小，但是具体的维度标准，拆分依据都没有明确，因为这些其实是高度依赖于我们自身业务的。但是在纷繁的业务中有没有更加通用的指导性方法？DDD（领域驱动设计）可以给我们一些建议。



3. 关于DDD（领域驱动设计）的一些理解和思考

DDD本身是一个比较庞大的领域，这里只讲一下我自己的理解。

3.1 DDD是什么？

DDD其实就是面向对象设计的指导方针和领域模型编程的落地指导原则。面向对象的编程方式这么多年都不流行和他本身的落地复杂性有很大的关系。即使有了DDD这样一套思想加持，想要完成落地也是有一定实现难度的。但是DDD中关于面向对象设计的一些思路可以作为我们系统领域设计和服务拆分的最佳实践，这部分就是DDD中的额战略设计过程。



3.2 DDD如何指导系统设计？

业务是高度不一致的，每个人面对的业务都不尽相同的，DDD也不可能告诉我们具体业务是什么，如何划分领域模型。DDD只是告诉如何去做，告诉我们分析方法。那DDD如何指导我们分析系统呢？它有两点要求：

3.2.1 专家参与

DDD非常重视领域专家，希望系统设计之初就引入领域专家（或各种熟悉业务的人员）和软件开发人员一起参与到软件的设计工作来。程序员不能在闭门造成，按照自己对业务的理解设计系统、开发系统。他们要想领域专家请教，要和领域专家沟通，要将自己的设计成果及时和专家反馈。这样的一种方式可以最大限度的避免领域系统的设计偏差，保证系统完全服务业务需求。

3.2.2 统一思想

光让专家参与进来只是第一步，更重要的是要和专家或各放干系人就业务达成统一的思想。我们在什么上统一思想呢？

DDD就系统中设计的各个方面定义了一些概念：领域，子域，界限上下文，上下文映射图，实体、值对象、模块等。我们需要将系统映射到这些概念中，并未每一个概念起一个大家都达成一致的名字，此为统一语言。统一语言之后我们就可以就系统中这些概念的具体含义在各方充分讨论的基础上达成思想一致，例如：我们是做什么？我们的业务范围是什么？系统中有哪些子系统？分别是做什么的？系统中的子系统在哪些语境中成立？子系统间依赖关系如何？系统有哪些领域实体构成？这些实体都有哪些属性？哪些职责？系统可以分为哪些模块？这些模块有什么职责？

这里的关键点有三点：

• 现实对应：设计中名词和概念都是源于实际业务

• 充分讨论：讨论过程中可以将各放意见统一聚合，让各方充分了解对方想法，并最终统一思想

• 达成一致：达成一致的概念就是系统的稳定点，而未能达成充分一致的可能就是系统的变化点或扩展点，主要我们在设计上充分考虑

当这些来源于实际业务的概念经过充分的讨论并将都达成一致后，我们可以保证我们设计的系统就是充分满足现有组织业务需求的系统，未来也可以扩展。



DDD的核心言责就基于实际业务设计系统，基于各方意见核对设计，高度符合现实，高度思想统一。遵循这些原则我们就能保证我们系统设计的符合业务需求。



4. 后语

我们从单体应用一直聊到微服务架构，我们并没有关注与架构的技术实现，而是重点探讨了架构是如何支撑业务演化和扩展的。其实这些才是架构进化的根本目的和检验架构是否成功核心标准，最后在强调几点：

• 使用什么架构是当前业务场景和未来扩展需求决定的。

• 实现业务最重要，其他非功能需求可以后续考虑。

• 技术没有银弹，业务上也一样，设计架构时需要深入业务了解本质，善用业务分析工具和原则。