Introdução: Como o primeiro produto de malha de serviço Alibaba Cloud totalmente gerenciado e compatível com Istio do setor, o ASM manteve a consistência com a comunidade e as tendências do setor desde o início. cluster é independente.
Autor: Wang Xining
O conteúdo deste artigo é baseado no discurso do autor na 2022 Cloud Native Industry Conference.
fundo
Revise a evolução do sistema de arquitetura de serviço de aplicativo. Do ponto de vista do método de processamento do chamador do serviço e do provedor, ele pode ser dividido em três etapas.
O primeiro estágio é o balanceamento de carga centralizado, ou seja, o chamador do serviço é roteado para o provedor de serviço correspondente por meio de um balanceamento de carga externo. Suas vantagens são óbvias, não é intrusivo para o aplicativo em si, pode suportar vários idiomas e vários frameworks para desenvolver e implementar o próprio aplicativo, o balanceamento de carga é um gerenciamento unificado e centralizado e toda a implantação é simples. No entanto, a desvantagem também é muito significativa: por ser centralizado, a escalabilidade é limitada e a capacidade de governança de serviço desse balanceamento de carga centralizado é relativamente fraca.
A segunda etapa refere-se à governança distribuída de microsserviços, ou seja, os recursos de governança internos dos chamadores de serviço são integrados aos aplicativos na forma de bibliotecas SDK. A vantagem é que toda a escalabilidade é melhor e a capacidade de governança de serviços é forte, mas ao mesmo tempo, prestará atenção às suas desvantagens, incluindo a intrusão do próprio aplicativo, a dificuldade de suporte a vários idiomas por causa de seu dependência do SDK e do gerenciamento e implantação distribuídos. Complicações, etc.
O terceiro estágio é a tecnologia atual de service mesh. Ao sidecarizar esses recursos de governança de serviço, os recursos de governança de serviço podem ser desacoplados do próprio aplicativo e várias linguagens de programação podem ser melhor suportadas. Ao mesmo tempo, esses recursos secundários não precisam depender de uma estrutura técnica específica. Esses proxies sidecar formam um plano de dados em malha através do qual todo o tráfego entre serviços é processado e observado. A face de controle fornece gerenciamento unificado desses proxies sidecar. Mas isso traz uma certa complexidade.
A figura a seguir é um diagrama de arquitetura de uma malha de serviço. Conforme mencionado anteriormente, sob a tecnologia service mesh, cada instância de serviço de aplicativo será acompanhada por um proxy sidecar, e o código de negócios não está ciente da existência do sidecar. Esse proxy Sidecar é responsável por interceptar o tráfego de aplicativos e fornece três funções: governança de tráfego, segurança e observabilidade.
No modelo de aplicativo nativo da nuvem, um aplicativo pode conter vários serviços, e cada serviço é composto por várias instâncias, então os proxies Sidecar dessas centenas de aplicativos formam um plano de dados, que é mostrado na camada de plano de dados da figura.
E como gerenciar esses proxies sidecar de maneira uniforme, esse é o problema a ser resolvido pela parte do plano de controle da malha de serviço. O plano de controle é o cérebro da grade de serviço. Ele é responsável por distribuir a configuração para o proxy sidecar do plano de dados, gerenciar como os componentes do plano de dados são executados e também fornecer uma API unificada para que os usuários da grade manipulem facilmente a grade capacidades de gestão.
Normalmente, com uma malha de serviço habilitada, desenvolvedores, operadores e equipes de SRE abordam o gerenciamento de serviços de aplicativos de maneira unificada e declarativa.
Infraestrutura de aplicativo nativa da nuvem com tecnologia de malha de serviço
Como uma tecnologia central básica para gerenciar a comunicação de serviços de aplicativos, o service mesh oferece recursos de roteamento de tráfego, segurança e observabilidade seguros, confiáveis, rápidos e independentes de aplicativos para chamadas entre serviços de aplicativos.
Pode-se observar que a infraestrutura de aplicativos nativos da nuvem sob a benção do service mesh traz vantagens importantes, que são divididas em seis aspectos.
Uma das vantagens: governança unificada de serviços heterogêneos
• Interoperabilidade e governança de arquitetura multilíngue e multiframework, dual-mode integrada ao sistema tradicional de microsserviços
• Controle de tráfego multiprotocolo refinado, gerenciamento unificado do tráfego leste-oeste e norte-sul
• Descoberta automática de serviços para infraestrutura de computação heterogênea unificada
A segunda vantagem: observabilidade de ponta a ponta
• Operação e manutenção inteligentes integradas integrando log, monitoramento e rastreamento
• Topologia de grade visual intuitiva e fácil de usar, sistema de identificação de saúde codificado por cores
• Melhores práticas integradas, diagnóstico de rede de autoatendimento
Vantagem 3: Segurança Zero Trust
• Criptografia mTLS de ponta a ponta, controle de acesso baseado em atributos (ABAC)
• Mecanismo de política declarativa OPA, identidade de carga de trabalho globalmente exclusiva (Identidade)
• Histórico de auditoria completo e insights com painéis
Vantagem 4: Otimização de desempenho de combinação suave e dura
• A primeira plataforma de malha de serviço baseada na tecnologia Intel Multi-Buffer para aprimorar a criptografia e descriptografia TLS
• O NFD detecta automaticamente os recursos de hardware, oferece suporte adaptativo a recursos como conjunto de instruções AVX, aceleração QAT, etc.
• O primeiro lote a ser aprovado na certificação avançada de plataforma de grade de serviços de nuvem confiável e avaliação de desempenho
Benefício nº 5: Resiliência de aplicativos orientada por SLO
• Política de Objetivo de Nível de Serviço (SLO)
• Dimensionamento elástico automático de serviços de aplicativos com base em dados observáveis
• 多集群流量突发下的自动切换与故障容灾
优势之六：开箱即用扩展&生态兼容
• 开箱即用的 EnvoyFilter 插件市场、WebAssembly 插件全生命周期管理
• 与 Proxyless 模式的统一融合, 支持 SDK、内核 eBPF 方式
• 兼容 Istio 生态系统, 支持 Serverless/Knative, AI Serving/KServe
下图是服务网格 ASM 产品当前的架构。作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。
托管式服务网格 ASM 在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及基于 WebAssembly 实现统一的代理可扩展能力, 以此构筑企业级能力。
服务网格技术的下一站如何发展
Sidecar Proxy 与 Proxyless 模式的融合一句话来总结的话，就是同一个控制面, 支撑不同的数据面形态。同一个控制面就是指使用 ASM 托管侧组件作为统一的标准形式的控制入口, 这个控制面运行在阿里云侧，属于 hosted 托管模式。
而数据面支持 Sidecar Proxy 与 Proxyless 模式的融合, 其中数据面的组件虽然不是 hosted 托管模式, 但是也是 managed 模式, 也就是说这些组件的生命周期也是由 ASM 统一来管理, 包括分发到数据面、升级、卸载等。
具体来说, 在 Sidecar Proxy 模式下, 除了当前标准的Envoy代理之外, 我们的架构可以比较容易地支持其他 Sidecar, 譬如说 Dapr Sidecar, 当前微软 OSM+Dapr 就是采用了这种双 Sidecar 模式。
在 Proxyless 模式下, 为了提升 QPS 降低时延, 可以使用 SDK 方式, 譬如 gRPC 已经支持 xDS 协议客户端, 我们的 Dubbo 团队也在这条路上。我想今年我和北纬团队双方是可以一起在这个点上进行一些突破实现。
另外一个 proxyless 模式, 就是指- 内核 eBPF + Node 级 Proxy 方式。这个模式是对 sidecar 模式的一个根本性改变, 一个节点只有一个 Proxy，并且能力 offload 到节点上。这部分我们今年也会有些产品落地。
围绕服务网格技术, 业界存在着一系列以应用为中心的生态系统, 其中, 阿里云托管服务网格 ASM 支持了以下多种生态系统。列举如下：
现代化软件开发的生命周期管理和 DevOps 创新
服务网格的核心原则（安全性、可靠性和可观察性）支持了现代化软件开发的生命周期管理和 DevOps 创新, 为在云计算环境下如何进行架构设计、开发、自动化部署和运维提供了灵活性、可扩展性和可测试性能力。 由此可见, 服务网格为处理现代软件开发提供了坚实的基础，任何为 Kubernetes 构建和部署应用程序的团队都应该认真考虑实施服务网格。
DevOps 的重要组成部分之一是创建持续集成和部署 (CI/CD)，以更快更可靠地向生产系统交付容器化应用程序代码。在 CI/CD Pipeline 中启用金丝雀或蓝绿部署可为生产系统中的新应用程序版本提供更强大的测试，并采用安全回滚策略。在这种情况下，服务网格有助于在生产系统中进行金丝雀部署。当前阿里云服务网格 ASM 支持了与 ArgoCD、Argo Rollout、KubeVela 以及云效、Flagger 等系统的集成实现了应用的蓝绿或金丝雀发布, 具体如下：
ArgoCD[1] 职责主要是监听 Git 仓库中的应用编排的变化，并集群中应用真实运行状态进行对比，自动/手动去同步拉取应用编排的变更到部署集群中。如何在阿里云服务网格 ASM 中集成 ArgoCD 进行应用程序的发布、更新，简化了运维成本。
Argo Rollouts[2] 提供了更强大的蓝绿、金丝雀部署能力。在实践中可以将两者结合来提供基于 GitOps 的渐进式交付能力。
KubeVela[3] 是一个开箱即用的、现代化的应用交付与管理平台。使用服务网格 ASM 结合 KubeVela 可以实现应用的渐进式灰度发布，达到平缓升级应用的目的。
阿里云云效流水线 Flow[4] 提供了基于阿里云服务网格 ASM 完成 Kubernetes 应用的蓝绿发布。
Flagger[5] 是另外一种渐进式交付工具，可自动执行在 Kubernetes 上运行的应用程序的发布过程。它通过在测量指标和运行一致性测试的同时，逐渐将流量转移到新版本，降低了在生产中引入新软件版本的风险。阿里云服务网格 ASM 已经支持通过 Flagger 实现这种渐进式发布能力。
微服务框架兼容[6]
支持 Spring Boot/Cloud 应用无缝迁移至服务网格进行统一纳管和治理, 提供了融合过程中出现的典型问题解决能力, 包括容器集群内外服务如何互通、不同的语言服务之间如何进行互联互通等常见场景。
Serverless 容器与基于流量模式的自动扩缩[7]
Serverless 和 Service Mesh 是两种流行的云原生技术，客户正在探索如何从中创造价值。 随着我们与客户深入研究这些解决方案，问题经常出现在这两种流行技术之间的交集以及它们如何相互补充上。我们能否利用 Service Mesh 来保护、观察和公开我们的 Knative 无服务器应用程序？在一个托管的服务网格 ASM 技术平台上支持基于 Knative 的 Serverless 容器, 以及基于流量模式的自动扩缩能力, 从中可以替换如何通过托管式服务网格来简化用户维护底层基础设施的复杂度, 让用户可以轻松地构建自己的 Serverless 平台。
AI Serving[8]
Kubeflow Serving 是谷歌牵头发起的一个基于 Kubernetes 支持机器学习的社区项目，它的下一代名称改为 KServe, 该项目的目的是可以通过云原生的方式支持不同的机器学习框架，基于服务网格实现流量控制和模型版本的更新及回滚。
零信任安全及 Policy As Code[9]
在使用 Kubernetes Network Policy 实现三层网络安全控制之上，服务网格 ASM 提供了包括对等身份和请求身份认证能力、Istio 授权策略以及更为精细化管理的基于 OPA(Open Policy Agent) 的策略控制能力。
具体来说, 构建基于服务网格的零信任安全能力体系包括了以下几个方面：
-
零信任的基础：工作负载身份；如何为云原生工作负载提供统一的身份；ASM 产品为服务网格下的每一个工作负载提供了简单易用的身份定义，并根据特定场景提供定制机制用于扩展身份构建体系, 同时兼容社区 SPIFFE 标准；
-
零信任的载体：安全证书，ASM 产品提供了如何签发证书以及管理证书的生命周期、轮转等机制，通过 X509 TLS 证书建立身份，每个代理都使用该证书。并提供证书和私钥轮换；
-
零信任的引擎：策略执行，基于策略的信任引擎是构建零信任的关键核心，ASM 产品除了支持 Istio RBAC 授权策略之外，还提供了基于 OPA 提供更加细粒度的授权策略；
-
零信任的洞察：视化与分析，ASM 产品提供了可观测机制用于监视策略执行的日志和指标，来判断每一个策略的执行情况等；
改造为云原生应用带来的业务价值非常多，其中一个就是弹性扩缩容，它能够更好地应对流量峰值和低谷，达到降本提效的目的。服务网格 ASM 为应用服务间通信提供了一种非侵入式的生成遥测数据的能力, 指标获取不需要修改应用逻辑本身。
根据监控的四个黄金指标维度（延迟、流量、错误和饱和度），服务网格 ASM 为管理的服务生成一系列指标, 支持多个协议, 包括 HTTP，HTTP/2，GRPC，TCP 等。
此外, 服务网格内置了 20 多个监控标签, 支持所有 Envoy 代理指标属性定义、通用表达式语言 CEL, 支持自定义 Istio 生成的指标。
同时，我们也在探索拓宽服务网格驱动的新场景，这里举一个AI Serving的示例[10] 。
这个需求来源也是来自我们的实际客户, 客户的使用场景就是希望在服务网格技术之上运行 KServe 来实现 AI 服务。KServe 平滑运行于服务网格之上, 实现模型服务的蓝/绿和金丝雀部署、修订版本之间的流量分配等能力。支持自动伸缩的 Serverless 推理工作负载部署、支持高可扩展性、基于并发的智能负载路由等能力。
总结
作为业内首个全托管Istio兼容的阿里云服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区Istio定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。
A partir de 1º de abril de 2022, o Alibaba Cloud Service Mesh ASM lançará oficialmente uma versão comercial, fornecendo recursos mais avançados, suporte em maior escala e melhor suporte técnico para melhor atender aos diferentes cenários de demanda dos clientes.
Link original: click.aliyun.com/m/100034811…
Este artigo é o conteúdo original do Alibaba Cloud e não pode ser reproduzido sem permissão.