【微服务】重新理解微服务之终究绕不过这4个坎？

Love The Way You Lie 2024-04-01 09:37 43阅读 0赞

大家曾经有没有遇过日常技术交流的时候，会讨论某某技术之间的关系是什么，某些技术是否应该用到微服务。我相信热爱技术交流的您，就算不是在微服务这里领域，或多或少都会跟其他同行会做一些争议话题的探讨，而且我敢肯定这些讨论绝对热火朝天。

今天我想从微服务的4个比较火热的话题进行出发，与大家分享我对微服务的一些个人见解，这4个话题分别是：**微服务来带的新问题、微服务与SOA、微服务与DDD、是否有必要引入聚合层**。这里部分话题，在业界会存在一定的争议性，例如DDD的引入、微服务与SOA的关系。

一千个人眼中有一千个哈姆雷特，不同的人以不同的视角去看待这些问题，都会拥有**不同观点与答案**。观点上，咱们**求同存异，不盲目遵从别人的想法，也不自以为是的把自己当成标准**。

当然了，我并不会**为了个人见解而故意制造观点与话题**，更不会把我所有的观点当成一个“所谓的”标准。因此在该篇文章，我会把多处理收集的资料梳理好放到文内，有理有据地结合自己的见解与大家分享一二。

这些内容**可能是大家日常容易混淆的，也可能是大家多次纠结不知道如何做出选择，**因此我希望通过我该篇文章的分享，能给大家带来新的观点上的碰撞，或是见解上的共鸣。

## 微服务带来的新问题 ##

**　　做技术选型就如网上购物一样，即使知道了****它****的优点，还得看看****它****的差评。我们得多方面评估，事先知道团队与业务是否能抵御与承受“坑”的风险**。

既然任何一样技术都无法成为软件工程的银弹，那么必然解决了某种问题的同时，也会带来一些新问题，微服务也不例外。我回顾了下当时我实施时的难点确实有不少。不过，我个人认为微服务给我们带来最核心的问题主要有三点，**两文化**与**一思维**：

*  自动化文化
 *  可观测性文化
 *  分布式系统思维

![5f8d4e6a804995f1e2fba40959ce1b98.jpeg][]

上面这三个问题，每个的内容单独拿来出讲的篇幅，都足以出一篇完整的文章甚至是书，基于此我会挑一些重点和大家分享。当然，几乎每部分的文末，我会放入相关内容的文章外链，如果大家有兴趣可以自行扩展阅读。

### 自动化：避免重复的人力劳动 ###

**　　任何的架构模式****，****也是需要同等的开发模式与之配合****的**，随着应用的拆分后服务的数量由**量变引起质变**，因而需要接受自动化来代替从前的“人工处理”，包括服务的部署、服务注册发现等等。自动化，是软件工程的其中一种处理手段，允许团队采用主流的工具、流程形成一套自动化机制，从而减少重复性工作、减少人力干预的不确定性因素。

这里说说我对软件工程的理解：**通过多人协作、有目标、有步骤、有计划的****，****并使用科学方法论指导开发与维护程序的这个过程，**也可以换成一条公式表达：**软件工程 = 工具 + 流程 + 模式。**

![5c0c1df70ed4df2e40b32d5a2c8c2e23.png][]

无论是我们讨论的这些**“事”**、**技术工具****，**还是**流程制度**都是需要**人（团队组织）**的参与，**人**的延申就是**团队与文化**，就如上述所说的软件工程是多人协作的工作，只有当然团队目标一致，共同负责承担团队的项目，共同接受同一种文化才能很好的实施自动化。

我简单举个例子：如同多匹马拉车一样，只有它们都有共同的目标的时候，才能快速拉车到目的，如果它们一匹向东一匹西，只会让马车无法前行甚至四分五裂。

说到这里有些人觉得疑惑，自动化这种能给团队省时省力、减少重复工作量、增加幸福度的技术难道还有人或者团队会抗拒的？是的，还真的有。

