落地三年,两次架构升级,网易 Service Mesh 实践之路

阅读数:3 2020 年 4 月 8 日 08:28

落地三年,两次架构升级,网易 Service Mesh 实践之路

当 Service Mesh 从概念期进入到应用期时,大家的关注重点都会转向先锋企业的落地实践。为了帮助大家在实践中“避坑”,我们采访了多家互联网企业的应用实践,例如美团点评同程艺龙以及瓜子二手车等,本文将和大家分享的是网易的 Service Mesh 实践。今年 6 月,本文采访嘉宾冯常健将在 QCon 全球软件开发大会(北京站)2020 上分享题为《网易基于 Istio 的 Service Mesh 2.0 架构升级实践》的演讲,感兴趣的同学可以关注一下。

2016 年,网易的部分业务严选、传媒等率先开始探索使用 Service Mesh 架构支撑微服务体系建设;2017 年,网易开始落地 Service Mesh 1.0,代号 cNginx;2019 年,由于 Service Mesh 1.0 在管控能力和流量治理等方面的不足,网易开始基于定制 Istio 和扩展 Envoy 落地云原生 Mesh 2.0,代号轻舟微服务。经过 1 年的升级改造,轻舟微服务已经在严选落地。

传统微服务架构与 Service Mesh

大多数企业的 Service Mesh 实践都不是从零开始,而是在原有微服务架构的基础上进行改造转型。那么,传统微服务架构在转型过程中会面临哪些问题?转型之后,企业内部不同角色的技术人员需要做出哪些改变?

传统的微服务框架以 RPC 通信框架为基础,提供服务目录、注册发现、服务治理、流量管理、配置中心、全链路追踪等核心能力,并且向外延伸到安全审计、监控告警、统计分析、知识库等平台化能力。

冯常健表示:“服务框架在微服务架构中占据核心位置,因此,使用 Service Mesh 来替换正在使用的微服务框架,无异于一次‘换心手术’。”

以网易为例,他们的关注点在于如何在不中断业务的情况下,逐步将微服务架构支撑能力下沉到 Service Mesh 架构里。想要实现平滑过渡,除了需要在 Service Mesh 数据面和控制面组件中对服务注册发现、RPC 协议、配置下发进行扩展之外,还要对现有的上层研发工作台、运维效能平台等支撑平台进行兼容设计,避免支撑平台等基建重复建设。

在部署架构方面,Service Mesh 比传统微服务框架多了一层 Sidecar,且服务治理是基于流量的,因此会带来一系列的问题和挑战。

  • Sidecar 的运维复杂性问题,微服务架构支撑能力下沉后,也把复杂性下沉到了 Sidecar。Sidecar 面临着频繁更新的问题,但 Kubernetes 和 Istio 只解决了部分部署的问题,因此如何在不影响业务的情况下热更新 Sidecar 成为了新的挑战;

  • 性能问题,某些对延时比较敏感的业务会对性能问题有较多顾虑,迫切需要对服务与 Sidecar、Sidecar 与 Sidecar 之间的链路进行性能优化;

  • 整体架构的可观测性和排障效率问题,对业务方来说,服务注册发现、服务通信等原本客户端可见的过程现在都成了黑盒,在问题诊断和故障恢复方面需要更立体化的监控系统支撑。

Service Mesh 实践会如何影响企业内部员工的工作内容呢?

传统模式下,开发和运维会有比较清晰的边界,开发人员负责服务运行稳定,运维人员负责服务运行的基础设施稳定。而进入到云原生时代,特别是容器化和 Service Mesh 落地之后,服务框架、服务治理、灰度发布等稳定性密切相关的能力都作为基础设施下沉了,开发和运维的边界开始变得模糊。所以,企业 IT 人员的职责也应该相应的进行重新划分。

  • 架构师及基础架构团队,新的职责要求他们必须要非常理解业务,清楚地知道业务的服务依赖和服务治理规则,故障后能从业务视角进行排障和快速恢复。同时,他们还需要重新审视现有的技术架构和支撑平台建设,从业务视角出发进行设计,避免做出来的技术平台无法满足业务需求,或者不好用。

  • 开发人员,原先开发人员要关注很多方面,例如服务框架、服务治理、环境一致性、遥测数据、客户端 SDK 版本升级等等,而现在,以上这些几乎统统不用关注,只需要专注于业务本身的逻辑开发;

  • 运维人员,依托于 Service Mesh 打通的服务和基础设施边界,以及对服务的统一抽象,能够更好的从全局视角进行服务质量、依赖管理、容量规划、端到端监控等来保障产品稳定性。

