针对网站开发者的问答网站,个人网站做淘宝客违规,如何提升进入网站的速度,做网站和做系统有什么不同简介#xff1a;本文分享了阿里巴巴服务网格技术三位一体战略背后的思考和实践#xff0c;关于阿里云服务网格 ASM 的一些产品功能#xff0c;包括最近发布的一些功能。 作者#xff1a;宗泉、宇曾 阿里巴巴三位一体战略 阿里云内部很早就提出了开源、自研、商业化三位一…简介本文分享了阿里巴巴服务网格技术三位一体战略背后的思考和实践关于阿里云服务网格 ASM 的一些产品功能包括最近发布的一些功能。 作者宗泉、宇曾 阿里巴巴三位一体战略 阿里云内部很早就提出了开源、自研、商业化三位一体战略先谈谈我对它的理解。 多年的软件开发经验告诉我们开发出一款出色的软件有一些关键要素 沟通反馈实践 在软件开发过程中我们不能闭门造车不能随意“创造”业务场景需求。业务场景和产品功能需要提炼开源给我们提供了一个共同创新的平台基于这个平台大家可以共同定义一些规范和标准。不同的厂商遵循相应的标准客户就没有被锁定的风险可以不停地迁移总是能找到最好的厂商将自己的业务放上去用最简单、最便捷、最经济的方式来运营自己的业务。 很多客户在选择阿里云服务网格的时候有一条比较重要的评判指标是否和社区 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 的 ProxylessMeshMesh 化不是一蹴而就对于原有的存量业务类似业务上云存在一个中间过渡阶段传统微服务框架例如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 通过引入新的 CRDRouteChain、 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 ModelOAM是一个从设计与实现上都高度可扩展的模型具有完全以应用为中心、可编程式交付工作流、与基础设施无关的特点。阿里云服务网格 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 服务负载均衡、链路追踪以及流量统一管理等核心问题。 原文链接​​​​​​​ 本文为阿里云原创内容未经允许不得转载。