江苏龙网

  1. 首页 > 人文 > >

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

作者丨田晓旭
嘉宾丨冯常健
当ServiceMesh从概念期进入到应用期时 ， 大家的关注重点都会转向先锋企业的落地实践 。 为了帮助大家在实践中“避坑” ， 我们采访了多家互联网企业的应用实践 ， 例如美团点评、同程艺龙以及瓜子二手车等 ， 本文将和大家分享的是网易的ServiceMesh实践 。 今年6月 ， 本文采访嘉宾冯常健将在QCon全球软件开发大会（北京站）2020上分享题为《网易基于Istio的ServiceMesh2.0架构升级实践》的演讲 ， 感兴趣的同学可以关注一下 。
2016年 ， 网易的部分业务严选、传媒等率先开始探索使用ServiceMesh架构支撑微服务体系建设；2017年 ， 网易开始落地ServiceMesh1.0 ， 代号cNginx；2019年 ， 由于ServiceMesh1.0在管控能力和流量治理等方面的不足 ， 网易开始基于定制Istio和扩展Envoy落地云原生Mesh2.0 ， 代号轻舟微服务 。 经过1年的升级改造 ， 轻舟微服务已经在严选落地 。
1传统微服务架构与ServiceMesh
大多数企业的ServiceMesh实践都不是从零开始 ， 而是在原有微服务架构的基础上进行改造转型 。 那么 ， 传统微服务架构在转型过程中会面临哪些问题？转型之后 ， 企业内部不同角色的技术人员需要做出哪些改变？
传统的微服务框架以RPC通信框架为基础 ， 提供服务目录、注册发现、服务治理、流量管理、配置中心、全链路追踪等核心能力 ， 并且向外延伸到安全审计、监控告警、统计分析、知识库等平台化能力 。
冯常健表示：“服务框架在微服务架构中占据核心位置 ， 因此 ， 使用ServiceMesh来替换正在使用的微服务框架 ， 无异于一次‘换心手术’ 。 ”
以网易为例 ， 他们的关注点在于如何在不中断业务的情况下 ， 逐步将微服务架构支撑能力下沉到ServiceMesh架构里 。 想要实现平滑过渡 ， 除了需要在ServiceMesh数据面和控制面组件中对服务注册发现、RPC协议、配置下发进行扩展之外 ， 还要对现有的上层研发工作台、运维效能平台等支撑平台进行兼容设计 ， 避免支撑平台等基建重复建设 。
在部署架构方面 ， ServiceMesh比传统微服务框架多了一层Sidecar ， 且服务治理是基于流量的 ， 因此会带来一系列的问题和挑战 。
Sidecar的运维复杂性问题 ， 微服务架构支撑能力下沉后 ， 也把复杂性下沉到了Sidecar 。 Sidecar面临着频繁更新的问题 ， 但Kubernetes和Istio只解决了部分部署的问题 ， 因此如何在不影响业务的情况下热更新Sidecar成为了新的挑战；
性能问题 ， 某些对延时比较敏感的业务会对性能问题有较多顾虑 ， 迫切需要对服务与Sidecar、Sidecar与Sidecar之间的链路进行性能优化；
整体架构的可观测性和排障效率问题 ， 对业务方来说 ， 服务注册发现、服务通信等原本客户端可见的过程现在都成了黑盒 ， 在问题诊断和故障恢复方面需要更立体化的监控系统支撑 。
ServiceMesh实践会如何影响企业内部员工的工作内容呢？
传统模式下 ， 开发和运维会有比较清晰的边界 ， 开发人员负责服务运行稳定 ， 运维人员负责服务运行的基础设施稳定 。 而进入到云原生时代 ， 特别是容器化和ServiceMesh落地之后 ， 服务框架、服务治理、灰度发布等稳定性密切相关的能力都作为基础设施下沉了 ， 开发和运维的边界开始变得模糊 。 所以 ， 企业IT人员的职责也应该相应的进行重新划分 。
架构师及基础架构团队 ， 新的职责要求他们必须要非常理解业务 ， 清楚地知道业务的服务依赖和服务治理规则 ， 故障后能从业务视角进行排障和快速恢复 。 同时 ， 他们还需要重新审视现有的技术架构和支撑平台建设 ， 从业务视角出发进行设计 ， 避免做出来的技术平台无法满足业务需求 ， 或者不好用 。
开发人员 ， 原先开发人员要关注很多方面 ， 例如服务框架、服务治理、环境一致性、遥测数据、客户端SDK版本升级等等 ， 而现在 ， 以上这些几乎统统不用关注 ， 只需要专注于业务本身的逻辑开发；
运维人员 ， 依托于ServiceMesh打通的服务和基础设施边界 ， 以及对服务的统一抽象 ， 能够更好的从全局视角进行服务质量、依赖管理、容量规划、端到端监控等来保障产品稳定性 。
2网易的ServiceMesh实践
2016年 ， 移动互联网发展火热 ， 网易业务发展飞快 。 当时内部各事业部之间在服务化框架的应用方面差别非常大 ， DubboRPC框架、SpringCloud微服务框架、自研微服务基础设施都有 ， 较少考虑微服务架构支撑能力的复用问题 。
网易严选是2015年内部孵化、2016年对外发布的新业务 ， 没有太多的历史负担 ， 考虑到电商业务的复杂性 ， 其在微服务架构选型方面进行了慎重的思考 。
是否基于RPC框架提供服务治理？根据历史经验 ， 由于业务团队和基础架构团队的关注点和优先级不同 ， 推动RPC框架升级效率非常低 ， 业务团队担心服务稳定性受影响 ， 基础架构团队担心架构演进效率太低 ， 矛盾比较突出 。
【落地三年，两次架构升级，网易的Service Mesh实践之路】如何支持多语言？微服务时代多语言是趋势也是优势 ， 严选的核心业务是基于Java技术栈的 ， 但是还是有大量前端业务和运营业务是基于Node.js ， 另外还有不少业务是Python和C++技术栈的 。
基于开源项目还是自研？自研系统可掌控性较强 ， 但是会面临重复造轮子和项目生命力的问题 ， 基于开源定制是一条更好的落地路径 。
2017年 ， 网易落地ServiceMesh1.0
2017年 ， 网易严选业务首先开始落地ServiceMesh1.0（代号：cNginx）架构 。 在选型方面 ， 数据面采用了Nginx ， 控制面及注册中心采用Consul ， Nginx和ConsulAgent形成Sidecar 。 通过Nginx实现了负载均衡、环境路由、熔断降级和限流等服务东西向流量的管理 ， 通过Consul实现了服务注册发现、配置同步、指令下发等控制面流量下发 。 服务对外调用的流量都通过本地部署的Nginx 。
落地三年，两次架构升级，网易的Service Mesh实践之路
文章图片
举个例子 ， 如果运维人员要对某服务进行流控设置 ， 只需通过服务治理平台将流控参数下发到ConsulServer ， ConsulServer通过一致性协议将配置同步到集群所有ConsulAgent ， Nginx能Watch本地ConsulAgent ， 生成Nginx流控配置 ， 作用于服务间的东西向流量 。
Nginx+Consul提供的基础能力基本满足了业务和基础架构团队对服务治理的需求 。 ServiceMesh1.0最早是在网易邮箱、网易有钱和网易严选试点 ， 随着严选业务的快速发展 ， 2017年底 ， 就基本在严选全面落地了 ， 并发挥了重要作用 。
业务不改造即可接入服务治理能力 ， 对齐了跨团队间对服务治理的理解 ， 降低沟通协作成本 ， 提升了业务团队生产力 。
解耦了基础架构和业务服务化架构 ， 使得他们能够独立演进 。 业务团队聚焦业务开发 ， 基础架构团队推动中间件和框架的升级可以做到业务无感知 。 原本需要三个月才能落地的SDK版本升级 ， 现在只要两周就可以通过灰度发布完成全量更新 。
多语言技术栈统一治理 ， 充分发挥多语言技术栈在微服务架构中的优势 。
2019年 ， 网易落地ServiceMesh2.0
ServiceMesh1.0的落地虽然带来一定的好处 ， 但是随着严选规模的变大和业务的复杂度 ， 业务方对于基础架构的诉求也发生了变化 ， 他们需要更灵活的流量调度、更多功能的服务治理、更大范围的基础组件解耦、更敏捷的快速迭代 ， 更弹性的IT资源......而这些 ， 现有架构并不能满足 。
2019年初 ， 伴随以Kubernetes、Envoy、Istio为代表的云原生技术体系成熟 ， 网易开始推动ServiceMesh1.0向云原生ServiceMesh2.0架构（代号：轻舟微服务）升级 。 经过1年的升级改造 ， 轻舟微服务已经在严选落地 。
ServiceMesh2.0与1.0有啥区别
与ServiceMesh1.0（cNginx）相比 ， ServiceMesh2.0（轻舟）最大的不同在于全面拥抱云原生技术 。 底座采用Kubernetes ， 通过容器化和混合云基础设施解决快速迭代和IT资源弹性的问题 。 同时对基础组件做了升级 ， 数据面组件采用Envoy ， 控制面组件采用Istio 。
落地三年，两次架构升级，网易的Service Mesh实践之路
文章图片
轻舟的Sidecar在部署架构上采用per-pod模式 ， 取代了cNginx的per-node模式 ， per-pod在隔离性、安全性、扩展性、升级风险等方面更加友好 。 此外 ， cNginx只开启client-sidecar ， 只拦截Outbound流量 ， 为了充分发挥ServiceMesh架构的优势 ， 轻舟启用both-sidecar注入 ， 在安全、遥测、路由、限流、故障注入、负载控制等方面能力更加完整 。 对于业务方最关心的请求延时问题 ， 轻舟通过SR-IOV网络增强、eBPF短路socket、xDS协议优化等方式增强容器网络和数据面性能 ， 使延时降低100%以上 。
ServiceMesh2.0的技术选型
ServiceMesh2.0是基于Istio+Envoy构建的 ， 为什么会是这样的技术选型呢？
冯常健表示：“其实在选型之前 ， 我们也做了很多调研工作 ， 基于标准化、扩展能力、技术风险、研发成本等多种因素 ， 综合考虑了很多开源或自研方案 ， 之所以选定Istio+Envoy ， 主要是因为以下四种原因 。 ”
Istio和Envoy都是云原生社区开源产品 。 云原生是下一个技术浪潮 ， 面向云原生的架构可以快速获得社区的技术红利 ， 而且云原生社区活跃度高 ， 版本迭代快 。
Envoy拥有不低于Nginx的转发性能 ， 但在治理能力和控制能力（UDPA）方面 ， 却比Nginx灵活得多 。 Istio是Envoy的黄金搭档 ， 作为从Kubernetes上长出来的原生ServiceMesh控制面框架 ， 比较亲和容器化场景 。
Envoy支持协议和插件扩展 ， 以满足除HTTP之外的其他L4/L7协议 ， Istio也可以通过MCP和API能方式扩展控制面对注册中心、配置中心、CRD的支持 。 这种丰富的扩展能力不仅能够实现ServiceMesh ， 将来也能实现DBMesh、RedisMesh等等 。
近几年 ， Kubernetes通过工作负载和CRD抽象给基础设施系统设计带来了巨大变革 ， Istio+Envoy对微服务流量和服务治理的良好抽象 ， 让我们可以看到了通过ServiceMesh来统一服务层系统设计的可能性 。 对集团来说 ， 统一服务化层的技术栈 ， 沉淀技术资产实现跨事业部的复用 ， 能够极大降低研发成本 。
3实践ServiceMesh还有哪些问题？
作为ServiceMesh实践者 ， 对于想要实践ServiceMesh的企业 ， 冯常健给出了以下三个建议：
首先 ， 要充分认识到ServiceMesh架构改造的必要性 ， 想清楚当前技术架构的痛点在哪 ， 用ServiceMesh解决什么问题 ， 能为自己的业务带来什么样的价值；
其次 ， 要审视当前的组织文化 。 ServiceMesh作为一个统一的服务治理层 ， 汇聚了大量原本其他技术平台的能力 ， 必然会涉及到对基础技术平台和周边系统的改造 。 这时候尤其需要技术管理者制定战略目标 ， 为开发、架构、运维等多个团队通力配合扫清障碍 ， 这是预判ServiceMesh能否落地的重要因素 。
最后 ， 关于ServiceMesh演进路径问题 。 微服务化是前提 ， 业务系统没有完成微服务化改造 ， 就不存在ServiceMesh建设的基础 。 微服务化架构下 ， 我认为先完成容器化改造和完善周边平台(全链路监控、日志平台、CI/CD)建设之后 ， 再进行ServiceMesh演进是一条稳妥的路径 ， 否则在系统运维效率和服务稳定性方面存在极大风险 。 当然 ， 对于没有能力成立基础架构团队的企业来说 ， 外采云厂商提供的成熟产品和咨询也是一个替代方案 。
从整个业界的发展趋势来看 ， ServiceMesh正处于Gartner技术成熟曲线中的期望膨胀期 。 冯常健表示 ， 目前ServiceMesh发展呈现两个特征：
观众多 ， 选手少 。 ServiceMesh技术在业界关注度高 ， 当人们谈论微服务架构的时候 ， 必不可少都会谈ServiceMesh ， 但是目前看到的落地实践均出自互联网头部公司 ， 大公司资源充足愿意投资技术 ， IT基础设施完善 ， 有技术沉淀 ， 能应付ServiceMesh的复杂性 ， 而中小型公司和传统企业基本还处于观望状态 。
ServiceMesh技术的商业价值还处于探索阶段 。 几乎所有的云厂商都提供ServiceMesh服务 ， 但是目前这种云服务同质化严重 ， 缺少场景化的产品形态封装 ， 难以满足用户对于平滑演进的诉求 ， 未来需要依靠更多贴近业务的最佳实践来打磨产品 。
ServiceMesh架构虽然通过业务和基础平台的解耦降低了整体服务化术栈的熵 ， 但是却增加了其所在的基础平台本身的复杂性 ， 除了数据面性能需要持续优化之外 ， 控制面组件的运维复杂性、可观测性欠佳引起的排障困难、Sidecar对中间件Mesh场景的支撑能力等都是ServiceMesh未来发展需要解决的问题 。


    推荐阅读


    上一篇：英国自食恶果，当初强拒华为，如今民众都与世隔绝

    下一篇：英飞凌发布5G eSIM一站式解决方案 通过CC EAL4+的测试