电子商务|阿里巴巴服务网格技术三位一体战略背后的思考与实践( 三 ) 广州市

提到服务网格，经常被提起的一个话题：“它和 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 带来的丰富的可扩展流量调度能力和可观察性。