我曾经就接触过几个团队的Leader，他们的团队都是推行自动化失败了，失败的原因就在于成员不配合，成员拒绝配合的理由是：没有自己亲手去做总觉得机器不靠谱。我们先忽略他们的想法是对是错，回到团队与文化，从上面可知，**统一团队的目标一致性是有必要的**，作为技术领导者推行优良的方案，是我们的职责之一。如果团队成员无法配合，导致推行受阻，我们一共有三种应对策略：**激励、考核和逐步试行**。

![20c03023b2730362007a906e27f80f3d.jpeg][]

如果有条件的公司可以设置奖金激励，如果有绩效考核的，可以将自动化的实施纳入考核目标，如果这俩都没有，那就选取团队里愿意改变的同事牵头试行，假如使用过后都说好，那么会更有说服力。

### 可观测性：**提高团队对系统运作的信息量** ###

如果说自动化是给团队带来稳定性，减轻工作量的，那么**可观测性**就是**提高团队对系统运作的信息量。**建立可观测性的这项工作，虽然无法直接给系统带来健壮性，但能够使我们通过这些信息充分地了解到系统正在运作的情况，以至于最大程度地做出最合适的**定位、判断与决策**。

在单体应用的场景下，我们也是需要可观测性的，但是单体的架构相对简单，项目调试也更加便捷，无论是从复杂度和规模的角度来看，单体跟微服务相比都要低不少，也因此单体对可观测性的需要，相比于微服务显得没那么重要。

而我们只要进行了微服务实施后，因为应用被拆分成了细粒度，从而导致了架构从**量变引起质变**，这个时候可观测性的作用在微服务场景下被**“无限放大”**，也因此我们利用**"可观测性"****，**给与我们提供应用与服务器的监控、快速跟踪与问题定位的功能。

> 可观测性——可以由系统的外部输出推断其内部状态的程度，在软件系统中，可观察性是指能够收集有关程序执行、模块内部状态以及组件之间通信的数据

而可观测性三个维度组成：**日志（logging）、跟踪（ tracing）、指标（Metrics）****。**

![fed9bb055653196df41424266d741aaf.png][]

**日志（logging）**的**定义特征**是它记录离散事件，**目的**是通过这些记录后分析出程序的行为。

**跟踪（ tracing）**的**定义特征**是它处理请求范围内的信息，**目的**是排查故障。

**指标（Metrics）**的**定义特征**是它们是可聚合的，**目的**是监控和预警。

<table> 
 <tbody> 
 <tr> 
 <td> 可观测性 </td> 
 <td> 类型 </td> 
 <td> 名称 </td> 
 </tr> 
 <tr> 
 <td> 跟踪（&nbsp;tracing） </td> 
 <td> 分布式链路跟踪 </td> 
 <td> SkyWalking </td> 
 </tr> 
 <tr> 
 <td> 日志（logging） </td> 
 <td> 日志系统 </td> 
 <td> ES+Filebeat+kibana </td> 
 </tr> 
 <tr> 
 <td> 指标（Metrics） </td> 
 <td> 系统监控 </td> 
 <td> Prometheus </td> 
 </tr> 
 </tbody> 
</table>

因此基于上述总结，有**日志记录**才能清楚知道当前系统的运行状况和具体问题；**指标**是给与后续做优化和定位偶发性问题的一些参考，没指标参考就没标准；我们平常做得多的调试、查看调用栈也是跟踪的一种，但是在分布式时代，更多考量的是跨进程通信的**调用链路**。

日常有小伙伴曾问过我，如果出了那些很奇怪的问题，应该怎么定位、排查，本质上其实还是得提高我们对这个问题或系统的信息量。

例如：是哪个模块、接口出问题？具体服务器表现的情况是怎样？CPU还是IOPS高？具体报错是什么？

你看，说白了还是可观测性的三个要素日志、跟踪、指标。我们在工作中只有灵活结合这三者，才能**提高我们对系统运行情况的信息量**，信息量越高思考的越是更加全面，才能尽可能地减少“不知道问题出在哪”的状况，所以当我们不清楚具体发生问题的原因时，建议你侧重做一件事：就是尽可能想办法，提高我们对问题与系统的信息量。

