*作者：卜比*

全链路灰度是微服务领域，很实用的企业级场景下的技术能力。

从本期开始，我们将通过《全链路灰度：自顶向下的方法》的系列文章，由远及近的剖析全链路灰度全貌，系列文章分为 4 篇：

《从三万英尺看全链路灰度》：介绍微服务的基础概念、主流的部署模式。

《从三千英尺看全链路灰度》：介绍全链路灰度和涉及的组件，以及如何组装成全链路灰度的能力。

《从三百英尺看全链路灰度》：从技术细节入手，分享如何实现路由能力和灰度能力。

《总结篇》：总结全链路灰度，目的是更加高效支持好业务同学，进一步保证线上稳定性。

## 微服务架构的优势

### 划分微服务层次结构，拆分复杂度

在微服务架构出现之前，更多的业务采用的是单体架构。单体架构在复杂业务场景下，每一个开发人员都无法准确的评估复杂度：每一个修改都需要遍历代码库，确定这个修改不会影响其他功能。

在微服务架构出现后，通过 RPC、消息队列等技术，我们可以很好的划分出微服务体系结构（microservices hierarchy）：**架构师关注业务逻辑；业务开发者关注微服务内的业务自洽；中间件开发者关注基础设施的高效和稳定**。分离、拆分了复杂度。

### 高内聚低耦合，让业务更加聚焦

在单体架构中，代码的模块化一般是通过 package、namespace 等语言特性来实现的，但这种模块化的实现，会有各种各样的问题：

-   package、namespace 等特性是语言相关的，如果出现跨语言的情况，需要重新组织代码结构
-   模块化划分没有标准。以 Java 为例，是以 controller、service 等组件类型来划分 package？还是以各个业务域来划分 package？
-   package 划分缺少强制工具。即使我们定了划分标准，但 package 仍不能强制限定模块化，业务同学写出了跨模块的调用，仍然能通过测试、上线。

面对上述问题，亚马逊提出了 API-first、FaceBook 开源了 Thrift、Google 开源了 gRPC，帮助开源社区构建了微服务基础设施。

### 限制不好的架构设计，让代码能够无负担进化

在单体架构时代，经常遇到一些比较难看的设计，但是改动这些代码，总是会遇到兼容性问题，不能彻底移除。

拆分成微服务后，每个微服务都可以有自己的开发语言、设计模式，即使出现了设计问题，我们也能够将这些糟糕的设计限定在每个服务内部，阻止了架构的腐化和失控。

### 微服务的基础概念

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/219b8501794f4d07b7680f0caafc5ee4~tplv-k3u1fbpfcp-zoom-1.image "1.png")

微服务生态图

上面这张图很好的展示了微服务体系下，我们需要依赖的基础设施以及相关开源项目，下面我们分模块简要介绍下：

-   微服务之间要能够互相发现、互相调用，就需要注册中心。
-   微服务的部署需要标准化，方便迁移、扩缩容，业界比较流行的部署模式有 Kubernetes。
-   微服务的问题排查、监控等，需要可观测组件。
-   微服务体系需要引入外部流量、鉴权等，需要微服务网关。
-   微服务的数据存储，根据存取的方式、成本不同，可以使用 MySQL 或者 Redis 等。
-   需要实现全链路灰度、API 管理等微服务治理功能，就需要治理中心。

## 微服务的拆分

技术层面上，微服务的拆分，通常可以按照业务模块、业务场景等进行拆分，尽量确保服务逻辑自洽、对外其他比较少，做到**高内聚低耦合**。紧密关联的业务逻辑，放在一个微服务内，避免在服务与服务之间共享数据。

从组织结构层面上，微服务解决的根本问题是团队分工问题，详见康威定律，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“服务拆分粒度难以准确把握”根本不是本质问题。

你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/449ca7dba7e14086b34bedb2acd12013~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## 微服务的部署

从大体上来看，微服务至少需要部署在线上和测试环境。但需要注意的是，开发口中的环境和此处的环境会很容易混淆，所以我们借用 K8s 命名空间的概念，使用命名空间来防止混淆。

在线上命名空间中，我们能够保证代码都是经过 review 的、数据库都是线上数据。线上的应用版本，一般分为 prod（生产版本）、gray（灰度版本，少部分线上流量进入）、pre（预发版本，仅内部人员可用）。

在测试命名空间中，测试同学和开发同学发起流量进行测试和开发。在测试环境中，一般每个应用都部署了 stable 版本，提供一个稳定的测试环境；根据项目、开发流程的不同，相关的应用也会部署一些 project1 版本等。

另外，对于注册中心、Kubernetes 集群、消息队列等基础组件，也应当在不同的部署环境中单独部署一套。比如线上命名空间中的注册中心，和测试命名空间中的注册中心，应当分开部署，做到硬性隔离。

### 微服务流量灰度路由

对于不同的命名空间，不同的部署版本，我们都要考虑到流量是怎么路由的，不合理的流量轻则困扰研发、测试进度，重则导致线上事故。

#### 线上流量

对于大部分用户和流量，都应该路由到 prod 版本上。

对于符合灰度要求（比如百分比规则、特定用户等），应该路由到 gray 版本上。

对于内部验证账号，应该路由到 pre 版本上，验证功能是否正常。

#### 测试环境流量

对于属于项目环境中的流量，自然应该路由到对应的项目环境中。

对于不属于任何项目环境中的流量，我们将其路由到 stable 版本中。

## 总结

下面这张图能够反映出恰当的生产、测试部署环境下，整体微服务的部署、流量走向、环境隔离：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6716e404dd954dbcbd5db84322ec684e~tplv-k3u1fbpfcp-zoom-1.image "3.png")

至此，我们对微服务全链路灰度有了一个全局（且粗糙）的认知，我们当然需要了解全链路灰度是如何实现的，如何让流量根据不同的特征，路由到不同的节点。这些内容就是下一篇文章要讲的 **《全链路灰度原理——从三千英尺看全链路灰度》** ，敬请期待！

点击[**此处**](https://www.aliyun.com/product/aliware/mse)，前往微服务引擎官网查看更多详情～

ITPub博客

从三万英尺看全链路灰度

最新文章