作者：刘如鸿

布景

合阔智云(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 增强了多协议支撑以及动态扩展才能，供给精密化服务办理，完善零信任安全体系，并继续提高性能及大规划集群支撑才能，降低在出产环境落地服务网格的门槛。商业版适用于有多言语互通，服务精密办理需求，在出产环境大规划运用服务网格的场景。

详细的介绍能够拜见：

help.aliyun.com/document_de…

经过调研， 咱们了解到作为业内首个全保管 Istio 兼容的服务网格产品 ASM，一开端从架构上就保持了与社区、业界趋势的一致性，操控平面的组件保管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是根据社区开源的 Istio 定制完结的，在保管的操控面侧供给了用于支撑精密化的流量办理和安全办理的组件才能。经过保管模式，解耦了 Istio 组件与所办理的 K8s 集群的生命周期办理，使得架构愈加灵敏，提高了体系的可伸缩性。

合阔智云核心生产系统切换到服务网格 ASM 的落地实践

保管式服务网格 ASM 在成为多种异构类型核算服务一致办理的根底设施中, 供给了一致的流量办理才能、一致的服务安全才能、一致的服务可观测性才能、以及完结一致的署理可扩展才能, 以此构筑企业级才能。能够经过点击”阅览原文”检查具体的内容介绍。

根据上述的调研， 咱们决议开端运用阿里云服务网格 ASM 产品进行搬迁。

搬迁到阿里云 ASM

第一轮

  • 第一次注入：ACK-PROD

咱们首先将一个满足规划体量的单一客户出产环境（门店供应链）（每天 50 万笔订单，1500 万库存流水）注入 Istio，由于这个环境的运用场景不是全天候的，呈现问题会有半个小时的缓冲时刻来处理问题，而且运用体系做了完善的主动补偿，保证在呈现问题咱们撤销 Istio 今后事务也能够正常恢复，第一次注入十分成功。

  • 第2次注入：ACK-PROD

然后咱们将别的一个门店供应链的出产环境也做了 Istio 注入，相关于第一个环境，规划体量小一点，但事务环境愈加复杂，有更多的运用服务在运转，第2次注入十分成功。

  • 第三次注入：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，除了晋级过程中遇到部分服务资源缺乏的问题，其他都十分顺畅；

  • 第2次注入：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 的落地实践

服务网格ASM 经过拜访日志剖析主动引荐 Sidecar CR

经过优化后， Sidecar 装备大小从本来的 40 多M削减为 5M, 操控面装备推送时刻也随之大大削减。

总之， 经过一个多月的重复测验和承认，咱们终于完结了根据服务网格 ASM 的中心出产体系切换，相关于之前的服务网格计划，给咱们带来了很多益处。

计划优势及发展规划

齐备的可观测性以及运用监控

经过服务网格对应的操控面盘，咱们发现了很多之前运用自身的问题，比方：

  • 不合理的运用补偿战略
  • 不合理的运用部署（比方把大数据查询和运用处理放在同一个服务）
  • 不合理的运用报错
  • …

而这些问题跟着服务网格的上线，咱们变得一清二楚，从而十分方便的推进运用架构的改造。

流量与资源的均衡

这是咱们上线服务网格的初衷，跟着咱们将一切运用放到服务网格，咱们真实做到了在 CPU、内存、网络利用率的均衡，经过经过运用调用的监控来看，一切恳求数量和错误也十分均衡的分配在不同的 Pod 上，不用再去忧虑跟着流量的增长由于负载不均衡而导致横向扩展失效。

愈加强壮的流量办理才能

在没有 Istio 之前，咱们根据自身事务需求做了一些“手艺”的流量办理作业，比方：

  • 东西流量：根据根据租户与门店的流量阻隔，答应咱们能够答应需求针对某一个租户某一个门店发布指定服务
  • 南北流量：针对事务场景进行灰度测验，比方某一个租户的美团订单处理运用新的接单服务
  • 为某个租户供给自定义域名
  • …

这些作业都是根据 K8s CRD 构建的，跟着服务网格的上线，咱们发现 Istio 能够帮助咱们完结更多，比方灰度发布、熔断、限流、流量标签等。这些才能将在未来继续不断提高咱们线上事务的稳定性。