### 新思维：不可避免的分布式系统问题 ###

上文的自动化和可观测性，主要偏向于**运维层面**，而作为后端开发人员更加关注的是**数据与应用服务的层面**，特别是服务的拆分后，数据的一致性该如何处理。我相信这问题困扰着不少的后端开发，接下来我将从**幂等性、数据的一致性的读与写**三个方向，跟大家分享一二。

#### 幂等性 ####

> 幂等性的定义——相同的参数在同一个方法里，无论执行一次还是多次都会响应相同的结果

对于**查询**和**删除**的场景都有**天然的幂等性**，那么我们考虑幂等性的处理，更多是关注于**新增数据**与**更新数据。**

新增数据缺乏幂等性，则会因为网络抖动导致请求重试或者是客户端重复点击，而引发的数据写入重复，其解决方案也相对简单，只要从客户端生成主键传给后端API 就可以解决，在**这里得注意一点，只有请求成功或者主动刷新才会重新生成主键。**

更新数据缺乏幂等性，主要会造成两种情况，**数值错误自增**和**ABA问题**。首先，数值错误自增，可以结合事务凭据与新增幂等性的方式解决。

![6a5fbcc14d95114273b09c9afd7d5f9f.png][]

而ABA问题，解决方案相对简单，可以在更新操作时带上版本号判断进行解决。

> ABA问题
> 
> 对某条记录先更新了A数据，紧接着又更新了B数据，理应是B是最新的，但是因为其他客观原因使接口Retry或者别的问题，导致A数据再次请求覆盖了B。

<table> 
 <tbody> 
 <tr> 
 <td colspan="3"> 幂等性处理方案 </td> 
 </tr> 
 <tr> 
 <td> 场景 </td> 
 <td> 问题 </td> 
 <td> 方案 </td> 
 </tr> 
 <tr> 
 <td> 新建数据 </td> 
 <td> 重复创建 </td> 
 <td> 由调用端预生成订单号，唯一键约束 </td> 
 </tr> 
 <tr> 
 <td colspan="1"> 更新数据 </td> 
 <td> ABA覆盖问题 </td> 
 <td> 添加版本号判断 </td> 
 </tr> 
 <tr> 
 <td> 金额自增 </td> 
 <td> 使用流水凭据 </td> 
 </tr> 
 </tbody> 
</table>

#### 数据一致性（读） ####

数据一致性读，其实说白了就是做数据关联，从我过往用的解决方案来看共有三种，**应用层的接口聚合数据**、**把更新频率低的字段冗余存储**、**把数据库同步到一台服务器进行SQL联表处理**，每种方式各有优缺点，我结合切身体会和过往经验，以表格方式整理呈现出来，你可以根据业务场景自行选择解决方案。

<table> 
 <tbody> 
 <tr> 
 <td colspan="4"> 数据关联方案 </td> 
 </tr> 
 <tr> 
 <td> 方案名称 </td> 
 <td> 方案描述 </td> 
 <td> 优点 </td> 
 <td> 缺点 </td> 
 </tr> 
 <tr> 
 <td> 应用层数据聚合 </td> 
 <td> 分别调用查询API，在业务逻辑层组装，适用于简单的关联。 </td> 
 <td> 实现简单 </td> 
 <td> 该方案只能适合简单的查询过滤，以主表为驱动的关联 </td> 
 </tr> 
 <tr> 
 <td> 冗余设计（反范式） </td> 
 <td> 在目标表添加冗余字段，适用于记录递增的，不适用于冗余字段更新频繁，实现起来简单，有扩展性问题 </td> 
 <td> 实现简单，以应用层数据聚合方案有更多的过滤条件 </td> 
 <td> 冗余的字段如果更新存在同步问题，该方案适用于更新频繁少的递增日志类数据 </td> 
 </tr> 
 <tr> 
 <td> 数据库从库集成 </td> 
 <td> 通过主从同步把相关表同步到一台服务器做跨库查询，适用于复杂查询、报表类的，有技术复杂度，从长远收益来看能应对多种场景 </td> 
 <td> 通过强大的SQL解决复杂的报表类查询 </td> 
 <td> 拥有技术复杂度，需要数据库主从处理 </td> 
 </tr> 
 </tbody> 
