架构师图谱·微服务&消息队列篇

1. 概述

“架构师图谱”是一个很宏大的命题，特别是优秀的架构师自身也是“由点到面再到图”，一点点成长积累起来，尝试写这系列文章的目的更多的是结合自身的一些经验和理解，来解读工程师和架构师所应具备的技能模型，这里会更偏向于后端技能，依赖于开源技术、云原生或者其他第三方服务。重点介绍一些技术栈、设计理念和适应场景，这些可以作为我们选型时的依据。所谓“架构即决策”，是在一个有约束的盒子中寻求最优解。这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等编织、掺杂在一起的综合体。本质上无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。

1.1 序章

一个技术图谱：

计划会分三个篇章来介绍：

1. 微服务&消息队列篇：重点聚焦在微服务和常用的消息队列，包括相关的选型以及一些理论基础
2. 数据库&分布式篇：主要集中在数据库、分布式（一致性/锁/缓存/发号/任务调度等）
3. 尾篇：分享一些流媒体、Devops、项目管理、团队建设方向的一些经验

完整的思维导图：

2. 微服务

谈到微服务，通常会和SOA、微内核等架构进行比较，不过SOA粗粒度服务、庞大的ESB，在互联网更注重敏捷交付的场景，落地较少。微内核架构和微服务架构没有本质上的区别，但是更多的面向插件化场景，在一些类似营销、风控、工作流、管线等场景，对应的微服务可以采用微内核架构。

微服务（英语：Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。

微服务架构有别于更为传统的单体巨石服务，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署。这也体现了可扩展的基本思想：将原本大一统的系统拆成多个小部分，扩展时只修改其中一部分，通过这种方式减少改动范围，降低改动风险。

微服务架构涵盖了服务的多个方面，包括理论基础、网关、通信协议以及服务注册/发现、可观察性等基础设施。

2.1 理论基础

微服务的理论基础主要用来指导微服务架构设计、服务拆分，确定合适的服务粒度和边界。在做微服务之前我们首先要想明白我们现有系统面临什么样的问题，为什么需要微服务，随后才是怎么做。

微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway’s Law）。在康威的这篇文章中，最有名的一句话就是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway(1967)

中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。 最初这篇文章只是描述作者自己的发现和总结，后来“人月神话”中，引用这个观点，并将其“吹捧”成现在熟知的“康威定律”，其中的一些核心观点可以概括如下：

• 组织沟通方式决定系统设计，对于复杂的系统，聊设计就离不开聊人与人的沟通，解决好人与人的沟通问题，才能有一个好的系统设计
• 时间再多一件事情也不可能做的完美，但总有时间做完一件事情，这与架构设计的“简单、合适、演化”思维不谋而合
• 线型系统和线型组织架构间有潜在的异质同态特征，更直白的说，你想要什么样的系统，就搭建什么样的团队，定义好系统的边界和接口，团队内应该是自治的，这样将沟通成本维持在系统内部，每个子系统就会更加内聚
• 大的系统组织总是比小系统更倾向于分解，面对复杂的系统及组织，往往可以采用分而治之

“康威定律”更多的阐述了影响微服务实施的一些软性因素，再具体到业务上，我们需要结合业务现状、复杂度、团队现状进行进一步的评估、分析，再采用合适的方式进行拆分。面向业务拆分，我们一般需要考虑：

• 单体到微服务的拆分：从非核心服务到核心服务完成拆分，基础设施按照优先级进行落地。
• 粗粒度拆分微服务：按照质量（性能、复杂度、可用性）、交付频率拆分，重用现在的基础设施。
• 服务拆分的粒度：能够维持2-4个人维护一个微服务最佳，过少会导致没有备份，思维局限，过多也会使得每个人无法掌握服务所有细节，以及潜在较高的协作、交付成本。

当我们的业务和组织架构复杂度比较高的时候，很多概念只从技术的角度很难去抽象。但是为了达到可复制，足够的抽象是必须的，越高层的抽象越稳定，越细节的东西越容易变化。因此我们需要把思考层次从代码细节、技术架构拉到业务层面。

我们不妨自上而下，建立起通用语言，通过对不同领域的建模，逐步确定领域范围和业务边界，这也就是领域驱动设计（DDD）。 DDD 是一种在面向高度复杂的软件系统时，关于如何去建模的方法论，它的关键点是根据系统的复杂程度建立合适的模型，DDD中的限界上下文也完美匹配了微服务的高内聚、低耦合特性，这也为我们微服务的划分提供了强有力的基础。

除了微服务，在平台和中台的建设上，我们也经常谈及DDD，平台是解决公共能力的复用问题，防止重复造轮子，中台则是“企业级能力的复用”，中台从业务和平台服务中不断抽象和聚合，建立领域模型，形成的一整套可复用的平台级解决方案，这点和DDD战略设计不谋而合。平台和中台建模之后，我们就需要通过DDD的架构设计和微服务完成系统架构，平台、中台和微服务可以说是DDD一个落地的最佳场景，这也是DDD逐渐火热的重要原因。

DDD实施的一般步骤是：

• 进行战略设计，结合数据流向，上下文依赖，通过组合抽象的方式，逐渐形成一个较为完整的领域，这就是确定限界上下文和领域边界的过程
• 进行战术设计，进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象，哪些是领域事件，对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根，为聚合根设计仓储，并思考实体或值对象的创建方式
• 进行架构设计，结合限界上下文拆分微服务，对服务内的代码进行分层、实现，在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构

DDD并不是银弹，首先是团队对DDD的掌握程度以及领域专家（可以是研发、产品、测试等）的水平，一定程度上都会影响到DDD的落地，这里有几本关于DDD的书籍，由浅及深，非常推荐去阅读：

其次，在一些新业务场景，本身就充满了很多的不确定性，一次性把边界划清楚并不是一件很容易的事。大家在一个进程里，调整起来会相对容易，然后让不同的限界上下文各自演化，等到了一定程度之后再考虑微服务也是一个不错的选择。

2.2 网关

作为微服务的统一入口，也肩负着整个微服务的流量接入、管理、聚合、安全等，从服务分层的角度可以划分为接入网关和业务网关。

接入网关 接入网关提供最基础的流量接入和安全防护能力，侧重于全局，与业务无关。

• 域名&DNS，作为服务的流量入口，对外通过域名和DNS提供服务，国内域名厂商一般都依托于共有云或被共有云厂商收购，用来完善自由的云生态