网易的 Service Mesh 实践

2016 年,移动互联网发展火热,网易业务发展飞快。当时内部各事业部之间在服务化框架的应用方面差别非常大,Dubbo RPC 框架、Spring Cloud 微服务框架、自研微服务基础设施都有,较少考虑微服务架构支撑能力的复用问题。

网易严选是 2015 年内部孵化、2016 年对外发布的新业务,没有太多的历史负担,考虑到电商业务的复杂性,其在微服务架构选型方面进行了慎重的思考。

  • 是否基于 RPC 框架提供服务治理?根据历史经验,由于业务团队和基础架构团队的关注点和优先级不同,推动 RPC 框架升级效率非常低,业务团队担心服务稳定性受影响,基础架构团队担心架构演进效率太低,矛盾比较突出。

  • 如何支持多语言?微服务时代多语言是趋势也是优势,严选的核心业务是基于 Java 技术栈的,但是还是有大量前端业务和运营业务是基于 Node.js,另外还有不少业务是 Python 和 C++ 技术栈的。

  • 基于开源项目还是自研?自研系统可掌控性较强,但是会面临重复造轮子和项目生命力的问题,基于开源定制是一条更好的落地路径。

2017 年,网易落地 Service Mesh 1.0

2017 年,网易严选业务首先开始落地 Service Mesh 1.0(代号:cNginx)架构。在选型方面,数据面采用了 Nginx,控制面及注册中心采用 Consul,Nginx 和 Consul Agent 形成 Sidecar。通过 Nginx 实现了负载均衡、环境路由、熔断降级和限流等服务东西向流量的管理,通过 Consul 实现了服务注册发现、配置同步、指令下发等控制面流量下发。服务对外调用的流量都通过本地部署的 Nginx。

落地三年,两次架构升级,网易 Service Mesh 实践之路

举个例子,如果运维人员要对某服务进行流控设置,只需通过服务治理平台将流控参数下发到 Consul Server,Consul Server 通过一致性协议将配置同步到集群所有 Consul Agent,Nginx 能 Watch 本地 Consul Agent,生成 Nginx 流控配置,作用于服务间的东西向流量。

Nginx+Consul 提供的基础能力基本满足了业务和基础架构团队对服务治理的需求。Service Mesh 1.0 最早是在网易邮箱、网易有钱和网易严选试点,随着严选业务的快速发展,2017 年底,就基本在严选全面落地了,并发挥了重要作用。

  • 业务不改造即可接入服务治理能力,对齐了跨团队间对服务治理的理解,降低沟通协作成本,提升了业务团队生产力。

  • 解耦了基础架构和业务服务化架构,使得他们能够独立演进。业务团队聚焦业务开发,基础架构团队推动中间件和框架的升级可以做到业务无感知。原本需要三个月才能落地的 SDK 版本升级,现在只要两周就可以通过灰度发布完成全量更新。

  • 多语言技术栈统一治理,充分发挥多语言技术栈在微服务架构中的优势。

2019 年,网易落地 Service Mesh 2.0

Service Mesh 1.0 的落地虽然带来一定的好处,但是随着严选规模的变大和业务的复杂度,业务方对于基础架构的诉求也发生了变化,他们需要更灵活的流量调度、更多功能的服务治理、更大范围的基础组件解耦、更敏捷的快速迭代,更弹性的 IT 资源…而这些,现有架构并不能满足。

2019 年初,伴随以 Kubernetes、Envoy、Istio 为代表的云原生技术体系成熟,网易开始推动 Service Mesh 1.0 向云原生 Service Mesh 2.0 架构(代号:轻舟微服务)升级。经过 1 年的升级改造,轻舟微服务已经在严选落地。

Service Mesh 2.0 与 1.0 有啥区别

与 Service Mesh 1.0(cNginx)相比,Service Mesh 2.0(轻舟)最大的不同在于全面拥抱云原生技术。底座采用 Kubernetes,通过容器化和混合云基础设施解决快速迭代和 IT 资源弹性的问题。同时对基础组件做了升级,数据面组件采用 Envoy,控制面组件采用 Istio。

落地三年,两次架构升级,网易 Service Mesh 实践之路

轻舟的 Sidecar 在部署架构上采用 per-pod 模式,取代了 cNginx 的 per-node 模式,per-pod 在隔离性、安全性、扩展性、升级风险等方面更加友好。此外,cNginx 只开启 client-sidecar,只拦截 Outbound 流量,为了充分发挥 Service Mesh 架构的优势,轻舟启用 both-sidecar 注入,在安全、遥测、路由、限流、故障注入、负载控制等方面能力更加完整。对于业务方最关心的请求延时问题,轻舟通过 SR-IOV 网络增强、eBPF 短路 socket、xDS 协议优化等方式增强容器网络和数据面性能,使延时降低 100% 以上。