</table>

#### 数据一致性（写） ####

写的数据一致性，其实就是分布式事务，主流的方案有**TCC**、**本地消息表（基于消息可靠的最终一致性）**、**异步请求/回调。**其他的多数是基于以上几种方法的变种，例如RocketMQ的消息事务，就是TCC+本地消息表的变种。篇幅有限，这里分享一篇我曾经编写的文章《[.Net微服务实战之必须得面对的分布式问题][.Net]》。

![b4f7e4cd2e75409a403d72de954e50aa.png][]

分布式事务方案，用文字描述起来相对比较吃力，因此我通过流程图代替文字描述展示给大家。下方表格是我对这三种方案的优缺点与使用场景的总结。

<table> 
 <tbody> 
 <tr> 
 <td colspan="4"> 分布式事务方案 </td> 
 </tr> 
 <tr> 
 <td> 名称 </td> 
 <td> 场景 </td> 
 <td> 优点 </td> 
 <td> 缺点 </td> 
 </tr> 
 <tr> 
 <td> 异步请求/回调 </td> 
 <td> 跨网络环境、同网络环境 </td> 
 <td> 实现简单 </td> 
 <td> 强业务 </td> 
 </tr> 
 <tr> 
 <td> TCC </td> 
 <td> 跨网络环境、同网络环境 </td> 
 <td> 有现成的框架、实现简单 </td> 
 <td> 强业务 </td> 
 </tr> 
 <tr> 
 <td> 基于消息可靠的最终一致性 </td> 
 <td> 同网络环境 </td> 
 <td> 有现成的框架、通用性强 </td> 
 <td> 中间件依赖 </td> 
 </tr> 
 </tbody> 
</table>

### 小结 ###

**　　从"拆"的层面来看**，微服务的思想与优势给与开发人员带来了更多的便捷性，如**技术细节的隐藏**与**认知负担的降低，使得开发人员更加关注自己负责业务代码的迭代。**

但是，**拆了后还得重新整合**，如果拆了无法整合，那么这样的设计是没有意义的。**从"整合"的层面**，微服务大大提高了对架构师技能的要求，从通信交互到分布式问题，从自动化工程到可观测性，每一项对于架构师都是一种新的挑战。

## 聊到微服务总绕不过SOA ##

无论是过去还是现在，只要聊到微服务总有个绕不过去的坎，那就是SOA。接下来，我会结合**《****Microservices****》原文（**[Microservices][]**）**的**\[Smart endpoints and dumb pipes\]**模块，简单聊聊微服务与SOA的之间的关系，有助于大家更好地了解为何微服务比SOA更容易实施与盛行。

在**《****Microservices****》原文**里有一个模块的标题是**Smart endpoints and dumb pipes**，如果用翻译直译成中文是**\[智能端点和哑管道\]**，我结合了自己的经验并查阅了多种资料，最终认为**\[强服务和弱通信\]**作为它的翻译才更加合适。

![a847e77bf42af4db183c4a67998961ab.png][]

微服务的\[**强服务和弱通信**\]，与SOA的\[**弱服务和强通信**\]是与之对应的，而**SOA架构的核心是ESB**，ESB主要功能有消息路由、协议转换、消息转换和应用业务规则的复杂。仔细观察下来，ESB基本上把微服务的基础设施该做的都做了，如此高的技术复杂度，也是导致SOA在过去那些年无法普及跟实施的根本原因。

ESB的**大而全**的特点，在文中描述到SOA的通信是“聪明的”（smart pipes），而我也因为ESB的特点给SOA的翻译是“强通信”。此外，我翻译的微服务的“**弱通信**”，并不代表通信的功能有限，而真正的意义是**弱化协议差异**，使用统一、轻量级的通信协议，减少差异化、降低技术难度。

![6606f7a3be05bb1c64f1a3998be2f140.png][]

