服务网格 ASM 年终总结：最终用户如何使用服务网格？

01

背景

Aliware

阿里云服务网格 ASM 于 2020 年 2 月公测，近 2 年的时间，已有大量用户采用其作为生产应用的服务治理平台。阿里云服务网格 ASM 基于开源 Istio 构建。同时，Istio 仍然年轻，2021 年我们看到 Istio 不少新的进展，eBPF、Multi-buffer、Proxyless 等，每一次 Istio 的变化都牵动人们的神经——是时候采用服务网格了吗？

本文不打算回顾 Istio 或是阿里云服务网格 ASM 的变化或趋势，我们来聊一聊阿里云 ASM 服务网格，它的最终用户是如何使用服务网格的。

02

为什么采用服务网格？

Aliware

服务网格的理念是将服务治理能力下沉到基础设施，让业务更加专注于业务逻辑。我们可以很轻松地举出服务网格带来的服务治理能力，比如流量管理、可观测性、服务安全通信、策略增强如限流和访问控制等。但是，最终用户真的需要这些功能吗？Istio 的这些能力真的满足生产要求吗？为了一两个功能引入服务网格是否值得大费周章？

比如说流量管理，最受关注的是 Traffic Splitting，常用于灰度发布或者 A/B 测试。Istio 的功能设计非常简洁，但是默认无法实现全链路流量管理。如果没有在所有微服务拓扑节点里透传自定义的 Header 或标签，具有关联性的服务流量切割则完全不可能。

比如是安全能力，采用传统手段进行大量微服务 TLS 认证几乎是 Impossible Mission，而 Envoy 提供的 mTLS 加密则非常轻松地完成了服务间加密通信，或者说零信任安全。但是，用户是否真的关心服务间安全，毕竟这些微服务大多运行在云上的一个 VPC 的一个 Kubernetes 集群里。

比如可观测性，Istio 将 Metrics、Logging、Tracing 统一起来，可以很方便地获取微服务拓扑结构，快速地定位微服务问题。但是，Sidecar 无法深入进程级别，相关的 Metrics 和 Tracing 相比经典的 APM 软件实在相形见绌，无法真正有效地定位代码级别问题。

最后策略增强比如限流能力，Istio 提供 Global Rate Limit 和 Local Rate Limit 限流能力，确实是大量面向 C 端用户应用的强需求。但是它真的能满足复杂的生产应用限流降级需求吗？

真正的生产环境各式各样，服务网格在落地过程中又会遭遇各种各样的挑战。最终用户最关心的服务网格的能力是什么，在落地过程中又有怎么的实践经验？

03

用户主要采用服务网格什么能力？

Aliware

我先暂时不回答上面提出的疑问。我们来看看阿里云服务网格 ASM 用户主要使用服务网格的哪些能力，我相信读者会形成自己的答案。

01

流量管理

首先当然是流量管理，这是 Istio 最显著地提升应用发布幸福感的能力。阿里云服务网格 ASM 大部分的用户出于流量管理的需求选择了 ASM 服务网格。而流量管理主要应用在灰度发布或 A/B 测试。最常见的应用场景如下：