作者：刘如鸿
背景
合阔智云(www.hexcloud.cn) 是专注于为大中型零售连锁行业，提供全渠道业务中/前台产品和解决方案，并建立以消费者为中心的全渠道交易和敏捷供应链的新一代零售运营协同平台。
合阔智云提供了从全渠道交易管理到订单履约再到门店供应链完整的餐饮零售连锁解决方案，整个方案采取微服务设计，并深度使用了 Kubernetes 作为生产调度平台。
技术现状
整个业务系统采用微服务架构，但不同业务场景在不同阶段选择了不同的技术语言来开发，如 Python、Golang 和 Java，甚至有部分应用使用了 Nodejs，因为技术栈的缘故，Spring Cloud 或者 Dubbo 这样的全家桶并不适合我们，为了能够适应业务需要，我们选择了下面的策略：
- 不依赖于单一语言和单一技术框架，允许使用更加合适业务的开发语言，如快速业务迭代使用 Python，基础服务和云原生部分使用 Golang，核心的业务系统使用 Java
- 服务内部使用 gRPC 通信，服务接口定义依赖于 Protobuf
- 原则上跨服务通信不依赖于消息队列，消息队列只用于服务自身的调度与补偿，这样子降低了消息系统本身的复杂性
- 所有系统不直接暴露 HTTP，需要提供 HTTP 服务的，使用团队开发的 grpc-proxy 来实现 HTTP to gRPC 的转码代理工作
原则上应用只处理业务本身的问题，所有基础架构部分的能力都转由 K8s 来负责，包括：
- 网关
- 服务发现
- 负载均衡
- 指标与监控
- 健康检查
- 故障恢复
当前挑战
早期所有技术人员只需要专注业务的编写，其他所有的工作全部交给 K8s，在流量比较小业务相对简单的情况下，这个运行非常流畅。然而，随着应用数量的增加，业务变得越加复杂，外部流量也在不断增长，由此带来了应用链路调用更加复杂等新的运维难题：
- 内部调用用的是 gRPC 协议，应用端没有做特别处理，导致基于 HTTP2 的长连接协议无法实现负载均衡，尤其是单一客户端调用变大的情况下，服务端无法有效负载；
- 因为应用本身比较薄，应用调用链路无法透明化，每次新的发布部署容易出问题。
在 2022 年之前，我们使用 Linkerd，初步解决了服务在负载均衡和调用链路上的治理难题，但我们大部分的基础架构都是依赖于阿里云，比如：
- 日志使用 SLS
- 应用监控使用 ARMS
- 链路追踪使用 XTrace
- 仪表盘使用 Grafana
- 容器监控使用 Prometheus
为了简化基础架构的复杂性，我们在基础服务上的基本原则是使用云厂商而非自建，而 Linkerd 在实际的使用过程中遇到了一些问题：
- 需要使用自建的基础设施，无法和阿里云提供的基础设施很好的融合
- 应用可观测性比较简单
- Sidecar 使用默认配置，控制能力相对较少，在应对一些复杂一点的场景，无法做到灵活配置
而可观测性是服务网格的基石，在一套自建的基础架构上，我们会偶发的出现链路被熔断、某个端口无法访问的场景，最终的解决方案就是取消注入或者重新注入来解决。
基于服务网格 ASM 的探索
集群现状
我们目前有两个生产集群，合计 150 台 ECS，2500 个 Pod，不同开发语言应用的特点如下：
- Golang 用于用户基础架构以及计算密集型性的应用系统，总体内存占用不会超过 500M，部分服务会随着临时性的内存而增长，如文件的导入导出服务；
- Python 用于早期业务敏捷迭代构建的业务系统，都是单进程多线程工作模式，单一 Pod 内存占用不高，但一个 Deploy 需要更多的 ReplicaSet 数量；
- Java 用于全渠道在线交易业务构建的系统，单一 Pod 需要耗费的资源比较多，但同等情况下单一 Pod 的处理能力比较强。
两个集群包括了不同的应用场景：
- ACK-PROD：早期针对大型客户专有部署的应用集群，每个客户的规模体量比较大，应用资源的隔离通过namespace和调度绑定来隔离；
- ACK-SAAS：针对 SME/KA 全新开发的 SaaS 平台，所有客户都使用统一的计算资源。
调研阿里云服务网格 ASM
我们知道， 服务网格作为一种用来管理应用服务通信的基础核心技术, 为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。我们针对开源社区 Istio 和阿里云服务网格 ASM 产品分别进行了调研， 通过试用了解到作为云厂商的产品， ASM 具备了若干生产使用的功能和实战经验，具体来说， ASM 增强了多协议支持以及动态扩展能力，提供精细化服务治理，完善零信任安全体系，并持续提升性能及大规模集群支持能力，降低在生产环境落地服务网格的门槛。商业版适用于有多语言互通，服务精细治理需求，在生产环境大规模使用服务网格的场景。
详细的介绍可以参见：
https://help.aliyun.com/document_detail/176082.html
通过调研， 我们了解到作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。
托管式服务网格 ASM 在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及实现统一的代理可扩展能力, 以此构筑企业级能力。可以通过点击"阅读原文"查看具体的内容介绍。
基于上述的调研， 我们决定开始使用阿里云服务网格 ASM 产品进行迁移。
迁移到阿里云 ASM
第一轮
- 第一次注入：ACK-PROD
我们首先将一个足够规模体量的单一客户生产环境（门店供应链）（每天 50 万笔订单，1500 万库存流水）注入 Istio，因为这个环境的使用场景不是全天候的，出现问题会有半个小时的缓冲时间来解决问题，并且应用系统做了完善的自动补偿，确保在出现问题我们取消 Istio 以后业务也能够正常恢复，第一次注入非常成功。
- 第二次注入：ACK-PROD
然后我们将另外一个门店供应链的生产环境也做了 Istio 注入，相对于第一个环境，规模体量小一点，但业务环境更加复杂，有更多的应用服务在运行，第二次注入非常成功。
- 第三次注入：ACK-SAAS
随着前面两次的成功实践，我们在一个更加重要的实时生产系统（门店全渠道交易）的基础服务部分引入了 Istio，因为这些服务只使用 Golang 编写，都是一些实时处理要求比较高，但业务相对简单的，第三次注入成功。
- 第四次注入：ACK-SAAS
我们在生产环境开始注入部分交易链路，注入以后系统生产可用，在第二天高峰期发现了会有部分服务出现 istio-proxy crash 导致应用不可用，从而影响了部分应用的正常运行。鉴于对生产环境的谨慎，我们重新复盘了出现问题的场景，最终得到的结论是：
- Java 应用的启动对于资源的要求比较苛刻，我们没有提前配置好更加合理的启动参数，将会导致 Java 应用启动缓慢；
- 检查机制不完善，将会导致流量打给还没有完全准备就绪的服务，此时 K8s 的健康检查机制会在多次没有响应时会再次重启服务；
- Istio Sidecar 默认的设置也会推慢整个 Pod 的启动时间，之前应用的假设是 15s 内完成启动，随着 Sidecar 代理的注入，有时候会遇到更长的时间；
- Java 应用提供 gPRC 服务的时候，istio-proxy 会出现某种特殊情况的 Crash，这也是导致生产服务不可用的直接原因。
简单而言，在 istio-proxy 存在部分 bug 的情况下，我们的应用的快速启动策略和健康检查机制的不合理，直接导致了注入 Sidecar 代理的部分服务生产不可用。
针对这个问题，我们在阿里云工程师的支持之下，在另外一个环境复现并做了改进，主要的改进如下：
- 针对 istio-proxyCRASH 问题，社区已经有了解决方案，在阿里云工程师的支持下，我们升级了 Sidecar，并做了 A/B 测试，确定复现了这个 Crash 的场景；
- 针对 Java 应用一开始分配更多的CPU资源来加快 Java 应用启动，在测试过程中，如果默认分配 0.2 调整到 1.5，启动时间最长的会从 6 分钟减少到 40 秒；
- 调整 Sidecar 配置，根据应用优化 istio-proxy 的启动速度；
第二轮
在方案得到确认以后，我们开始了第二轮的 Istio 升级。
- 第一次注入：ACK-SAAS
我们将 SaaS 的供应链业务注入 Istio，除了升级过程中遇到部分服务资源不足的问题，其他都非常顺利；
- 第二次注入：ACK-SAAS-QA
我们在测试环境复现了启动速度慢的问题，并通过更加合理的启动参数配置验证了在 CPU 初始化申请对于 Java 应用的影响；
- 第三次注入：ACK-SAAS-QA
A/B 测试 Istio crash 场景，确认新的 Sidecar 已经修复这个问题；
- 第四次注入：ACK-SAAS
正式完成全渠道交易的 Istio 生产注入；
- 第五次注入：ACK-SAAS
将剩余的应用全部完成注入。
此外，服务网格 ASM 相比社区 Istio 能够实现更加丰富的能力，如流量标签、配置推送优化等能力。在实际的应用场景中，我们充分利用配置推送优化能力。在默认情况下，由于无法确定数据平面内所有工作负载与服务之间的关系，服务网格数据平面内的所有 Sidecar 都必须保存数据平面集群内所有服务信息的全量配置。同时，一次针对控制平面或数据平面的修改（例如在控制平面新建一条虚拟服务规则），都会导致控制平面向数据平面的所有 Sidecar 推送新的配置。
而在我们的数据平面 Kubernetes 集群中的工作负载数量比较多， 默认情况下会增加 Sidecar 对数据平面集群的资源消耗，同时控制平面会面临较大的配置推送负担，降低控制平面的效率与可用性。ASM 提供了选择性服务发现和 Sidecar 资源推荐功能，帮助优化配置推送效率。
服务网格 ASM 可以通过分析数据平面 Sidecar 产生的访问日志获取数据平面服务之间的调用依赖关系，为数据平面中的每个工作负载自动推荐 Sidecar 资源。为工作负载推荐 Sidecar 资源后：
- Sidecar 配置内将仅保留该 Sidecar 对应工作负载所依赖的服务信息。
- 当该 Sidecar 资源对应的工作负载无依赖关系的服务发生改变，或与该服务相关的资源发生改变（例如虚拟服务等），都不会引起控制平面向该 Sidecar 的配置推送。
服务网格ASM 通过访问日志分析自动推荐 Sidecar CR
经过优化后， Sidecar 配置大小从原来的 40 多M减少为 5M, 控制面配置推送时间也随之大大减少。
总之， 经过一个多月的反复测试和确认，我们终于完成了基于服务网格 ASM 的核心生产系统切换，相对于之前的服务网格方案，给我们带来了很多益处。
方案优势及进展规划
完备的可观测性以及应用监控
通过服务网格对应的控制面盘，我们发现了很多之前应用本身的问题，比如：
- 不合理的应用补偿策略
- 不合理的应用部署（比如把大数据查询和应用处理放在同一个服务）
- 不合理的应用报错
- ...
而这些问题随着服务网格的上线，我们变得一清二楚，进而非常方便的推动应用架构的改造。
流量与资源的均衡
这是我们上线服务网格的初衷，随着我们将所有应用放到服务网格，我们真正做到了在 CPU、内存、网络利用率的均衡，通过通过应用调用的监控来看，所有请求数量和错误也非常均衡的分配在不同的 Pod 上，不用再去担心随着流量的增长因为负载不均衡而导致横向扩展失效。
更加强大的流量治理能力
在没有 Istio 之前，我们基于自身业务需要做了一些“手工”的流量治理工作，比如：
- 东西流量：基于基于租户与门店的流量隔离，允许我们可以允许需要针对某一个租户某一个门店发布指定服务
- 南北流量：针对业务场景进行灰度测试，比如某一个租户的美团订单处理使用新的接单服务
- 为某个租户提供自定义域名
- ...
这些工作都是基于 K8s CRD 构建的，随着服务网格的上线，我们发现 Istio 可以帮助我们实现更多，比如灰度发布、熔断、限流、流量标签等。这些能力将在未来持续不断提升我们线上业务的稳定性。
