写点什么

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

2020 年 4 月 08 日

落地三年,两次架构升级,网易 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。



举个例子,如果运维人员要对某服务进行流控设置,只需通过服务治理平台将流控参数下发到 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。



轻舟的 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 未来发展需要解决的问题。


2020 年 4 月 08 日 08:285504
用户头像
田晓旭 InfoQ 编辑

发布了 497 篇内容, 共 234.0 次阅读, 收获喜欢 1613 次。

关注

评论

发布
暂无评论
发现更多内容

Go语言实现的23种设计模式之结构型模式

华为云开发者社区

设计模式 组合模式 go语言 结构型模式 适配器模式

一篇文章告诉你 GIS 存储如何选?

焱融科技

技术 分布式 云原生 高性能 容器存储

年份白酒推荐 商务聚会我选唐庄五星酒

Geek_50a546

Mysql是如何选择主键的

架构精进之路

MySQL 6 月日更 主键

3年Java经验硬核通过京东面试(已获Offer),谁说专科不能进大厂?

神奇小汤圆

Java 程序员 架构 面试

TcaplusDB华东客户Hands-on活动|10分钟玩转腾讯游戏核心数据库

数据人er

数据库 nosql tencentdb TcaplusDB

chia奇亚算力挖矿分发APP系统开发

薇電13242772558

区块链

8种图数据库对 NULL 属性值支持情况

华为云开发者社区

图数据库 null 逻辑 语义网 图模型

并发王者课-铂金3:一劳永逸-如何理解锁的多次可重入问题

技术八点半

Java 多线程 并发

联邦学习这件小事(二)

趣链科技

区块链 隐私保护 加密技术 联邦计算

JAVA面向对象(八)--封装

加百利

后端 Java· 6 月日更

项目管理100问 | 为什么你的项目进度总是在延期?

万事ONES

项目管理 项目排期 ONES 项目开发

「Adobe国际认证」Adobe Photoshop软件,如何绘制对称图案?

Adobe国际认证

react源码解析16.concurrent模式

全栈潇晨

react.js

FIL币价大跌,是旷工最佳的入场窗口期吗?

IPFS8822

IPFS 区块链应用 ipfs怎么投资?

曝光一个网站,我周末就耗在上面了。

why技术

Arthas Java·

并发王者课-铂金4:令行禁止-为何说信号量是线程间的同步利器

技术八点半

Java 多线程 并发

[译] R8 优化: 字符串操作

Antway

6 月日更

智能边缘时代 英特尔携手极视角赋能开发者 助推AIoT发展

新闻科技资讯

云算力挖矿系统APP模式开发方案

系统开发咨询:I76-883I-5I52 邓森

详解Apache Dubbo的SPI实现机制

vivo互联网技术

dubbo 服务器 spi

长春大学旅游学院,加入ACA世界大赛,打造"实习+就业+创业"平台

Adobe国际认证

Git标星25K,美团大佬私藏的SpringSecurity笔记,堪比教科书级

神奇小汤圆

Java 架构 面试 微服务

618大促又来了?3天2次大事故,不堪回首的加班经历……

数列科技

压力测试 全链路压测 大促 系统高可用 生产环境全链路压测

敏捷 vs 瀑布

星际行者

敏捷开发

百度一款前端图片合成工具库MI开源啦!

百度开发者中心

百度 开源 图片

做项目管理,如何对复杂的项目工作进行分解

万事ONES

需求管理 ONES 项目管理工具

掌握鸿蒙轻内核静态内存的使用,从源码分析开始

华为云开发者社区

鸿蒙 操作系统 内存 静态内存 鸿蒙轻内核

索信达控股:解析索信达模型管理利器

索信达控股

模型 风险管理 智能 人工智能大数据 数据管理平台

ZGC 新特性

meacial

ZGC JVM 软件开发 Java·

英特尔谢晓清:开源是软件发展趋势

新闻科技资讯

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