总地来说，基于两者在通信层面的对比，我们因此能总结出它们本质上的差异：**SOA基于配置，微服务则基于约定。**

### 关系的分类 ###

既然上面已经谈到了微服务与SOA之间的对比，接下来，又不得不提SOA与微服务的关系了。我从多个方面的资料梳理后，总结出有这样两种看法：

1.  **微服务是SOA的最佳实践**（出自维基百科）—— 微服务是SOA的演进版，粒度更细，基础设施去中心化。
2.  **微服务拒绝SOA的标签**（出自马丁福勒的《Microservices》原文）——微服务与SOA，是两个完全不同的架构风格，只不过刚好长得像。

![8ff8bbb592be77beb4b2cb1243741a23.png][]

### 场景与目的 ###

我相信，不少朋友看到SOA与微服务关系方面的话题时，肯定第一时间在想，无论是维基百科还是百度，都是写着微服务是SOA的演化这还要说？是的，人云亦云的，大家听多了看多了，不妨从新的观点与角度看待一下问题，这样或许会有新的碰撞与共鸣。

大家认为，微服务是SOA的演进版的理由也比较简单，因为微服务基础设施只不过是把SOA的ESB拆了，而微服务粒度更细，SOA更粗。从表面看起来的确是这么一回事，但是我认为，**要看清楚它们关系的本质，就得从两者各自****的****处理场景目的出发。**

首先从微服务角度出发，因为单体应用的**大而全**的高耦合与臃肿，随着业务的发展迭代的时间越久，就会有各种各样的问题，因此通过把应用**拆**成了多个"小"的服务，这里使用到了**化繁为简**、**分而治之**的思想，解决原有单体的“痛点”和“难点”。

![93a3c815dce3a3bf538e7af6ab9f9b11.jpeg][]

接着从SOA的角度出发，在当时那个年代，希望把各种异构的系统给**整合**起来，这些异构的系统，有可能是从其他地方买的，也有可能是研发的，也有可能是找外包做的，**因缘由存在各种不确定性，所以希望通过一个"聪明的"ESB解决所有的"愚蠢的"问题，**也是因此ESB的高复杂度，导致当年SOA那会只是炒得火热，却无法普遍落实。

![6e102e2b59ca76f545cf073900a80ba8.png][]

总地来说，微服务以**拆**与**约定**作为出发点，而SOA是以**整合**与**配置**作为出发点，所以我个人认为从它们的出发点与目的的角度出发，直接决定了它们在本质上是完全不同的架构风格。所以我更加倾向于**《****Microservices****》原文**提到的看法，微服务的倡导者拒绝SOA这个标签的。

## 微服务与DDD的争议 ##

要是说SOA是微服务理不清的过去，那么DDD更是微服务的一块拦路石。拦住的不是技术人员对它们的热情，而是它们之间扯不清的“**捆绑销售”。**

**　　《****Microservices****》原文、《微服务设计》、《领域驱动设计精粹》****，**都有涉及到DDD对微服务划分的参考。**DDD****战略上**的**化繁为简****，**与**微服务**的**分而治之**，这两者的思想，可以说是不谋而合。成就了彼此，但是它们是否必须密不可分，又或者说无DDD就无微服务的说法呢？我是这么认为的。

![d6ea7bd4f5a251493bd87f41d93bba66.png][]

### DDD（领域驱动设计）的过去 ###

2004年，埃里克•埃文斯（Eric Evans）发表了《领域驱动设计》一书简称**DDD（domain-driven design ）**，自DDD提出后在软件开发领域一直处于SOA相似的尴尬地位——宣传得火热，真正用的少。

随着微服务架构的兴起，DDD才迎来了自己的时代。在上文提到三本书（**《****Microservices****》原文、《微服务设计》、《领域驱动设计精粹》**），都有涉及到使用DDD战略来识别边界上下文，从而划分服务。总地来说，DDD并不是什么新颖的技术，当年许多布道者也没有把它带火，如今却靠着微服务流行起来而加速了DDD的盛行。

![37c481c1f8d0d3dc74cf32d3fa641e94.png][]

