江苏龙网

  1. 首页 > 人文 > >

Service Mesh：调度千军万马微服务，2.0妥妥的

冠望发自凹非寺
量子位报道|公众号QbitAI
过去一年 ， 继Kubernetes风靡 ， ServiceMesh已成功上位变成当之无愧的技术网红 。
TA不但可以极大简化用户使用体验 ， 还将大中型企业的Kubernetes落地引向“实处” 。
对于绝大多数使用容器的企业来说 ， 似乎一夜之间 ， ServiceMesh就成长为完善容器部署的功能担当 ， 不容小觑 。
并被一度当作云原生技术栈的关键组件之一 ， 人称“新一代微服务架构” ， 即2.0版本 。
从逻辑出发 ， 如果想聊透ServiceMesh ， 还是要先谈谈微服务的 。
用维基百科的话说 ， 所谓微服务 ， 可被定义为一种软件架构风格 。
这个风格比较专注单一责任与功能的小型区块 ， 利用模块化的方式组合出复杂的大型应用程序 。
在此过程中 ， 各功能区块的使用与语言无关的API集达成相互通信 。
简单来说 ， 在云原生微服务的模式下 ， 哪怕是单个应用也可能由数百个服务组成 。
此基础上 ， 每个服务又包含多达上千个实例 。
如果你真想抽丝剥茧一下下 ， 其实每个实例又很有可能被像Kubernetes这样的服务调度器不断调度 ， 而产生千变万化的形态 。
尽管形态复杂多样 ， 但端到端通信的可靠性与性能优势却始终至关重要 。
这时候ServiceMesh就派上了用场 。
本质上就是将服务间的通信从无法发现与控制的基础设施中分离出来 ， 并达成监控、管理与控制的目标 。
显而易见 ， 关于ServiceMesh的定义 ， 广泛被接受的一种 ， 是控制应用程序不同部分彼此共享数据的方式 。
Service Mesh：调度千军万马微服务，2.0妥妥的
文章图片

