作者：王夕宁、 刘强、 华相
丽迅物流是百丽旗下专注于时尚产业、为企业提供专业物流及供应链解决方案的服务商。其产品服务主要包括城市落地配、仓配一体、干线运输及定制化解决方案。通过自研智能化物流管理平台，全面助力企业合作集约化发展。目前，丽迅物流已在全国拥有 70+ 全渠道实体云仓、6 大中心电商仓，总面积达 100 万+ 平方米，服务覆盖 300+ 城市、3000+ 商圈，为多家知名时尚品牌及其品牌门店提供全渠道配送服务。
为了降低业务各环节中的运维成本、提高物流服务效率，2021 年 8 月起，丽迅物流开始在阿里云上完成自身从 IDC 自建到全面云原生化的进程。其中使用了阿里云容器镜像仓库企业版 ACR EE 和阿里云容器服务 ACK 作为容器制品管理及调度平台，使用了阿里云服务网格 ASM 作为云原生应用服务的分布式管理平台，通过服务网格的服务治理和流量控制功能，实现了应用程序的高效部署和扩展。
通过本文，丽迅物流架构师刘强分享了关于基于阿里云服务网格 ASM 如何加速企业业务云原生化进程的实践经验。
在技术架构转型及业务快速发展的背景下，丽迅物流需要和各供应链支撑平台、研发平台等多个业务单元和合作伙伴进行业务交互，其业务系统多元化并且具有开放性。在市场环境和消费者需求快速变化的现状下，我们更希望将精力专注于核心业务的研发。包括了以下需要解决的业务问题痛点：
应用版本迭代困难
面对快速变化的客户、业务要求，所依赖的应用功能越来越多。业务越复杂，代码的耦合度也越来越高，新特性上线周期逐步拉长，使得应用版本迭代愈发困难。
异构系统无法统一治理
企业级 IT 系统多语言、多协议、多框架的现状，为统一进行服务整合、服务治理设下困局。同时，由于 IT 系统部署基础设施复杂，支持跨平台、跨多个 Kubernetes 集群的技术难点亟需解决。
构建统一的云原生应用服务研发平台存在一定困难
以 Spring Cloud 为代表的开源微服务框架成为业界主流的微服务脚手架。这些框架已具备服务注册发现、健康检查等基础微服务能力，但面对企业级应用所涉及的服务访问安全控制、服务流控、路由控制、灰度发布等高阶服务治理问题，仍须应用自行整合大量的第三方开源框架。这使得云原生应用服务业务应用设计开发具有较高的技术门槛，对于企业构建统一的云原生应用服务研发平台带来一定困难。
复杂的运维体系
现有的运维体系存在一定的复杂性，相比于服务网格提供围绕流量管理、安全性、可观测性的一系列功能，目前对于大规模管理应用服务的运维体系存在挑战。
作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就保持了业界领先性以及社区与业界发展的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立，保持高可用部署与稳定性。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。
阿里云服务网格 ASM 架构图
托管式服务网格 ASM 在成为多种类型计算服务统一管理的基础设施中，提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及基于 WebAssembly 实现统一的代理可扩展能力，以此构筑企业级能力。
除大数据的分析体系外，丽迅物流的当前系统已经全面接入服务网格体系，包括使用以下能力：
丽迅科技业务应用部署架构图
客户端发起业务请求，后端需要验证用户请求的合法性。例如，判断用户请求是否有该资源访问权限。认证通过后，返回结果中还需要增加一些原始请求中没有的信息，例如用户认证通过后在 header 中添加业务版本号、用户 ID 等。
针对上述业务场景，ASM 提供了自定义授权服务。在 ASM 网关上加入鉴权流程，以确保只有得到授权的情况下，才能访问关键服务。
具体可以参见：https://help.aliyun.com/document_detail/446628.html?spm=a2c4g.476420.0.0.25005e37CV8ta8
此外，阿里云服务网格 ASM 产品为服务网格下的每一个工作负载提供了简单易用的身份定义，并根据特定场景提供定制机制用于扩展身份构建体系，同时兼容社区 SPIFFE 标准；并提供了基于策略的信任引擎作为构建零信任的关键核心。
在原系统 2.0 体系下，应用微服务之间调用时通过服务注册中心 Eureka 获取实例的 IP 和端口，也就是说 Eureka 通过将服务实例注册到注册表中，并通过 Eureka 客户端进行负载均衡，使得服务可以根据需要动态地选择可用的服务实例进行连接。
在切换到 Kubernetes 和服务网格体系上之后，替换其中微服务应用程序中的 Spring Cloud 模块功能，包括服务注册和发现切换到 Kubernetes 体系，基于 K8s service+Core DNS 实现，也就是说，既然 Kubernetes 已经在 Pod 调度的同时维护了服务和 Endpoint 间的数据，那么就没有必要再单独搞一套名字服务的机制进行服务注册，统一收敛到 Kubernetes 的服务注册与发现是最佳实践。
经过以上的简单改造，各种不同语言、各种不同开发框架开发的服务，只要业务协议相通，彼此可以互相访问，访问协议可以被网格管理，就都可以通过 ASM 进行统一的管理。
控制面上可以配置统一的服务管理规则。数据面上，统一使用 Sidecar 代理进行服务发现、负载均衡和其他流量、安全、可观察性等相关能力。当然在迁移过程中间，也可以阶段性地保留原有微服务框架的注册中心，使 ASM 和其他的服务发现结合使用的中间状态，让网格中的服务可以访问到微服务注册中心的服务。
具体可以参见：https://help.aliyun.com/document_detail/2527072.html
在生产环境正常运行的同时，开始针对部分应用服务进行灰度升级，譬如图中的 B 和 D 应用进行灰度，在不需要修改应用逻辑的情况下，利用 Service Mesh 技术就可以实现根据请求来源或者请求的头信息，动态地路由到不同版本的服务上。譬如，当请求头中包含 tag1 时，应用A就会调用灰度版本 B，而 C 并没有灰度版本，系统就会自动 fallback 回退到原有的版本。
全链路灰度示意图当您需要在多个服务间实现全链路的灰度发布时，可以通过配置 TrafficLabel 来识别流量特征，将网关入口流量分为正常流量和灰度流量。灰度流量特征会在请求调用链经过的各个服务间进行传递，从而实现全链路灰度发布。
具体可以参见：https://help.aliyun.com/document_detail/377563.html?spm=a2c4g.2362128.0.0.50945dfcNA9kUg
阿里云服务网格 ASM 提供了网格可观测中心来统一进行可观测性体系和联动分析，分为 3 个维度。
一是日志分析， 通过对数据平面的 AccessLog 采集分析，特别是对入口网关日志的分析，可以分析出服务请求的流量情况、状态码比例等，从而可以进一步优化这些服务间的调用。
第二个可观测性能力是分布式追踪能力。 为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。
第三个可观测性能力是监控能力。 根据监视的四个维度（延迟，流量，错误和饱和度）生成一组服务指标，来了解、监视网格中服务的行为。
此外，还提供了网格拓扑，用于提供对服务网格行为的即时洞察。除了强大的网格流量拓扑可视化之外，还提供了回放功能，可以选定过去时间段的流量。
ASM 提供了开箱即用的 EnvoyFilter 插件市场来维护扩展插件的全生命周期管理。
基于内置的模板，用户只需要根据对应的参数要求，进行简单配置，就可以部署出对应的 EnvoyFilter 插件。通过这样的机制，使得数据平面成为更易可扩展的插件集合能力。
服务网格作为一种用来管理应用服务通信的基础核心技术，为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。
可以看到，阿里云服务网格 ASM 为云原生应用管理带来了重要的优势，总结为以下六个方面。
优势之一：异构服务统一治理
优势之二：端到端的可观测
优势之三：零信任安全
优势之四：软硬结合性能优化
优势之五：SLO 驱动的应用弹性
优势之六：开箱即用扩展&生态兼容
应用阿里云服务网格 ASM 之后，高效解决了多语言技术栈情况下应用链路调用复杂的运维难题，并解决了与云上其他产品搭配使用时的易用性问题，从而使运维效率提升了 40%。 同时，借助 ASM 提供的丰富的企业级能力和完备的可观测能力，构建服务网格的实施周期缩短了 50%。
