共计 2415 个字符，预计需要花费 7 分钟才能阅读完成。
全链路灰度是微服务畛域，很实用的企业级场景下的技术能力。
从本期开始，咱们将通过《全链路灰度：自顶向下的办法》的系列文章，由远及近的分析全链路灰度全貌，系列文章分为 4 篇：
《从三万英尺看全链路灰度》：介绍微服务的根底概念、支流的部署模式。
《从三千英尺看全链路灰度》：介绍全链路灰度和波及的组件，以及如何组装成全链路灰度的能力。
《从三百英尺看全链路灰度》：从技术细节动手，分享如何实现路由能力和灰度能力。
《总结篇》：总结全链路灰度，目标是更加高效反对好业务同学，进一步保障线上稳定性。
微服务架构的劣势
划分微服务层次结构，拆分复杂度
在微服务架构呈现之前，更多的业务采纳的是单体架构。单体架构在简单业务场景下，每一个开发人员都无奈精确的评估复杂度：每一个批改都须要遍历代码库，确定这个批改不会影响其余性能。
在微服务架构呈现后，通过 RPC、音讯队列等技术，咱们能够很好的划分出微服务体系结构（microservices hierarchy）：架构师关注业务逻辑；业务开发者关注微服务内的业务自洽；中间件开发者关注基础设施的高效和稳固。拆散、拆分了复杂度。
高内聚低耦合，让业务更加聚焦
在单体架构中，代码的模块化个别是通过 package、namespace 等语言个性来实现的，但这种模块化的实现，会有各种各样的问题：
- package、namespace 等个性是语言相干的，如果呈现跨语言的状况，须要从新组织代码构造
- 模块化划分没有规范。以 Java 为例，是以 controller、service 等组件类型来划分 package？还是以各个业务域来划分 package？
- package 划分短少强制工具。即便咱们定了划分规范，但 package 仍不能强制限定模块化，业务同学写出了跨模块的调用，依然能通过测试、上线。
面对上述问题，亚马逊提出了 API-first、FaceBook 开源了 Thrift、Google 开源了 gRPC，帮忙开源社区构建了微服务基础设施。
限度不好的架构设计，让代码可能无累赘进化
在单体架构时代，常常遇到一些比拟难看的设计，然而改变这些代码，总是会遇到兼容性问题，不能彻底移除。
拆分成微服务后，每个微服务都能够有本人的开发语言、设计模式，即便呈现了设计问题，咱们也可能将这些蹩脚的设计限定在每个服务外部，阻止了架构的腐化和失控。
微服务的根底概念
微服务生态图
下面这张图很好的展现了微服务体系下，咱们须要依赖的基础设施以及相干开源我的项目，上面咱们分模块简要介绍下：
微服务之间要可能相互发现、相互调用，就须要注册核心。
微服务的部署须要标准化，不便迁徙、扩缩容，业界比拟风行的部署模式有 Kubernetes。
微服务的问题排查、监控等，须要可观测组件。
微服务体系须要引入内部流量、鉴权等，须要微服务网关。
微服务的数据存储，依据存取的形式、老本不同，能够应用 MySQL 或者 Redis 等。须要实现全链路灰度、API 治理等微服务治理性能，就须要治理核心。
微服务的拆分
技术层面上，微服务的拆分，通常能够依照业务模块、业务场景等进行拆分，尽量确保服务逻辑自洽、对外其余比拟少，做到高内聚低耦合。严密关联的业务逻辑，放在一个微服务内，防止在服务与服务之间共享数据。
从组织构造层面上，微服务解决的基本问题是团队分工问题，详见康威定律，这是大型软件倒退的必然，不因为人的爱好而扭转。当你读懂康威定律，就会发现“服务拆分粒度难以精确把握”基本不是实质问题。
你有几个 2 pizza 团队，最好就拆成几个微服务。举一个事实的例子：只有一个开发人员时，尽量就做单体利用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，蕴含开发、测试、运维），当然咱们也施行过一些传统大型企业，但团队还是处在横向构造的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很苦楚，尤其是运维团队。
微服务的部署
从大体上来看，微服务至多须要部署在线上和测试环境。但须要留神的是，开发口中的环境和此处的环境会很容易混同，所以咱们借用 K8s 命名空间的概念，应用命名空间来避免混同。
在线上命名空间中，咱们可能保障代码都是通过 review 的、数据库都是线上数据。线上的利用版本，个别分为 prod（生产版本）、gray（灰度版本，少部分线上流量进入）、pre（预发版本，仅内部人员可用）。
在测试命名空间中，测试同学和开发同学发动流量进行测试和开发。在测试环境中，个别每个利用都部署了 stable 版本，提供一个稳固的测试环境；依据我的项目、开发流程的不同，相干的利用也会部署一些 project1 版本等。
另外，对于注册核心、Kubernetes 集群、音讯队列等根底组件，也该当在不同的部署环境中独自部署一套。比方线上命名空间中的注册核心，和测试命名空间中的注册核心，该当离开部署，做到硬性隔离。
微服务流量灰度路由
对于不同的命名空间，不同的部署版本，咱们都要思考到流量是怎么路由的，不合理的流量轻则困扰研发、测试进度，重则导致线上事变。
线上流量
对于大部分用户和流量，都应该路由到 prod 版本上。
对于合乎灰度要求（比方百分比规定、特定用户等），应该路由到 gray 版本上。
对于外部验证账号，应该路由到 pre 版本上，验证性能是否失常。
测试环境流量
对于属于我的项目环境中的流量，天然应该路由到对应的我的项目环境中。
对于不属于任何我的项目环境中的流量，咱们将其路由到 stable 版本中。
总结
上面这张图可能反映出失当的生产、测试部署环境下，整体微服务的部署、流量走向、环境隔离：
至此，咱们对微服务全链路灰度有了一个全局（且毛糙）的认知，咱们当然须要理解全链路灰度是如何实现的，如何让流量依据不同的特色，路由到不同的节点。这些内容就是下一篇文章要讲的《全链路灰度原理——从三千英尺看全链路灰度》，敬请期待！
作者：卜比
原文链接
本文为阿里云原创内容，未经容许不得转载。
