从三万英尺看全链路灰度
Posted 阿里云云栖号
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了从三万英尺看全链路灰度相关的知识,希望对你有一定的参考价值。
全链路灰度是微服务领域,很实用的企业级场景下的技术能力。
从本期开始,我们将通过《全链路灰度:自顶向下的方法》的系列文章,由远及近的剖析全链路灰度全貌,系列文章分为 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 版本中。
总结
下面这张图能够反映出恰当的生产、测试部署环境下,整体微服务的部署、流量走向、环境隔离:
至此,我们对微服务全链路灰度有了一个全局(且粗糙)的认知,我们当然需要了解全链路灰度是如何实现的,如何让流量根据不同的特征,路由到不同的节点。这些内容就是下一篇文章要讲的《全链路灰度原理——从三千英尺看全链路灰度》,敬请期待!
作者:卜比
本文为阿里云原创内容,未经允许不得转载。
以上是关于从三万英尺看全链路灰度的主要内容,如果未能解决你的问题,请参考以下文章