Service Mesh 2.0 的技术选型

Service Mesh 2.0 是基于 Istio+Envoy 构建的,为什么会是这样的技术选型呢?

冯常健表示:“其实在选型之前,我们也做了很多调研工作,基于标准化、扩展能力、技术风险、研发成本等多种因素,综合考虑了很多开源或自研方案,之所以选定 Istio+Envoy,主要是因为以下四种原因。”

  1. Istio 和 Envoy 都是云原生社区开源产品。云原生是下一个技术浪潮,面向云原生的架构可以快速获得社区的技术红利,而且云原生社区活跃度高,版本迭代快。

  2. Envoy 拥有不低于 Nginx 的转发性能,但在治理能力和控制能力(UDPA)方面,却比 Nginx 灵活得多。Istio 是 Envoy 的黄金搭档,作为从 Kubernetes 上长出来的原生 Service Mesh 控制面框架,比较亲和容器化场景。

  3. Envoy 支持协议和插件扩展,以满足除 HTTP 之外的其他 L4/L7 协议,Istio 也可以通过 MCP 和 API 能方式扩展控制面对注册中心、配置中心、CRD 的支持。这种丰富的扩展能力不仅能够实现 Service Mesh,将来也能实现 DB Mesh、Redis Mesh 等等。

  4. 近几年,Kubernetes 通过工作负载和 CRD 抽象给基础设施系统设计带来了巨大变革,Istio+Envoy 对微服务流量和服务治理的良好抽象,让我们可以看到了通过 Service Mesh 来统一服务层系统设计的可能性。对集团来说,统一服务化层的技术栈,沉淀技术资产实现跨事业部的复用,能够极大降低研发成本。

实践 Service Mesh 还有哪些问题?

作为 Service Mesh 实践者,对于想要实践 Service Mesh 的企业,冯常健给出了以下三个建议:

首先,要充分认识到 Service Mesh 架构改造的必要性,想清楚当前技术架构的痛点在哪,用 Service Mesh 解决什么问题,能为自己的业务带来什么样的价值;

其次,要审视当前的组织文化。Service Mesh 作为一个统一的服务治理层,汇聚了大量原本其他技术平台的能力,必然会涉及到对基础技术平台和周边系统的改造。这时候尤其需要技术管理者制定战略目标,为开发、架构、运维等多个团队通力配合扫清障碍,这是预判 Service Mesh 能否落地的重要因素。

最后,关于 Service Mesh 演进路径问题。微服务化是前提,业务系统没有完成微服务化改造,就不存在 Service Mesh 建设的基础。微服务化架构下,我认为先完成容器化改造和完善周边平台 (全链路监控、日志平台、CI/CD) 建设之后,再进行 Service Mesh 演进是一条稳妥的路径,否则在系统运维效率和服务稳定性方面存在极大风险。当然,对于没有能力成立基础架构团队的企业来说,外采云厂商提供的成熟产品和咨询也是一个替代方案。

从整个业界的发展趋势来看,Service Mesh 正处于 Gartner 技术成熟曲线中的期望膨胀期。冯常健表示,目前 Service Mesh 发展呈现两个特征:

  • 观众多,选手少。Service Mesh 技术在业界关注度高,当人们谈论微服务架构的时候,必不可少都会谈 Service Mesh,但是目前看到的落地实践均出自互联网头部公司,大公司资源充足愿意投资技术,IT 基础设施完善,有技术沉淀,能应付 Service Mesh 的复杂性,而中小型公司和传统企业基本还处于观望状态。

  • Service Mesh 技术的商业价值还处于探索阶段。几乎所有的云厂商都提供 Service Mesh 服务,但是目前这种云服务同质化严重,缺少场景化的产品形态封装,难以满足用户对于平滑演进的诉求,未来需要依靠更多贴近业务的最佳实践来打磨产品。

Service Mesh 架构虽然通过业务和基础平台的解耦降低了整体服务化术栈的熵,但是却增加了其所在的基础平台本身的复杂性,除了数据面性能需要持续优化之外,控制面组件的运维复杂性、可观测性欠佳引起的排障困难、Sidecar 对中间件 Mesh 场景的支撑能力等都是 Service Mesh 未来发展需要解决的问题。

评论

发布