但是，DDD的盛行并非它所有的一切，我总结了DDD的一些核心概念，希望在我详细叙述前，可以帮助到你快速了解DDD，以便于对后续内容有个更好的理解：

> 领域驱动设计的本质是，打破业务与开发之间**沟通壁垒**，建立**通用语言**；从而在**战略设计**与**战术设计**两个维度上使用**化繁为简**手段将**通用语言逐步拆解**成领域模型；从而确定业务与应用的边界，保证业务模型与代码模型的一致性。

> **战略设计，**从**业务视角**出发，建立业务领域模型，划分领域边界，建立通用语言的界限上下文，界限上下文可以作为微服务设计的参考边界。

> **战术设计**，从**技术视角**出发，侧重于领域模型的技术实现，完成软件开发和落地，例如我们常讨论的聚合根、实体、值对象、领域服务等代码逻辑的设计与实现。

结合上述的**DDD概念知识**与**\[业务与团队\]**模块所叙述，我们可以得到以下结论：**业务需求**是作为我们设计的核心输入之一，**要做好领域驱动设计****，****并非取决于对它本身****的****概念掌握程度如何，而在于如何使用这些方法论了解清楚业务需求后，进行正确的领域建模**，就算对DDD的概念再熟悉不过，要是对领域业务缺乏了解，结果也是无法正确建模的，那跟用不用DDD其实已经没什么区别了，所以我认为这种做法与结果是本末倒置的。

![a6da0906cf83fd915d31aff2892c725b.png][]

PS：\[业务与团队\]这个模块是先前发表的文章《重新理解微服务之温故》里的内容，两文之间没有特别的前后关联性，有兴趣的朋友，可以阅读完本文后可自行进行扩展阅读。

> ***【维基百科】***
> 
> ***领域驱动的局限性****，为了帮助保证模型能作为一个单纯并有用的语言结构，团队通常必须在领域模型中实现大量的隔离和封装。因此，基于领域驱动设计的系统可能会花费相对较高的成本。虽然域驱动设计提供了许多技术优势，如可维护性，但 Microsoft 建议仅将它应用于复杂领域中，在这些复杂领域中，通过模型和语言处理能够在复杂信息中提供交流便利性的，并且能够该领域达成共识。*

文中我也多次声明软件工程是没有“技术银弹”的，结合上面领域驱动的局限性（维基百科）的叙述，DDD同样也有它的适用场景与局限性，像军工、金融等这些领域，就比较适合使用DDD，因为它们都具备了这两个特征：

*  **生命周期长（投入产出比）**
 *  **逻辑足够复杂(使用复杂对抗复杂)**

而互联网系统拥有需求高频变动性、快速试错和定制性，DDD是否需要引入，大家见仁见智。

### DDD战略的重要性 ###

首先，**DDD的战略设计**是可以使用指导划分微服务，这点是毋庸置疑的，因为**微服务的分而治之**的思想，与**DDD的化繁为简****，**的确是不谋而合。

![cad590b486fde3d6b457ff4bd2de14e9.png][]

然而，我接触过不少DDD的热衷者，只要聊起DDD，全部都是DDD的概念与术语，同时把**DDD战术设计**代入为微服务的全部，一开口的就是概念术语什么仓储、什么领域服务、什么聚合根，Abp框架，尽扯跟微服务设计没有半毛钱关系的东西，微服务的**服务治理**、分布式需要面对的**数据一致性、幂等性**和**自动化部署**却闭口不谈。

**　　战术设计**其实就是为了落实面向对象设计与编程、从业务模型到代码模型的翻译，说通俗点就是针对单个服务与应用的设计，而由微服务架构风格设计的系统是属于分布式系统，应更多关注跨进程的交互与服务的整合。

因此，DDD战术设计是否引入，完全是看该服务对于系统的重要性。

在**《微服务设计》**一书提到过，微服务里的服务的复杂度能在两个星期内重构完成的。如果遵从DDD战术设计思想的应用，那么**是使用复杂对抗复杂**，因而会增加服务本身的复杂度。从个人的角度来看，DDD战术与微服务拆分后降低复杂度的出发点，**相违背**。