作为一个专门让服务与服务之间的通信变得安全、快速以及可靠的基础设施 ， ServiceMesh确实可以做到通过服务通讯 ， 让整个架构更为先进和CloudNative 。
在某些方面 ， 这有点儿像网络七层模型中的第四层TCP协议 。
但与TCP不同的是 ， TA想要达成的目的不仅仅是正常的网络通讯 。
还着力为应用提供了统一的 ， 可视化的以及可控制的控制平面 。
如果追根溯源 ， ServiceMesh并不算是什么新技术；如果一定要说创新的话 ， 更多则是功能所在位置的改变 。
实践证明 ， ServiceMesh确实可高效做到屏蔽分布式系统通信的复杂性 ， 只关注业务逻辑 。
对于服务语言没有限制 ， 只需和ServiceMesh通信即可 。
更重要的是 ， 对应用透明 ， 组件可单独升级 。
止步于开源 ， 那些鼎鼎大名的servicemesh项目数一数
从2016年1月 ， 业内第一个开源项目Linkerd发布 ， “ServiceMesh”首次在公开场合被使用；到控制平面概念及作用被人们认可并接受以至于到今天 。
我们发现热闹归热闹 ， 虽然如火如荼 ， 但还尚未出现完全现成的商业产品 。
大部分的ServiceMesh仅仅止步于开源项目 ， 例如现在比较知名的Linkerd、Istio等 。
1、2、3 ， 那就从Linkerd说起吧！
Linkerd最初是由Buoyant团队在2016年打造的一个服务网格项目 。
从Twitter开发的library中分离出来并由Scala语言编写 ， 设计理念是支持基于主机（物理主机或者虚拟节点）的部署模式 ， 算是开源项目中资历比较深厚的 。
有关资料显示 ， Conduit ， 也是该领域另一位颇具影响力的选手 ， 多年前已成功合并到Linkerd项目 ， 并在2018年7月发布为Linkerd2.0版本 。
关于Conduit的研发初衷 ， 很多人总结为是由于最初版本的内存占用问题广受诟病 ， 所以Conduit确实表现更加轻量级 ， 为Kubernetes定制 ， 用Rust和Go语言编写 ， 但与当下广泛提及的Istio相比 ， 依旧不在一个数量级别上 。
但更多人认为 ， Buoyant是意识到继续同时支撑Linkerd1.x和Conduit两条产品线已经不合时宜 ， 此外Linkerd1.x无论是在数据平面还是控制平面上表现都很堪忧 。
所以 ， 合并产品线并保持品牌效力更关键 。
可喜的是 ， 从1到2 ， 我们发现Linkerd2.x主要基于Kubernetes ， 而Linkerd1.x则可以基于节点模式部署 ， 当面临复杂环境的场景时 ， 开发者完全有更灵活的选择方向 ， 对部署更是恰到好处 。
就在2018年12月 ， Linkerd2.1也顺势被发布 ， 推出了路由级的遥测能力 。
更重要的是 ， 此次发布率先提出了ServiceProfile概念 ， 以服务为中心 ， 将服务相关的大量CRD聚合统一 ， 这对服务网格的管理助力不小 。
伴随发展 ， 2017年1月 ， 开源的ServiceMesh软件Linkerd就正式加入了云原生基金会 ， 成为云原生基金会的官方项目并至今影响深远 。
但从近些年掌握的发展情况来看 ， 面对出身豪门的网红Istio以及在数据平面上表现优越的Envoy ， Linkerd更多是力不从心 ， 想要改变其现状 ， 恐怕还需在战略敏感度以及技术升级上做做功课 。
如果说Linkerd是服务网格的开山鼻祖 ， 那Istio可谓是目前这个领域实实在在的“流量大花” 。
由Lyft、IBM与google联合开发的Istio ， 相比Linkerd、Envoy这些典型的服务网格 ， 提供了一个更加完整的解决方案 ， 包括行为洞察以及操作控制在内 ， 主要用来满足微服务应用程序的多样化需求 。
所以 ， Istio是一个服务网格没错 ， 但又不仅仅是服务网格那么简单 。
具体来说 ， TA可以做到在不修改微服务源代码的前提下 ， 轻松为其添加负载均衡、身份验证等强功能 ， 并通过控制Envoy等代理服务来控制所有流量 ， 其中Istio基于Envoy代理并以之为数据层（dataplane） 。
另外 ， Istio还提供了容错、金丝雀部署、A/B测试、监控等功能 ， 甚至可以支持自定义的组件和集成 ， 对此官方有云：
流量管理：控制服务之间的流量和API调用的流向 ， 使得调用更可靠 ， 并使网络在恶劣情况下更加健壮 。
可观察性：了解服务之间的依赖关系以及它们之间流量的本质和流向 ， 从而提供快速识别问题的能力 。
策略执行：将组织策略应用于服务之间的互动 ， 确保访问策略得以执行 ， 资源在消费者之间良好分配 。 策略的更改是通过配置网格而不是修改应用程序代码 。
服务身份和安全：为网格中的服务提供可验证身份 ， 并提供保护服务流量的能力 ， 使其可以在不同可信度的网络上流转 。
总之一句话 ， Istio极大的减少了应用程序代码 ， 底层平台和策略之间的耦合 ， 使微服务更容易实现就对了！
作为各种技术前沿会议中备受瞩目的创新技术 ， 世界范围各主流云平台都对Istio伸出了橄榄枝 ， 比方说IBMCloudKubernetesService以及RedHat创建了一个名为Maistra的社区项目等 。
但不难发现的一点 ， 虽说Istio是如今最炙手可热的服务网格 ， 但实际落地的生产场景并不多 ， 更多是选择在测试环境中试用 ， 其应用价值确实受到某种限制 。
对此专业人士持这样的观点：原本使用像Istio这样的服务网格是为了希望能够降低微服务管理或者治理复杂度 ， 更好观测运行状况 ， 更容易完成熔断限流 ， 进行灰度发布等 。
但在实际操作中 ， 我们会发现非但没有降低微服务的复杂度 ， 反而是引入了一个同样复杂的技术 。
是否应该将一些主线变成单体应用去做统一部署 ， 从而降低servicemesh管理控制平面本身的使用和维护的复杂度呢？
事实上 ， 最近数月Istio接连发布了1.5和1.6版本 。
相比2018年-2019年度的频繁更新 ， 大多只涉及到错误修复和性能改善 ， 未带来新的特性的情况 ， 目前的1.5版本算是重大变革之一 。
该版本似乎回应了社区里关于Istio性能和易用性的诟病 ， 重建了新架构即回归单体 。
具体来说 ， 由原来更分散的微服务架构、控制平面做了一些收缩与整合 ， 变为一个更加集中的方式 。
将过去一些过于复杂的分散式组件 ， 集中到了Istio核心的控制平面中 ， 从而降低了使用管理的难度系数 。
另外 ， 以前的mxier组件 ， 在1.5版本中被移除 ， 该能力通过其他方式来实现 ， 组件删减之后也对性能方面带来显著提升 。
总体来说 ， 就是提升性能并降低复杂度 ， 从而让用户能够更容易去采纳这样的新技术 。
回顾Istio的一路走来 ， 如何打破叫好不叫座的局面 ， 真正实现生产环境落地的意义 ， 可能是未来很长时间都需要证明自己的事儿 。
相比Istio的任重道远 ， 作为Istio中的Sidecar官方标配 ， Envoy也有很吸睛的表现 。
Envoy ， 由Lyft创建 ， 为了直击完整的ServiceMesh功能 ， 它牢牢占据了“数据平面”的部分 ， 与其进行匹配 。
【Service Mesh：调度千军万马微服务，2.0妥妥的】作为一个面向服务架构的高性能网络代理 ， Envoy由C++语言实现 ， 拥有较为强大的定制化能力 。
主要通过其提供的Filter机制 ， 基本可以对请求转发过程中超过50%的流程做定制化 ， 在性能方面由于其实现参考了Nginx ， 也处于主流水平 。
其作为Sidecar其提供的核心功能可以被简单总结：对业务透明的请求拦截；对拦截请求基于一定规则做校验、认证、统计、流量调度、路由等 。
其中对于请求校验规则的多与少、遥测数据的采集精细度、数据统计的维度多样性等算是复杂性需求的展现 。
因此最有可能提升Sidecar性能的技术方向 ， 就是对请求的拦截与Sidecar之间通讯协议的高效性 。
目前Envoy被越来越多企业使用 ， 不但稳稳占据了Istio官配Sidecar的位置 ， 还在网络代理、负载均衡器上展露锋芒 。
甚至广泛被Istio之外的多家企业ServiceMesh框架项目采用 ， 明显有成为ServiceMesh的数据平面“风向标”的倾向 。
2017年9月 ， Envoy加入CNCF ， 成为CNCF的第二个ServiceMesh项目；2018年11月 ， CNCF宣布Envoy毕业 ， 成为继Kubernetes和Prometheus后 ， 第三个孵化成熟的CNCF项目 ， 前景乐观 。
当然 ， 除了这些传统的开源项目外 ， ServiceMesh竞争版图中也陆陆续续迎来了各种企业级的参与者 ， 例如Nginmesh 。
来自名声在外的nginx ， 作为2017年9月对外宣布的一款产品 ， 适用于Istio的方案 ， 本质上就是使用NGINX作为sidecar来替换Envoy 。
另外 ， Consul来自HashiCorp公司 ， 主要功能是服务注册和服务发现 ， 以及作为一个从API网关演变而来的servicemesh产品 ， 名叫Kong等 。
关于ServiceMesh技术 ， 这些大企业代表都有何频频动作？
如上文所言 ， ServiceMesh确已席卷全球 ， 过去一年时间中 ， 已有多家公司竞相推出自己的ServiceMesh产品和方案 ， 例如AWS ， 就是引人注目的一家 。
去年4月 ， AWS震撼宣布了AppMeshGA 。
AppMesh作为AWS推出的AWS原生服务网格 ， 与AWS完全集成 ， 主要组件包括：网络（AWScloudmap）；计算（AmazonEC2和AWSFargate）以及编排工具（AWSEKS ， AmazonECS和EC2上客户管理的k8s） 。
值得提及的一点 ， AppMesh的数据平面采用Envoy ， 产品同时支持VM和容器并支持多种产品形态 。
适用于AmazonECS、AmazonEKS和KubernetesonEC2 ， 另外还支持开源Envoy代理 ， 本质上帮助开发人员监控以及控制跨微服务的通信 。
具体来说 ， 使用AppMesh来建模的所有微服务的连接方式 ， 都会自动计算并向每个微服务代理发送相应的配置信息 。
这样就达成了跨整个应用的程序标准化 ， 以及易用性与流量控制等要求 。
相比AWS青睐Envoy ， Google的打法则是围绕Istio 。
最初 ， Google在2018年底推出了IstioonGKE ， 并提供遥测、日志、负载均衡、路由等能力 。
接着又推出了GoogleCloudServiceMesh 。
作为Istio的完全托管版本 ， 不仅仅提供开源版本的完整特性 ， 还集成了GoogleCloud上的重要产品Stackdriver 。
旨在解决企业中增长最快的成本问题之一 ， 即跨混合环境的管理复杂性 。
随后 ， Google拿出了TrafficDirector的beta测试版本 ， 被定义为完全托管的服务网格流量控制平面 。
不但支持全局负载均衡 ， 适用于虚拟机和容器 ， 还提供混合云和多云支持、集中式健康检查和流量控制；此外还有一个非常特别的特性 ， 支持基于流量的自动伸缩 。
对比Google的高调支持 ， 微软更聚群力 ， 推出了ServiceFabricMesh 。
据了解 ， AzureServiceFabric是Microsoft的微服务框架 ， 最初设计用于公共云 ， 内部部署以及混合与多云架构 。
而ServiceFabricMesh是Azure完全托管的产品 ， 于2018年8月推出预览版 。
此外微软还在KubeConf上推出ServiceMeshInterface ， 作为在Kubernetes上运行服务网格的规范 。
SMI定义了由各种供应商实现的通用标准 ， 使最终用户的标准化与创新可以做到兼顾 ， 预期为ServiceMesh带来了灵活性和互通性 。
据悉SMI作为一个开放项目 ， 由微软、Linkerd、HashiCorp、Solo、Kinvolk和Weaveworks联合启动 。
并同时得到了AspenMesh、Canonical、Docker、Pivotal、Rancher、RedHat和VMware等多家的大力支持 。
相比之前几家的声势浩大与首屈一指的知名度 ， 服务网格领域另一家值得提及的供应商是Tetrate 。
作为一家总部位于旧金山的创业公司 ， TA与Google渊源颇深 ， 是由GoogleIstio项目的一些主要工程师组成 。
据了解 ， 很长一段时间内他们正在着力开发一个独立的企业级服务网格 ， 主要为了减轻在混合或者大规模复杂环境中运行微服务带来的管理复杂性 。
Tetrate曾承诺将Istio和Envoy的开源产品与企业级功能相结合 ， 允许在复杂的企业环境中运行数据和控制平面 ， 这意味着“企业级可扩展性、可伸缩性和性能” 。
“我们正试图简化Istio配置的复杂性 。 ”Tetrate方面表示 。
当然 ， 如果放眼国内企业 ， 包括阿里DubboMesh、腾讯的TencentServiceMesh ， 华为Mesher与ASM、Rancher2.3Preview2版本上开始支持Istio以及网易云轻舟微服务基于开源Istio推出服务网格（ServiceMesh）平台等在内的多家企业也分别针对ServiceMesh有了个性化的技术尝试 。
阿里DubboMesh
Dubbo作为阿里巴巴内部SOA服务化治理方案的核心框架 ， 在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持 ， 并被广泛应用于各成员站点 。
甚至自2011年开源后 ， 已被许多非阿里系公司使用 ， 最后带来服务治理和SOA的设计理念开始逐渐在国内软件行业中落地并被广泛应用的大风潮 ， 可谓影响深远 。
简单理解DubboMesh ， 就是servicemesh作为云原生组织定义的微服务架构解决理念 ， Dubbo则是实现框架的意思 。
有资料显示 ， 目前DubboMesh主要包含Bonder、Pilot、Envoy三个进程 ， 以及被轻量化的ThinSDK 。
具体来说Envoy承担了数据平面的角色 ， 所有流量将由它完成服务发现与路由而中转 。
Pilot和Bonder则共同承担控制平面的角色 ， 实现服务注册、进程拉起与保活、集群信息和配置推送等功能 。
ThinSDK是FatSDK经过裁剪后只保留了对Dubbo协议进行编解码的能力 。
迄今为止 ， Dubbo应该是国内比较受到欢迎的远程服务框架 ， 也是阿里分布式架构相互连通的核心所在 。
腾讯TencentServiceMesh
TSFMesh作为腾讯微服务平台（TSF）的ServiceMesh解决方案 ， 从2018年8月推出首个版本以来 ， 已经陆续在金融、新零售、工业互联网以及公司内部等生产环境落地 。
TSFMesh整体架构上 ， 其核心能力与开源的Istio保持一致 ， 同时对envoy、Pilot、Mixer、Pilot-agent组件做了增强 ， 并且新增组件Apiserver和Mesh-dns 。 其外围能力聚焦在安全性、易用性、可维护性和可观测性 。
TSFMesh拥抱开源协同 ， 努力跟进ServiceMesh的技术发展趋势 ， 但就技术发展趋势而言 ， 比如控制面单体化 ， UDPA（通用数据平面API）的标准化演进 ， wasm在envoy中扮演的角色以及mixer下沉 ， 协议扩展 ， 性能优化等都是未来亟待探讨的技术关键 。
Rancher2.3
Rancher的理念是RunKubernetesEverywhere ， 其中关于Istio的支持创新也正是让该理念实现又大步向前了一个阶段 。
据悉 ， Rancher2.3Preview2版本上开始支持Istio ， 用户可以直接在UI界面中启动Istio并且可以为每个命名空间注入自动sidecar 。 具体来说 ，
Rancher内置了一个支持Kiali的仪表盘 ， 简化Istio的安装和配置 ， 这一切让部署和管理Istio变得简单而快速 。
“Rancher严格来说是一个单体应用 ， 我们的server架构 ， 它是一个集中式的 ， 其中有很多不同的服务 ， 比方说Rancher的UI、Rancherserver的核心控制进程、catalog、ContainerEngine对接基础设施等 。 将其全部打包到一个镜像中去再进行统一运行的话 ， 管理升级就会变得额外简单 。 ”Rancher方面表示 。
网易云轻舟微服务推出的服务网格平台
轻舟微服务基于开源Istio推出服务网格（ServiceMesh）平台 ， 可以提供完整的微服务生命周期管理、流量管理和非侵入式的服务治理解决方案 。
支持熔断、降级、流控、负载均衡、容错、高级路由等服务治理功能 ， 同时摆脱服务开发框架和开发语言的束缚 。
具体来说 ， 平台可以通过统一的微服务模型 ， 帮助将现有的微服务架构平滑迁移到服务网格 ， 并针对数据面引入Sidecar导致延时增加的问题 ， 持续优化数据面 ， 相比开源方案服务延时降低100%以上 。
支持无侵入的监控数据采集 ， 实时获取健康状态；支持容器化和非容器化的部署 ， 打破服务网格开源版本“偏科”容器的限制 。
华为Mesher与ASM
ServiceComb是一个java与go语言的微服务编程框架 ， 而华为Mesher则是基于华为开源的ServiceComb 。
从发展目标来看 ， Mesher并不只支持Kubernetes ， 而是支持任意的基础设施 ， 包括容器 ， 虚拟机等 ， 这一点类似于网易云的服务网格尝试 。
此外 ， 华为云Istio团队在生态上投入了很大力量 ， 并基于Istio发布了自己的ASM（ApplicationServiceMesh） ， 深度集成华为云容器服务CCE(CloudContainerEngine) ， 提供非侵入的智能流量治理解决方案 。
蚂蚁金服SOFAMesh+SOFAMosn
蚂蚁金服的ServiceMesh解决方案主要包括SOFAMesh以及SOFAMosn 。
其中SOFAMesh是蚂蚁金服推出的ServiceMesh开源产品 ， 可以简单理解为是Istio的落地增强版本 。
作为蚂蚁金服ServiceMesh的控制平面 ， 跟随社区保持同步更新 ， 还提供了多租户的支持 。
SOFAMosn ， 被称为蚂蚁金服新型基础设施和中间件的底层网络通用解决方案 ， 具备多种产品形态 ， 基于Golang开发 。
在蚂蚁金服ServiceMesh中承担数据平面的角色 ， 和SOFAMesh项目配合使用 ， 兼容Istio体系 。
ServiceMesh技术在蚂蚁金服的落地 ， 其实先后经历过几个阶段：
预研阶段：2017年底开始调研并探索 ， 确定方向 。
探索阶段：2018年初 ， 开始用Golang开发SidecarSOFAMosn ， 年中开源基于Istio的SOFAMesh 。
小规模落地阶段：2018年开始内部落地 ， 替代Java语言之外的其他语言的客户端SDK ， 之后开始内部小范围试点 。
规模落地阶段：2019年上半年 ， 作为蚂蚁金融级云原生架构升级的主要内容之一 ， 逐渐拓展到蚂蚁金服内部的业务应用并平稳支撑大促 。
全面大规模落地阶段：2019年下半年 ， 全面铺开并落地规模庞大 。
分析各家的DIY情况 ， 我们发现在数据平面上 ， 大多数选择了Envoy；在控制平面上除了自行开发之外 ， 很大程度上依旧依赖Istio进行扩展和订制 。
总体上 ， 国内ServiceMesh的发展情况呈现出“多方参与 ， 多种落地与探索 ， 都有符合自身特点的ServiceMesh产品出炉 ， 技术社区反响热烈”等态势 。
但从技术层面上 ， ServiceMesh目前也面临不少的问题与挑战 。
ServiceMesh用起来会面临哪些问题？
首先服务网格是一个平台解决方案 ， 十分排他 。
这意味着需要在服从方式与业务考量上进行艰难取舍 ， 前期成本消耗会十分昂贵 。
除了在理念上的矛盾之外 ， 服务网格的部署将架构引入不小的复杂性 ， 过程中需要与现有的环境进行整合并反复配置 。
例如ServiceMesh组件以代理模式计算并转发请求 ， 一定程度上会降低通信系统性能并增加资源开销 。
随着网格的扩张和路由表的膨胀 ， 通过一系列代理进行的路由通信将慢的痛苦异常 。
此外 ， 由于组件接管了网络流量 ， 因此服务的整体稳定性都会大概率依赖于ServiceMesh ， 额外引入的ServiceMesh服务实例 ， 其运维和管理也是挑战之一 。
尽管应用艰难且挑战重重 ， 但人们对将服务网格作为基础设施的关键部分 ， 所激发出的兴趣和亟待采用计划 ， 正在迅速赶上甚至超越容器 。
无论企业体量大小 ， 未来服务网格的使用迫切度都会显著增长 。
在此基础上 ， Istio之于服务网格会类似于K8S之于容器的地位 ， 一骑绝尘 ， 毕竟纵观生态系统的成熟度 ， Istio还是非常有竞争力的 。
此外 ， 2020年或将出现核心服务网格用例 ， 并将成为下一批使用者实施的参照 。
可想而知 ， 如果正在使用服务网格 ， 其价值会越发显现；如果已经考虑入局其中 ， 未来的机会颇多也是意料之中的事儿 。


    推荐阅读


    上一篇：厉害了！山东诞生最强国产芯片巨头！投资高达188亿元

    下一篇：年轻人全能5G新选：星空银配玻璃机身 华为畅享20 Pro美出新高度