作者：宗泉、宇曾
阿里巴巴三位一体战略
阿里云内部很早就提出了开源、自研、商业化三位一体战略，先谈谈我对它的理解。
多年的软件开发经验告诉咱们，开宣布一款出色的软件有一些要害要素：
- 交流
- 反应
- 实践
在软件开发进程中咱们不能闭门造车，不能随意“创造”事务场景需求。事务场景和产品功用需求提炼，开源给咱们供给了一个共同立异的渠道，依据这个渠道，咱们能够共同界说一些规范和规范。不同的厂商遵循相应的规范，客户就没有被确定的风险，能够不停地搬迁，总是能找到最好的厂商，将自己的事务放上去，用最简单、最便捷、最经济的方法来运营自己的事务。
很多客户在选择阿里云服务网格的时候，有一条比较重要的评判目标：是否和社区 Istio 兼容。由于客户担心被确定，强依靠于阿里云；
然后说到自研，也许有同学会问到，开源与自研是否互相矛盾，答案是否定的。
由于，咱们这儿说到的自研，其实是依据开源的自研，并非摒弃开源的版别，重新造个新的轮子。自研是指咱们要对开源产品有足够深度的理解：
- 要把握一切源代码；
- 具有修正每一行代码的才能
- 当然，自研还有意味着或许有自身事务特定独有的需求场景，一些没办法规范化的场景。
依据自研，对开源产品的深度把控和理解，咱们将有通用客户场景需求的功用搬到云上，封装成云产品，让云上客户能够开箱即用去运用，这是商业化的初心。
回到阿里集团内部，开源、自研、商业其实是一个技能飞轮。
关于阿里的技能同学来说，每年的 双11 都是一场“盛宴”。为了让顾客有顺滑的购物体会，给商户供给更多样化的让利活动，阿里电商渠道关于功率、可靠性、规划性的要求在 双11 的驱动下成倍进步，激发着技能人的潜力。作为根底技能中心之一，阿里巴巴中间件也会在每年 双11 迎来一次技能的全面演进和晋级。
阿里在开源社区中推出了 Dubbo、RocketMQ、Nacos、Seata 等多个为人熟知的开源项目，鼓励广大开发者共建中间件生态系统，也包含了 ServiceMesh 相关技能。
拥抱服务网格开源技能
阿里云内部很早就开端调研并实践 ServiceMesh 技能 。2018 年，Istio 正式发布 1.0 版别，进入大众视界。在这更早时期，阿里巴巴内部现已开端参与相关生态开源产品的奉献。
阿里云在微服务生态范畴，也有一些开源的服务化结构，比方 Dubbo 、Spring Cloud Alibaba，能够说微服务范畴，由于电商这层实验大渠道，阿里云在这方面是妥妥滴“技能专家”，咱们会进行横向功用比照，比照 Sidecar 形式和原有形式的优缺陷；在这进程中，咱们也积极参与 Istio 微服务相关生态项目的开源奉献；例如 Envoy、 Dubbo Filter 、RocketMQ Filter 、Nacos Mcp 功用、Spring Cloud Alibaba、Sentinel 等。
现在盛行着各种各样的服务结构，怎么依据不同的结构开发的可互通的事务？服务结构就像铁路的铁轨相同，是互通的根底，只有处理了服务结构的互通，才有或许完结更高层的事务互通，所以用相同的规范共同，合二为一并共建新一代的服务结构是必然趋势。
Dubbo 和 HSF 都是阿里巴巴内部在运用的微服务 RPC 结构。这些结构在阿里事务不断迭代开发的进程供给了坚实的底层微服务才能支撑，保证了一个又一个 双11 大促。
伴跟着云原生的浪潮，以及整体资源本钱优化、DevOps 等大布景下，原有微服务结构 Dubbo 、HSF 的一些缺陷也在慢慢露出出来，比方多语言的支撑，装备和代码逻辑别离等，SDK 版别晋级需求推动事务方，收购的事务选用不同结构互通的问题等。
阿里集团内部部分事务开端尝试运用服务网格技能来改造底层微服务结构，Dubbo 结构在 Mesh 化的进程中，阿里云服务网格团队奉献了 Envoy Dubbo Filter，就是为了完结原有 Dubbo 事务的 Mesh 化，以获得服务网格带来的新的增量价值。
另一方面，Dubbo 社区自身也在朝着云原生范畴往前迭代。Dubbo 从 Dubbo2.7.8 版别开端讨论 Dubbo 的云原生演进计划，为了更好地适配云原生场景 （根底设施的改变 Kubernetes 已成为资源调度编排的事实规范），Dubbo 团队现在在将 Dubbo 2.0 向 Dubbo 3.0 做技能演进，并提出了 Proxyless Mesh 的设计。
跟着事务逐渐上云，由于上云途径的多样以及从现有架构搬迁至云原生架构的过渡态存在，布置运用的设施灵敏异变，云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生依据敞开规范的共同协议和结构，以满意互通需求，这些场景，正式服务网格拿手的范畴，给了服务网格很好的发挥空间；
现在，Dubbo 3.0 社区版别已发布，中心改变有：
- 运用级服务发现
- Dubbo 2.0 协议演进为 依据 gPRC 的 Triple 协议
- 无 Sidecar 的 ProxylessMesh
Mesh 化不是一蹴即至，关于原有的存量事务类似事务上云，存在一个中间过渡阶段，传统微服务结构，例如：Dubbo 、Spring Cloud 等存量事务选用 Nacos、Eureka 、Zookeeper 服务注册中心，咱们需求对它进行兼容适配；依据 Istio 操控面敞开的 Mcp Over XDS 协议，优先在 Nacos 完结了该协议支撑，让 Istiod 能够直接对接 Nacos 注册中心。
开源产品在大规划生产环境往往不能直接运用，需求做一些适配和调优，以及一些产品化才能的封装；例如：Intel 的 mTLS 加快计划。
Intel 提交了 Envoy 侧 Upstream 的完结，但 Istiod 还未支撑。作为云产品，咱们希望供给给客户开箱即用的才能，服务网格 ASM 依据 Intel 开源的 mTLS 加快计划，完结了操控面 Istiod 的扩展支撑，而且由于该 mTLS 加快计划依靠底层资源的实践 CPU 机型（icelake)，ASM 针对用户事务实践布置做了自适应的加快功用的敞开和关闭，multiBuffer 加快功用在敞开状态下，选用阿里云 g7 代 ecs 作为 node 节点，QPS 有接近 80% 的提升。
说到服务网格，经常被提起的一个论题：“它和 Dapr 的差异是什么？”
Dapr 运用 Sidecar 架构，与运用程序一同作为单独的进程运转，包含服务调用、网络安全和分布式跟踪等功用。这经常会引发一个问题：Dapr 与 Istio 等服务网格处理计划比较怎么？
虽然 Dapr 和服务网格确实存在一些堆叠功用，但与专心于网络问题的服务网格不同，Dapr 专心于供给构建基块，使开发人员更简单将运用程序构建为微服务。Dapr 以开发人员为中心，而服务网格以根底设施为中心。此外，Dapr 不供给路由或流量分配等关于流量操控的功用。
当然, 两者能够布置在一同，此时，Dapr 和服务网格的 Sidecar 都在运用环境中运转。
服务网格在阿里巴巴的落地和实践
前面能够看到阿里针对微服务生态，开源了一些产品，这些产品其实在最开端都是由于有内部事务场景，依据这些内部事务场景的孵化和大规划事务检验，内部觉得外部客户也有类似需求，所以才把这些内部完结全部开源。
对应 Istio Mesh 相同也是，集团内部事务在很早就开端了 Mesh 的事务探究，咱们详细来看：
从整体架构图能够看到，阿里集团内部供给了一套操控台供 Mesh 用户操作，操控台以运用为视角，集成 CICD、权限办理、安全生产、SRE 运维系统等其他渠道，供给运用接入 Mesh 化后的共同 Portal ，让用户能够依据 DevOps 的理念，完结对运用的全生命周期办理，并经过 Mesh 方法供给运用服务办理、全链路灰度以及安全生产等才能，到达运用 Owner 能够自助和自愈运维的效果。
其中，Mesh 中心才能支撑对 Dubbo 、MetaQ(RocketMQ) 、LWP 等 RPC 协议的支撑，扩展完结了全链路染色、路由战略、插件市场等 Mesh 才能。
一同，阿里集团内部也支撑经过 OpenAPI 、Kubernetes API 方法供给给第三方系统集成的才能。
在社区 Istio 架构的根底上，阿里集团内部和内部中间件（Diamond、ConfigServer ） 做了深度集成，兼容保存事务的原始运用方法，让事务无缝接入到 Mesh ，这也是咱们考虑到部分 Mesh 事务有需求运用 Nacos ，在 ASM 产品层面支撑 Nacos 等多注册中心的场景；
一同笼统出运维平面，能够经过 UI 操控台的方法完结服务流量办理规矩（virtualservice、destinationrule 等) 的装备，一同经过和 OpenKrusise 的集成，完结 pod 粒度的 Sidecar 的敞开、关闭以及热晋级等功用，经过对集团内部 Prometheus 和 Grafana 以及告警 ARMS 的集成，完结微服务的可调查和可监控。
阿里集团服务网格的演进途径
阿里集团服务网格演进分为三个阶段：无侵入部分规划化、无侵入全面规划化、云原生终态，现在集群事务 Mesh 化处于第二阶段。
第一阶段：存量事务 Mesh 化存在一个过渡阶段，而且需求保证这个过渡阶段相对无侵入，让事务开发者无感知；这是为什么咱们需求选用无侵入计划的布景和前提；而且需求选用 Mesh 覆盖已有的微服务办理的才能，一同供给 Mesh 的增量价值；
第二阶段：全面规划化，一同处理规划化带来的资源开销和功用问题，经过 Sidecarcrd 完结服务装备懒加载，到达装备阻隔的问题，经过对 Metrics 的优化裁剪，下降 Sidecar 内存开销，一同经过优化 Dubbo/HSFFilter 完结慵懒编解码，进步数据面处理功用下降延迟。
跟着内部事务 Dubbo 2.0/HSF 演进到 Dubbo 3.0 ，终究演进到云原生终态计划。
第三阶段：云原生终态，跟着根底设施向 Kubernetes 演进，在云原生场景下，服务发现、服务办理才能下沉，经过 Mesh 能够解耦事务逻辑和服务办理，完结装备和代码逻辑别离，然后更好地 DevOps 化，并享用 Mesh 带来的丰厚的可扩展流量调度才能和可调查性。
Dubbo/HSF RPC 支撑多种序列化方法，而 Mesh 针对一些序列化并不能做到很友爱的支撑，比方 Java 序列化。
因此，事务在 Mesh 化第一阶段，针对 Java 序列化，Sidecar 不做编解码，选用 Passthrough 流量透传的方法；针对 Hessian2 序列化，Mesh 完结了完好的编解码支撑，并依据功用考虑完结了慵懒编解码。依据此，咱们能够完结对这类流量完结流量打标（染色）并经过扩展 VirtualService 的方法，完结标签路由和 Fallback 的才能。还能够完结一些特定的事务场景，如金丝雀发布、全链路灰度等场景；
内部事务 MeshSDK 这层会逐渐晋级到 Dubbo3.0 SDK，在敞开 Mesh 的场景下，Dubbo3.0 SDK 仅供给 RPC 等才能，对应 ThinSDK 形式，Mesh 化后，Sidecar 的协议支撑友爱度更好、资源开销本钱有一定的下降；当 Sidecar 故障时，能够快读切回 FatSDK 形式，事务无感知；
关于集群内部事务，流量调度存在一些较为杂乱的场景，特别是一些规划较大的事务。比方多机房多区域布置， 一同在单个区域下还存在服务多版别、多环境的的路由等
这就涉及到不同维度的路由和后端 cluster 选择，这些维度或许有：
- 区域化路由
- 机房路由
- 单元化路由
- 环境路由
- 多版别路由
集团电商场景尤为典型，依据此，内部扩展 Istio 经过引进新的 CRD：RouteChain、 TrafficLable 以及对 VirtualService 的扩展，完结了对流量打标和按标路由的才能。
商业化产品阿里云服务网格 ASM 也将这些才能进行了不同程度的透出，能够依据此完结比方金丝雀发布、A/B 测验、全链路灰度等场景。
云产品：阿里云服务网格 ASM
前面咱们介绍了阿里巴巴服务网格在开源和大规划落地方面的实践，接下来共享下在云原生三位一体中关于云产品方面的设计。阿里云经过总结事务场景落地经验，持续驱动技能发展，沉积一系列服务网格中心技能。
在大规划落地方面： 比方按需动态推送规矩装备，大规划事务无损下 Sidecar 热晋级，支撑最全面的异构计算根底设施，支撑多注册中心与渠道。
在流量办理方面： 供给了精细化的流量操控，按需对流量协议、端口动态阻拦，零装备完结恳求标签路由以及流量染色，支撑多种协议的精细化办理。
在可观测才能方面： 供给了日志、监控与跟踪融合的一体化智能运维，一同依据 eBPF 增强可观测性，完结无侵入完结全链路可观测，辅佐事务快速排障。
在安全才能方面： 支撑 Spiffe/Spire、完结零信赖网络、增强认证鉴权机制, 支撑渐进式逐渐完结 mTLS。
在功用优化方面： 经过 eBPF 技能进行网络加快，完结软硬一体的功用优化。
阿里云服务网格 ASM 是业界首个兼容 Istio 的托管式服务网格渠道，支撑完好的服务网格产品才能：精细化的运用流量办理、端到端的可观测才能、安全和高可用；支撑多语言多环境、多种微服务结构、多协议互联互通等杂乱场景。服务网格 ASM 技能架构现已升全面晋级 V2.0， 托管了操控面中心组件，保证了规范版和专业版的架构共同，滑润支撑社区各个版别的晋级。一同 ASM 在和社区规范共同的根底上进行各种才能增强。首要包含流量办理和协议增强，支撑多种零信赖安全才能，支撑对接 Nacos、Consul 等多种注册中心。除此之外经过网格诊断才能快速剖析网格的健康状况，合作操控面告警快速呼应。
服务网格 ASM 和各种云服务才能充分融合，包含链路追寻、Prometheus 监控、日志服务等可观测才能。集成 AHAS 支撑服务限流、集群限流和自适应限流，结合微服务引擎 MSE 支撑服务办理，而且能够给跨 VPC 多集群供给共同的办理体会。在自界说扩展方面支撑 OPA 安全引擎，webAssembly 等自界说扩展才能。
用户能够经过 ASM 操控台、OpenAPI、声明式云原生 API、数据面和操控面 Kubeconfig 运用服务网格技能。经过服务网格 ASM 在操控面和管控面的打磨，能够为运转在异构计算根底设施上的服务供给共同的网格化办理才能（Anywhere Service Mesh），从进口网关到数据面 Sidecar 注入，支撑容器服务 ACK、Serverless kubernetes、边缘集群和外部注册 Kubernetes 集群，以及 ECS 虚拟机等多种根底设施。
服务网格 ASM 的功用设计
依据 ASM 的流量打标和标签路由完结全链路灰度。微服务软件架构下，事务新功用上线前搭建完好的一套测验系统进行验证是适当费人费时的事，跟着所拆分出微服务数量的不断增大其难度也愈大。依据“流量打标”和“按标路由” 才能是一个通用计划，能够较好地处理测验环境办理、线上全链路灰度发布等相关问题。而且依据服务网格技能能够做到与开发语言无关，该计划适应于不同的 7 层协议，当前服务网格 ASM 现已支撑 HTTP/gRpc 和 Dubbo 协议。在 ASM 中引进了全新的 TrafficLabel CRD 用于界说 Sidecar 所需透传的流量标签从哪里获取，全链路流量操控进行逻辑阻隔，对流量进行打标（染色）和按标路由，经过运用服务网格 ASM，无需每位技能研制人员布置一整套环境，完结多环境办理，大幅度下降研制本钱。
服务网格 ASM 支撑完结金丝雀发布。发布是整个功用更新到线上的最终一个环节，一些研制进程中累计的问题，在最终发布环节才会触发。一同发布自身也是一个杂乱的进程，在发布进程中，往往简单呈现一些错误操作或者遗漏要害操作。金丝雀发布装备灵敏，战略自界说，能够按照流量或详细的内容进行灰度（比方不同账号，不同参数），呈现问题不会影响全网用户。图中给运用打上环境标签， 经过 TrafficLable 对用户流量比方对 http-header: user-id % 100 == 20 打上 gray 标签，一同经过 VirtualService 下发标签流量路由规矩，所以 userId 为 120 的用户流量会被路由到 gray 灰度环境，userId 为 121 的用户流量被路由到 normal 正常环境。服务网格 ASM 完结的金丝雀发布支撑按流量百分比路由，按恳求特征（如 http header, 方法参数等）路由，而且和服务网格进口网关完美集成，支撑 HTTP/gRPC/Dubbo 协议 。
除了运用流量打标和标签路由得完结全链路灰度和金丝雀发布，服务网格 ASM 也支撑和 KubeVela 结合完结渐进式发布。KubeVela 是一个开箱即用的、现代化的运用交付与办理渠道，能够简化面向混合环境的运用交付进程；一同又足够灵敏能够随时满意事务不断高速改变所带来的迭代压力。KubeVela 后的运用交付模型 Open Application Model（OAM）是一个从设计与完结上都高度可扩展的模型，具有彻底以运用为中心、可编程式交付工作流、与根底设施无关的特色。阿里云服务网格 ASM 支撑结合 KubeVela 进行杂乱的金丝雀发布流程能够将 KubeVela 界说的相关装备转化为流量办理规矩下发到数据面。
阿里云服务网格 ASM 完结了零信赖安全才能。在微服务网络中运用 HTTP 通讯的交互并不安全，一旦内部的某个服务被攻陷，进犯者能够以该机器为跳板来进犯内网。服务网格 ASM 能够减小云原生环境中的被进犯面积，并供给零信赖运用网络所需的根底结构。经过 ASM 办理服务到服务的安全性，能够确保服务网格的端到端加密、服务级别身份认证和细粒度授权战略。
比较传统的在运用程序代码中构建安全机制，ASM 零信赖安全系统具有以下优势：
- ASM Sidecar 署理的战略生命周期与运用程序保持独立，因此能够更轻松地办理这些 Sidecar 署理。
- ASM 支撑动态装备战略，更新战略变得更加简单，更新立即收效而无需重新布置运用程序。
- ASM 供给了对附加到恳求的终端用户凭据进行身份验证的才能，例如 JWT。
- ASM 的集中操控架构使企业的安全团队能够构建、办理和布置适用于整个企业的安全战略。
将身份验证和授权系统作为服务布置在网格中，好像网格中的其他服务相同，这些安全系统从网格中自身也能够得到安全保证，包含传输中的加密、身份识别、战略履行点、终端用户凭据的身份验证和授权等。战略操控面界说并办理多种类型的认证战略；网格操控面赋予网格中工作负载身份，并主动轮转证书；数据面的 Sidecar 代码履行战略。图中用户装备规矩只允许交易服务发起调用订单服务，回绝购物车服务调用订单服务。
由于服务网格 ASM 是操控平面托管，支撑管控多个数据面集群，流量办理 CR 存在操控平面，支撑用户经过操控平面的 KubeAPI 操作办理规矩。在服务网格新版别中，为了：
1、支撑用户在非托管形式下的操作习惯，能够在数据面 Kubernetes 集群中读写 Istio 资源 ；
2、支撑 Helm 常用命令工具；
3、兼容其他开源软件在单集群 addon 形式下的 API 操作，阿里云服务网格 ASM 完结了支撑数据面集群 Kube API 拜访 Istio 资源。两者一同对外供给，用户能够依据实践场景按需运用。
ASM 兼容社区规范，供给了操控平面的滑润晋级，那么数据面的晋级能够晋级两种方法：翻滚晋级和热晋级才能，关于翻滚晋级才能需求设置晋级 Strategy 为 RollingUpdate ，注入 Sidecar 的 Pod 在发布时，Envoy 镜像会主动晋级到新版别。图中首要介绍第二种方法阿里云服务网格 ASM 结合 OpenKruise 项目完结的热晋级功用，在晋级数据平面时不会中止服务，使数据平面在运用无感知的情况下完结晋级。运用发布和更新主动生成 SidecarSet 装备，更新 SidecarSet 装备完结数据面的晋级，现在这项才能在新版别灰度中。
服务网格 ASM 合作阿里云运用高可用服务 AHAS 能够对布置在服务网格内的运用进行流量操控，现在现已支撑单机限流，集群限流，自适应限流。一同服务网格 ASM 也原生支撑 Istio 的大局限流和本地限流，大局限流运用大局 gRPC 服务为整个网格供给速率约束，本地限流用于约束每个服务实例的恳求速率，本地限流能够与大局限流结合运用。
服务网格 ASM 也支撑经过 MCP over XDS 协议对接微服务引擎 MSE 的注册中心，同步服务信息到网格。MSE 的 Nacos 原生支撑 MCP 协议，用户只需求在创立或更新 ASM 实例时敞开 Nacos 注册中心对接功用，完结注册中心的服务同步到服务网格，能够很方便地支撑 Dubbo、Spring Cloud 服务的网格化，用户侧无需做任何事务代码修正。
最终共享几个客户事例，客户怎么运用服务网格 ASM 缩短服务网格技能落地周期、减轻反常排错本钱，节省操控面资源本钱。
1、春风日产跟着事务的发展，早前打造的「十二生肖」（十二套完好的测验环境）已无法满意众多并发需求，甚至需求摇号分配环境。经过引进阿里云服务网格 ASM，构建了依据流量办理的「无限生肖」系统，满意了主动按需供给环境的诉求。依据 ASM 供给的免运维、易晋级以及产品丰厚支撑才能，让产研团队集中享用 ServiceMesh 带来的价值。
2、职优你为了应对事务的全球化扩张与一体化运营，依据阿里云服务网格 ASM 和容器服务 ACK 将事务运用跨区域布置，经过服务按地域就近拜访的战略，优化了客户拜访体会，有用下降事务拜访时延，提升事务呼应速度。
3、商米科技引进阿里云服务网格 ASM，构建智能的数字化商业智能 POS 软硬件一体化系统处理计划，运用服务网格 ASM 处理 gRPC 服务负载均衡、链路追寻以及流量共同办理等中心问题。
本文共享了阿里巴巴服务网格技能三位一体战略背后的思考和实践，关于阿里云服务网格 ASM 的一些产品功用，包含最近发布的一些功用，例如 Istio 资源前史版别办理功用、支撑数据面集群 Kubernetes API 拜访 Istio 资源、支撑跨地域故障转移和跨地域流量分布、支撑操控平面日志收集和日志告警以及支撑依据 KubeVela 完结渐进式发布等详细信息，以及更多关于流量办理，可观测，零信赖安全，处理计划等产品功用，欢迎点击阅读原文拜访阿里云服务网格 ASM 的产品文档。如果对服务网格 ASM 感兴趣，欢迎钉钉扫描下方二维码或查找群号（30421250）参加服务网格ASM 用户交流群，一同探究服务网格技能。
点击此处，查看更多服务网格 ASM 相关信息～