![a66a35fc3a171c35b57e6757da369628.png][]

因此我实施微服务的时候，最终还只是以**战略设计**引入到微服务设计里，在期间我尝试使用了**事件风暴**与其他同事合作，帮助识别我业务边界从而确定界限上下文，而DDD战术则根据日后业务稳定，并且边界清晰后，再考虑选择性引入重构。事件风暴是一个从拆解到整合的过程，过程中需要领域专家（需求提出者）和技术实践者协作完成领域建模。

一般采用场景分析和用例分析尽可能分解出领域对象（实体、命令、事件），可以从交流的过程中提取出领域专家（需求提出者）口中的名词、动作、触发事件等，这是一个拆解的过程。

在软件工程里没有银弹，微服务不是，DDD也不是，我们所做的永远提供的是**解决方案**，**同一个问题能有很多种解决手段，但是同一种解决手段并不能解决所有问题**。

## 微服务需要引入聚合服务层吗？ ##

这是咱们这篇文章的最后一个话题了，也**是我在微服务实践时被同行问得最多的一个问题。**

回顾我身边，不同的时间，不同的人，实施同一种微服务架构风格，都问过我同一个问题：他们网上找了很多资料，聚合服务层有的说引入，有的说不需要，那么，究竟微服务是否真的需要引入**聚合服务层**呢？

说句实话，这个问题也曾经困扰过我。经不断的积累，我想我可以给这个问题一个明确的答案了：**根据系统的复杂度与场景进行取舍**，接下来，我将详细叙述下我的思考结果。

### API网关的类型 ###

API网关可以作为多个微服务提供统一入口，它的思想类似面向对象设计的外观模式，API 网关也称为“面向前端的后端（BFF）”，因为它是为了满足客户端的接口整合需求而出现的。在《[Microservices-Architecture-for-Containerized-NET-Applications][]》一书里有这样个观点，认为API网关主要分两种类型：

*  基础设施型API网关
 *  自定义业务API网关

基础设施型API网关比较容易理解，我举个例子估计你就秒懂了，Kong 和 APISIX。这种类型的API网关主要**把服务具有相同的功能抽象到上游服务**，像鉴权、日志、限流、熔断等通用功能，可以**避免每个服务都需要去重新的实现这些相同的功能**。

![b2c223693ac05b18f66fbc6b0c307001.png][]

自定义业务API网关，其实就是把多个微服务，适配成方便客户端使用的API服务，避免客户端组装过多的API导致过于臃肿，也就是咱们上面说的**聚合服务层**，也有称之为面向前端的后端（BFF）。

### 取舍与选择 ###

有些朋友一看，既然能减少客户端的工作量和复杂度那这个不是好事么，还需要思考是否要引入？大家可别忘记了，在上文，我们多次提到了微服务的核心点——**自治性**。

如果在原有的基础上加多了一层新的微服务，那么上游微服务就会受到下游微服务的更新而有所影响，如果下游服务接口有更新，上游服务也可能跟着一起更新，因此丢失了自治性。除此之外增加了调用链长度，也会降低系统整体的可用性。

![6779ac0cf80588faa6577b61e4ba4fab.png][]

无论用和不用好像都有问题，该怎么办？**取舍**！

作为一个架构师，大部分的工作就是根据问题场景**选择合适的**处理方案，因为大部分的方案是无法做到“完美的”，因此我们很多时候还得做出一定程度的**取舍。**

从个人的角度认为，如果**多个业务**需要客户端**组合大于等于3个接口**，我们可以**舍弃部分自治性**而选择引入BFF，以此来降低客户端对接的**复杂度**。如果客户端的业务相对比较简单，BFF则不需要引入，那可以最大程度的保证自治性。因此在开始设计微服务的时候，在不明确的情况可以暂时不需要考虑，随着业务系统的迭代，系统**复杂度**越来越高，我们再考虑BFF的引入。

![35fbe576cd934d16a77d7ce495f5679d.png][]

