如今微服务已成为构建现代云应用的主导模式，它围绕着特定的业务功能，将单个组件分解为独立的服务。但随之而来产生另外的问题：越来越多的系统被拆解成了很多个细胞一样的微服务，如何对微服务进行管理，是工程师遇到的难题之一。传统的微服务架构中，虽然有服务治理的组件，但需要在应用代码里进行集成，如何标准化高效地部署和运维的微服务？
Service Mesh应运而生。它将整体服务代码独立成一套服务，将业务代码和治理逻辑做了整体的分离，让运维部署变得简单。有人认为，Service Mesh是下一代微服务。
在前不久Gartner发布2020年公共云容器报告，阿里云连续两年成为唯一入选的中国企业，并成为全球容器产品最完善的云服务厂商之一。其中Alibaba Cloud Service Mesh(ASM)也位列入选的产品中，Service Mesh到底是什么？ASM背后的技术演进是怎样？
对此，CSDN（ID：CSDNnews）专访阿里云高级技术专家、阿里云服务网格ASM技术负责人王夕宁，来一探究竟。
王夕宁表示，过去几年间Kubernetes得到了具有变革性的进展，最重要的原因之一是其API的设计更加考虑了开发人员。开发者可以在Kubernetes中创建应用部署或者服务，这些应用本身仍然在使用计算、网络和存储资源，开发者可以使用一致的API方式来创建和使用，而不需要关注于太多底层细节。
但是，仅仅在Kubernetes中运行一个Pod或者容器并不能解决复杂分布式应用的全部，应用除了运行本身的代码之外，还需要与其他应用服务进行网络通信交互。定义应用程序通信的API是云原生开发人员体验的关键部分，这些API通常被称为Service Mesh API。通过Service Mesh技术，重新定义了分布式应用之间的通信消息机制与诸如拓扑、路由、度量和访问控制的特性。
在服务网格技术使用之前，把一个单体应用程序向分布式的微服务架构进行改造，通常的服务治理逻辑的实现往往是以代码库的方式构建在应用程序本身中，这些代码库中包括了服务发现、熔断、限流等这样的一些功能，这些代码库的版本也可能不同，不同的情况下也可能会带来冲突问题。此外，库的版本一旦变更，即使你的应用逻辑并没有任何变化，整个应用也要随之全部变更。通过把这些服务治理的能力Sidecar化，就能够把服务治理的能力与应用程序本身进行了解耦，可以较好地支持多种编程语言、并且不需要依赖于某种特定技术框架。针对Sidecar代理的生命周期管理和针对应用程序本身的生命周期管理可以独立，提升了应用管理和运维管理的灵活性；同时这种去中心化的架构，有利于提升系统的可伸缩性。2、通过Sidecar机制逐渐地将服务治理功能标准化、统一化。随着这些Sidecar代理功能的增强，原本在代码库中包含的功能逐渐地下沉到这些代理中，这些功能包含了服务治理中需要到的诸如流量管理、熔断、重试、客户端负载均衡的能力、安全以及可观测性能力等。这些能力的标准化、统一化，可以解决复杂系统中的微服务实现中面临的差异大、缺少共性的问题，可以很好地支持不同的编程语言、不同的框架。3、容器编排技术的更加成熟，加速了Sidecar代理的普及与使用的便捷。试想一下，如果每一个Sidecar代理都需要手工去注入、管理它的生命周期，那它的价值与带来的复杂性相比，就显得比较单薄。Kubernetes是一个出色的容器部署和管理平台，提供的API可以支持很自然的扩展，Sidecar代理可以在应用程序的容器启动时自动注入到对应的Pod中。服务网格技术带来了上述优势，它使用起来的情况如何呢？我们知道，在云原生应用模型中，一个应用程序可能会包含数百个服务，每个服务又有数百个实例构成，那么这些成百上千个应用程序的Sidecar代理如何统一管理，这就是服务网格中定义的控制平面部分要解决的问题。作为代理，Envoy非常适合服务网格的场景，但要发挥Envoy的最大价值，就需要使它很好地与底层基础设施或组件紧密配合。Envoy构成了服务网格的数据平面，Istio提供的支撑组件则是创建了控制平面。这些Sidecar代理形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。数据平面扮演了一个用来建立、保护和控制通过网格的流量的角色。负责数据平面如何执行的管理组件称为控制平面。控制平面是服务网格的大脑，并为网格使用人员提供公开API，以便较容易地操纵网络行为。这些复杂配置也是用户经常遇到的一些挑战，特别是在支持多集群、如何支持用户自建的IDC内的集群、如何支持非容器化应用的统一管理，这些基本成为了用户使用服务网格技术的阻碍。解决这些问题的方式，是需要全部托管控制平面的组件，降低用户使用的复杂度，用户只需要专注于业务应用的开发部署。在托管模式下，保持与Istio的兼容，支持声明式的方式定义灵活的路由规则，支持多个Kubernetes集群的统一流量管理。在安全上，用户可以一键启用或者禁用双向TLS认证，整个网格内的安全配置动态生效；在多集群模式下，用户也不需要去维护根证书了，这些事情都会交给平台来管理。此外，在深入分析服务网格方面，提供了网格诊断能力，把过去一年多来用户遇到的问题以及如何解决这些问题的手段变成产品能力；同时优化集成跟踪、日志服务等来提升端到端的可观测性。
2018年，阿里云容器服务ACK产品中以addon的方式集成了Istio，以社区开源Isito为基础，优化整合了阿里云的相关服务，例如跟踪服务、日志服务等提升端到端的观测性；通过使用阿里云的CEN云企业网，打通了多个集群的统一管理，将多集群下的Pod实现互联互通和统一管理。在接近两年的时间中，跟随社区的快速发展，迭代发布了多个版本，来支持目前在云上的数百个用户集群。2020年2月，阿里云发布了业内首个全托管，Istio兼容的服务网格产品ASM。
ASM控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立，降低用户使用的复杂度，用户只需要专注于业务应用的开发部署。在托管模式下，保持与Istio的兼容，支持声明式的方式定义灵活的路由规则，支持多个Kubernetes集群的统一流量管理。此外，ASM在Istio基础上进行大量的扩展。ASM整合阿里云服务包括可观测性服务、日志服务、基于云企业网实现跨VPC网络互连能力等，同时也优化整合了社区开源软件包括开放策略代理OPA的支持、授权服务的定制化能力等。随着Isito1.5新架构的优化，将WebAssembly技术引入服务网格，使得ASM架构成为：托管的高可用弹性控制平面 + 可扩展的插件式的数据平面。在数据平面的支持上，ASM产品可以支持多种不同的计算基础设施，这包括了阿里云ACK Kubernetes集群、ASK集群、以及针对ECS虚拟机的支持。此外，ASM也在今年4月份推出多云混合云的支持，可以支持用户自身IDC建设的Kubernetes集群或者运行在其他云提供商上的Kubernetes集群使用服务网格能力。通过ASM提供统一的服务治理能力，可以实现就近访问，故障转移，灰度发布等功能，支持云容灾、异地多活等应用场景，提升业务连续性。
随着微服务的发展，企业进行一些服务治理体系的演进，如从Spring Cloud到Service Mesh迁移，需要注意哪些问题？ 王夕宁回答道，Netflix是最早采用微服务的公司之一。为了跟上其增长速度，Netflix决定从单一的数据中心转移到基于云的微服务架构，来实现高可用性，规模和速度。Netflix OSS是Netflix开源的一组库和框架，用于解决大规模设计分布式系统的问题。Spring Cloud基于Spring Boot开发，里面使用了Netflix OSS这套库和框架，提供了一套完整的微服务解决方案。从功能角度来看，Spring Cloud与Service Mesh在服务治理场景下，存在较多的重叠，这也就为从Spring Cloud向Service Mesh迁移提供了一种潜在的可能性。当前两者所解决的问题尽管是类似的，即微服务架构中分布式特点带来的复杂性问题；然而两者解决相同问题的方式手段不尽相同，在《 Istio服务网格技术解析与实践》书提到这一点，详细对特定应用程序库的缺点的分析、Istio网格与传统微服务框架的比较，希望这些内容能够让读者理解他们之间的差异。Linux容器简化了应用程序的打包部署，容器是云原生应用基石，通过应用容器化，不仅使得开发部署更加敏捷、迁移更加灵活，并且将这些实现标准化。而容器编排则是更近一步，负责解决如何高效地编排和利用好这些资源。Kubernetes编排容器服务已经成为一种事实标准；同时微服务与容器在轻量、快速部署、运维等特征的匹配，微服务运行在容器中也正成为一种标准实践。类似于Istio的这些服务网格技术在微服务治理上很好地补齐了Kubernetes，同时它又与Kubernetes有着完美的集成，不同于现有的微服务架构如SpringCloud、Dubbo或者Netflix OSS等。由上述可知，如从Spring Cloud到Service Mesh迁移，应用的容器化是第一个需要注意的问题。越来越多的应用走在了通往应用容器化的道路上，容器化会成为应用部署的标准形态。无论哪种容器化运行环境，天然支撑服务注册发现这一基本要求，这就导致Spring Cloud体系应用上容器的过程中，存在一定的功能重叠，针对这部分重叠功能，不防分析下在Kubernetes是否可以满足这些能力。特别是一些大规模场景下，当迁移到Kubernetes环境时，需要考虑集群的规模、etcd集群的规模、节点配置及规模、网段划分等，是否合理规划，避免资源浪费。容器化环境规划好之后，就是针对应用服务的改造。这涉及到很多细节问题，需要根据应用本身特点具体来分析。大体上来讲，是围绕上述重叠功能模块依赖的去除或者替换，这里面可能会涉及到网关、熔断器、注册中心、负载均衡、链路跟踪等组件。本质上讲，重试、超时、客户端负载平衡、或者熔断等等，这些问题与应用程序功能本身相互独立，我们真正想要的是一种技术无关的方式来实现这些问题，并减轻特定于应用程序本身来实现。此外，强调的一点是一定不能将应用程序的安全性和正确性转移到Istio或任何服务网格上。构建正确和安全的应用程序的责任仍然是应用程序本身。
谈及未来，王夕宁表示，在过去的一年里，以Istio为代表的服务网格技术的快速发展和成熟完善。服务网格技术未来发展可分为2个方面：一方面服务网格技术架构优秀、提供的功能也比较丰富的，包括细粒度的流量管理、安全性、可观测性等，过去这些功能往往是需要若干个中间件拼凑在一起才是实现，它的复杂度绝对不低于服务网格技术本身。另一方面，随着Kubernetes的更加成熟稳定，基于Kubernetes的服务网格架构也随着变得更加成熟，控制面和数据面解耦使得托管变成现实，声明式的扩展方式更加灵活简便，数据面能力无论是从支持的基础设施形态上还是多云混合云边界上都随之不断增强扩展。
对于云计算未来技术的发展动态，王夕宁表示有以下三大发展技术趋势：
首先，Kubernetes深入企业应用。我们预期Kubernetes将会在大多数企业中被广泛采用，并继续保持其在容器编排方面的主导地位。尽管支持企业Kubernetes解决方案已经存在了很长一段时间，但在很多企业需求方面仍有提升空间，例如权限、治理、成本控制和集成。其次，混合云。据IDC预测，到2022年，50%的企业将部署统一的VMs、Kubernetes和多云混合云管理流程和工具，以支持跨本地和公有云部署的多云混合云管理和治理。同时，据IDC预测，中国90%以上的企业将依赖于本地/专属私有云、多个公有云和遗留平台的组合，以满足其基础设施需求。第三，服务网格。2020 年 Istio 作为控制平面的一种技术实现仍将在 Service Mesh 领域扮演核心角色。Istio 获得业界广泛关注的原因，在于背靠 Google 公司的内部工程实践，以及对工程实践的再思考和重新提炼。Istio 在过去一年的重要工作是完善功能和改善稳定性确保小规模生产可用，在 2020 年随着阿里巴巴采用这一技术实现大规模落地将为 Istio 的规模化运用提供真实的场景，这将使得 Istio 在接下来的一年在支持集群规模的能力上大幅提高。此外，Istio 的可运维性和架构的合理性在 2020 年也将迎来积极的变化，其部署和运维的复杂性高等问题将得到解决。嘉宾简介：王夕宁，阿里云高级技术专家，阿里云服务网格ASM技术负责人，关注Kubernetes、云原生、服务网格等领域。之前曾在IBM中国开发中心工作，曾担任专利技术评审委员会主席，作为架构师和主要开发人员负责或参与了一系列在SOA中间件、云计算等领域的工作，拥有50多项相关领域的国际技术专利。《Istio 服务网格解析与实战》作者。#欢迎来留言#
留言点赞数量最多的前三名
CSDN携手【机械工业出版社】送出王夕宁撰写的
《Istio 服务网格解析与实战》一本
截至6月22日12:00点
更多精彩推荐
☞中国最优秀的程序员都有哪些？王兴、张小龙、张一鸣是哪类？| 蒋涛说
☞前字节跳动程序员 28 岁提前退休引热议，网友：我也想！
☞听说你还没收到端午福利？程序人生来宠你！
☞秋名山老司机从上车到翻车的悲痛经历，带你深刻了解什么是 Spark on Hive！| 原力计划
☞MATLAB 被禁点燃导火索，国产软件路在何方？
☞破碎的互联网下，加密技术正在恢复数据主权！