**　　基础设施型API网关**与**BFF**两者的存在不是非此即彼的，因为**基础设施型API网关**不影响微服务的自治性，因此可以独立于BFF的选择，是否引入也取决于**团队的运维支撑程度**如何，运维能力足够则使用中间件支撑，运维能力有限，则在微服务的代码里实现。

### 小结 ###

总上文可见，**方案是没有“完美的”，设计只有"合适"与"不合适”，没有“对"与"错"**，架构师永远是在"取"与"舍"之间扎挣，而促使我们能做出那一次又一次的合适的选择，只有积累与经验。

## 结语 ##

该篇文章到这里就差不多结束了，我始终认为一图胜千言，因此我在文中基于上述分享的知识点，给大家做了个脑图，以便于帮助你回顾与总结。

![ebfd9e94374846438cb706bd0217ba83.png][]

微服务与DDD的见解，我也是再三思考了才打算写出来，我清楚地知道有不少的DDD热衷者认为这门技术是多么的“神圣”，当然曾经我也是。

但是，随着自己使用、接触的技术越多，越是发现技术并不是那么的**唯一****、****神圣**，促使我们能在这条道路走得更高更远的，是咱们的思维，是我们对这些技术做出**适当****的****选择与使用**，而不是想着“一招鲜吃遍天”，**我们是技术的创造者与使用者，而不是概念名词的搬运工**。

[5f8d4e6a804995f1e2fba40959ce1b98.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/23f3795c12da405caa1fd75828eb3599.jpeg
[5c0c1df70ed4df2e40b32d5a2c8c2e23.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6fd7f672868b4e96b93ad5e621806df2.png
[20c03023b2730362007a906e27f80f3d.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/61ee1cff024148418d483f1f53a7efd6.jpeg
[fed9bb055653196df41424266d741aaf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/9635ba2a4dd04bbe95fbbfc00cc0f6d7.png
[6a5fbcc14d95114273b09c9afd7d5f9f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6ea93a4baca6418b9ff338ff71a6630a.png
[.Net]: https://www.cnblogs.com/skychen1218/p/14346459.html
[b4f7e4cd2e75409a403d72de954e50aa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/484c1b2cea5a4803a8cb8737f8da1f30.png
[Microservices]: https://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
[a847e77bf42af4db183c4a67998961ab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/0dd85a6ccc0a4b72b20f8cf7128591fd.png
[6606f7a3be05bb1c64f1a3998be2f140.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/06a7f39a15f64728bb369898f7d64f28.png
[8ff8bbb592be77beb4b2cb1243741a23.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5dafad3a4a644a7fbec0ce8cdb85ad88.png
[93a3c815dce3a3bf538e7af6ab9f9b11.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f3ca82379c9d441993d97a48fa0a9f77.jpeg
[6e102e2b59ca76f545cf073900a80ba8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/bd8529270be44c1db0decbbc4aabc5a6.png
[d6ea7bd4f5a251493bd87f41d93bba66.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/d5f0ec1ee55b46649416d424f9573fd6.png
[37c481c1f8d0d3dc74cf32d3fa641e94.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/10e791cd60704bb582babb199988ee5b.png
[a6da0906cf83fd915d31aff2892c725b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/a1d39133c6b34d8aa48eee4acfde0bef.png
[cad590b486fde3d6b457ff4bd2de14e9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/63bce3e72df84f289d6aca12090f792d.png
[a66a35fc3a171c35b57e6757da369628.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/75ff8e8a87fd4d24badbea843872ad8a.png
[Microservices-Architecture-for-Containerized-NET-Applications]: https://dotnet.microsoft.com/zh-cn/download/e-book/microservices-architecture/pdf
[b2c223693ac05b18f66fbc6b0c307001.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3d71a9ee247444ea9ac301e06df9f15e.png
[6779ac0cf80588faa6577b61e4ba4fab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/49054e0567c740e098161e9b5af496dc.png
[35fbe576cd934d16a77d7ce495f5679d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/c5324e50540743028dd0db53e63d5f30.png
[ebfd9e94374846438cb706bd0217ba83.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/634139ce2c6145b4b80f9d84dd3ee0ad.png