DataWorks 微服务集群的 Service Mesh 落地实践

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:

初心

DataWorks 是集团内外广泛使用的全域智能大数据平台,包含了 DataStudio、StreamStudio、HoloStudio、AppStudio、GraphStudio、PAIStudio、WebExcel 等众多的线上产品,每个产品都是类似于 IDE 形态的富交互单页应用。

101

但是,DataWorks 服务于集团各大业务线上万名数据开发者和数据生态的参与者,这艘巨大的航母却不能准确地表达每一个用户的述求,「众口难调」。

因此,DataWorks 在架构升级的关键节点,决心将插件化、服务化定制的能力彻底落地,解开过重的业务共建模式在研发上的耦合羁绊,向更轻量的更开放的平台化迈进,不忘服务初心,帮助我们内外客户的业务定制快速落地。

那么如何开放 DataWorks 的定制化能力?

我们建立了一整套完整的微服务研发管控体系, DataWorks 微服务平台(DMSP:DataWorks MicroService Platform),以满足业务开发者定制服务化需求,帮助业务整合DataWorks输出的中台能力,重新定义属于自己的业务数据研发平台。

轻车快马

轻装上阵,是对用户(开发者、业务方)而言的。要做到用户的轻,作为平台方,我们就要做得更多。

对于业务而言,最轻量的,就是「只需要关注业务逻辑」。

即,业务开发者仅仅专注在业务逻辑上,而不需要再自己关注 入流量 的安全认证、路由、负载均衡、镜像、限流;出流量 的超时、重试、访问控制;服务间调用的隔离策略、熔断、分布式追踪等与业务逻辑无关的内容。

过去,微服务生态周边发展出了大量组件、框架,帮助我们很好地解决上述的业务以外的问题。但是这些组件框架门槛高、维护成本高、开发语言耦合,对于大多数开发者而言,成本太高,不适用于有敏捷开发需求的新兴业务。

近年来火热的服务网格(Service Mesh)技术,正能够解开这一困局。参见《Service Mesh 入门》。

微服务集群能力

DMSP 是一套基于 Kubernetes 集群的微服务运行平台。我们在K8S的基础上,基于 Operator 开发打造了一个完整的微服务生命周期管理体系。

整体上, DMSP 分成几个领域的能力来增强微服务:
9D9A2F5C_EDBE_4768_9ACD_DF8697E2B139

DMSP Service Mesh 架构

基于上述集群能力的要求,我们将 Istio 的 Service Mesh 能力落地。整体架构如下:

102

下层 SOA 服务包括了 DataWorks 已有的许多重量级服务,包括租户、数据开发、AI平台等。

DMS Console 是微服务管控台,它是微服务开发者与服务集群之间的管控交互唯一路径,负责管控所有(包括阿里巴巴内部、阿里云公有云 22 个 Region )的集群,前面提到的部署、流量控制与灰度、动态的安全策略、服务治理(日志&监控&报警)等能力都会在这里承上启下。

管控台与集群控制平面 Control Plane 之间的交互,完全基于 K8s ApiServer,通过抽象的一层 CRD 进行交互,再由特定的 Operator 基于 CRD 执行管控逻辑。透过对 Istio 的管控,基于服务 Sidecar 达到对服务能力的延展。业务服务就像插上了翅膀,无缝地获得了集群赋予的能力,用最小的开发成本,享受最多的最健全的微服务能力。

Why Operator and CRD?

扩展 K8s 的最佳实践,是以 Operator + CRD 的方式来实现扩展。

基于 Kubernetes 的 Operator ,将服务部署和 Service Mesh 控制层面的工作直接前移到集群上,降低原本需要多集群多配置需求中心部署管控的复杂度:
103

最终一致性保证

管控操作的可靠性强,能够保证最终一致性,依靠两个优势:

1、Operator 框架基于 K8s 的 Event&Watch 机制( Reconcile Cycle ),事件触发通过多发+幂等保证最终一致性。(而实际上幂等性不需要开发者过分关注,因为有下面第二个优势)。

2、 K8s Resource CRUD 的 Generation 机制能保证 CRD 操作的原子性

基于这两个优势,开发 Operator 时只需要专注于最终结果是什么,在任何情况下都往最终你想要的结果推进即可。

业务逻辑边界清晰
利用 Kubernates Operator 操作自定义的一套 CRD ,业务逻辑配置的复杂度降低了,将每一个业务逻辑抽象出一个 CRD 定义,业务功能边界清晰可维护,健壮性非常高。

管控链路安全可控
基于 CRD 的交互,集群不需要透出额外的控制接口,所有外部管控操作都可以基于原生的 apiserver 规范进行控制,完全可复用 k8s 的 rbac 体系,一定程度上也保证了管控链路的安全可靠,权限精细可控。

具体可参考 OpenShift 的这篇最佳实践,详情点击这里

对 Istio 的抽象设计

Istio 的 CRD 体系较为复杂,因此我们需要实现一层简单的控制平面,对 Istio 做一层抽象,用简单易懂的 API 做管控交互。

达到四两拨千斤的效果。例如:

基于 Istio 原生的控制配置,需要大约 100 行, 3 个 CRD 协作完成的控制,抽象的一层管控逻辑只需不到 10 行, 1 个 CRD :

spec:
  service: myservice1
  rules:
  - version: "1.1"
    weight: 70
  - version: "1.2"
    weight: 30
  - version: "2.0"
    weight: 100

服务路由(Route)

微服务迭代迅速,开发敏捷。因此,金丝雀版本流量的精细化控制是集群建设的首要重点。

这也是我们常说的「版本灰度」,那么灰度能力的支持主要分为两种:
1、流量权重灰度
2、规则灰度

权重灰度

按比例调整到达服务特定版本的流量。

在这里,我们设计了大小版本,约定了开发流程中,每个大版本升级需要访问不同的域名 /ContextPath 。每个大版本下的小版本流量比例合为 100 。

示例:
spec:
  service: httpbin
  rules:
  - version: "1.0"
    weight: 80
  - version: "1.1"
    weight: 20
  - version: "2.0"
    weight: 100

调整后,对服务流量监控进行可视化的效果:

104

规则灰度

按照特定的匹配规则,将服务流量定向到特定的版本。

spec:
  service: myservice1
  rules:
  - version: "2.0"
    matches:
    - headers:
        gray:
          exact: "1"
    - queryParams:
        debug:
          exact: "true"

描述了当 header 中包含 gray=1 或者 query 参数中包含 debug=true 时,流量访问到版本 1.1 。

我们通过埋在 Response 中的 header ,就可以知道灰度的效果:

105

服务安全

服务安全针对流量方向分为 Mesh 出入口的南北流量管控和 Mesh 内部的东西流量管控:
1、南北流量主要利用 Ingress Gateway 的 VS 能力管控入口流量,基于 Sidecar + Egress Gateway 管控出口流量
2、东西流量需要通过 mTLS + AuthorizationPolicy 进行控制

通过这些手段来增强集群(尤其是公有云集群)中微服务的安全性。

Ingress 入流量

入口流量的一部分管控需求,在前文「服务路由」中包含。在服务安全方面,包括了全局上的能力,例如:

  • CORS 跨域配置
  • CSRF 保护
  • 流量登录认证

CORS 和 CSRF 基于 Sidecar Filter 即可覆盖统一的通用规则,做进一步的细化和动态配置的需求不强。

流量登录认证,主要用于认证前端访问流量的身份是否合法(没有涉及权限体系),会对接各个常用的登录体系,目前支持的主要是 DataWorks 自有的登录体系。

我们设计了一套灵活的认证框架,基于Filter + 符合规范的认证服务的方式,达到登录认证的需求。

Egress 出流量

Egress 出流量是指访问Mesh网格之外的流量,例如,微服务访问阿里云 OSS 服务等操作。

为了防止服务被攻击后,访问未知的恶意网站,特别在高安全级别的集群环境,需要在默认情况下 0 信任任目标地址,再基于白名单的机制来打通特定的信任地址。

目前 Flannel 网络实现没有支持 NetworkPolicy ,阿里云 ACK 提供的集群默认是 flannel 网络(可选 terway 方式避免),所以基于 Pod 的 NetworkPolicy 不会生效,所以在 Istio 管控之外的 Pod 仍然需要防护,被 istio 管控的 pod 也暂时只有一层 istio 的安全机制保障

默认拒绝访问
配置 sidecar( mesh ) 访问所有 Service( Mesh 外部)的 outbound 流量都需要基于 ServiceEntry 注册才能够访问(即,默认拒绝所有连接)。

kind: IstioControlPlane
spec:
 gateways:
   components:
     egressGateway:
       enabled: true
 values:
   global:
     outboundTrafficPolicy:
       mode: REGISTRY_ONLY

配置生效之后,任何 pod 之间经过 SideCar 进行互相访问的流量都会检查是否注册过 ServiceEntry 。

未注册的服务效果如下:

$ kubectl exec -it sleep-788f7c9bcb-m67rh -c sleep -- curl -I www.aliyun.com
HTTP/1.1 502 Bad Gateway

502 的意思就是 DNS 和 IP 都通,但是访问会被 sidecar 拦截掉

观察流量可以看到,所有流量都到了 BlackHoleCluster ,一个专门用来接收被block的请求的内置 Cluster 。

PassthroughCluster 同理

106

白名单机制
然后,基于默认拒绝的策略,我们在这个基础之上增加白名单。

全局白名单
首先,ServiceEntry 这套 API 并没有 selector 支持对单独某些 workload 生效,一旦配置存在,就是全局有效的。它只支持 namespace 级别的隔离(基于 ExportTo 参数)。

我们将其抽象出一层动态配置,便于未来平滑支持更多的配置规则:

spec:
  service: sleep
  hosts:

  - "www.aliyun.com"

观察流量,可以看到所有流量都走了 Entry 定义的端点,访问得以放行:

107

服务访问控制

服务访问控制是指微服务之间的访问授权机制。在0信任网络中,默认是拒绝所有服务的访问。

在网格中, mTLS 机制用于服务之间身份校验,每个服务都有自己的基于 K8s 的 ServiceAccount ,根据 istio 提供的 mTLS 机制对证书进行身份校验。

因此,服务之间互相访问就有了身份的区别,那么就可以通过 AuthorizationPolicy 直接进行流量的权限控制。

配置默认拒绝:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  {}

生效后:403 RBAC: access denied 。

$ kubectl exec -it sleep-788f7c9bcb-m67rh -c sleep -- curl -i httpbin:8000/get
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Mon, 13 Jan 2020 16:09:16 GMT
server: envoy
x-envoy-upstream-service-time: 0
RBAC: access denied

未来

我们借助 Service Mesh 技术,构建了一套 DataWorks 定制化开放 API 的微服务 DevOps 体系。

希望通过我们的努力,能够极大地降低开发门槛,让业务接入更敏捷,让开发迭代更迅速。

未来, DataWorks 团队将提供更多面向微服务生态的管控和治理能力。

作者信息:袁赓拓,花名三辰,阿里云智能-计算平台事业部技术专家,负责数加平台 &DataWorks 的微服务生态建设,目前主要关注微服务、Service Mesh 等相关技术方向。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
一站式大数据开发治理平台DataWorks初级课程
DataWorks 从 2009 年开始,十ー年里一直支持阿里巴巴集团内部数据中台的建设,2019 年双 11 稳定支撑每日千万级的任务调度。每天阿里巴巴内部有数万名数据和算法工程师正在使用DataWorks,承了阿里巴巴 99%的据业务构建。本课程主要介绍了阿里巴巴大数据技术发展历程与 DataWorks 几大模块的基本能力。 课程目标  通过讲师的详细讲解与实际演示,学员可以一边学习一边进行实际操作,可以深入了解DataWorks各大模块的使用方式和具体功能,让学员对DataWorks数据集成、开发、分析、运维、安全、治理等方面有深刻的了解,加深对阿里云大数据产品体系的理解与认识。 适合人群  企业数据仓库开发人员  大数据平台开发人员  数据分析师  大数据运维人员  对于大数据平台、数据中台产品感兴趣的开发者
相关文章
|
2天前
|
敏捷开发 监控 API
构建高效微服务架构:从理论到实践
【5月更文挑战第18天】 在当今快速发展的软件开发领域,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序分解为一系列小型、独立的服务来提高系统的可伸缩性、弹性和维护性。本文旨在探讨如何从理论走向实践,构建一个高效的微服务架构。文章首先介绍微服务的基本概念和优势,然后详细讨论了在设计和部署微服务时需要考虑的关键因素,包括服务划分、通信机制、数据一致性、容错处理和监控策略。最后,结合具体案例分析,展示如何在现实世界中应用这些原则,确保微服务架构的高效运行。
|
2天前
|
测试技术 持续交付 API
构建高效的微服务架构:后端开发的现代实践
【5月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业追求敏捷、可扩展和容错能力的关键解决方案。本文将深入探讨微服务的核心概念,包括其设计原则、技术栈选择以及实施过程中的挑战与对策。通过对微服务架构实践的详细剖析,旨在为后端开发人员提供一套构建和维护高效微服务系统的实用指南。
|
5天前
|
消息中间件 Go API
基于Go语言的微服务架构实践
随着云计算和容器化技术的兴起,微服务架构成为了现代软件开发的主流趋势。Go语言,以其高效的性能、简洁的语法和强大的并发处理能力,成为了构建微服务应用的理想选择。本文将探讨基于Go语言的微服务架构实践,包括微服务的设计原则、服务间的通信机制、以及Go语言在微服务架构中的优势和应用案例。
|
5天前
|
监控 测试技术 持续交付
构建高效可靠的微服务架构:后端开发的现代实践
【5月更文挑战第14天】 随着数字化转型的浪潮,企业对于灵活、可扩展且高效的后端系统的需求日益增长。本文旨在探讨如何通过微服务架构来实现这些需求,涵盖微服务设计原则、开发流程以及持续集成和部署(CI/CD)的最佳实践。文中还将讨论监控、日志管理与容错机制,以确保系统的可靠性和性能。
|
5天前
|
Kubernetes Cloud Native 持续交付
构建高效稳定的云原生应用:容器编排与微服务治理实践
【5月更文挑战第14天】 随着企业数字化转型的深入,云原生技术以其弹性、敏捷和可扩展的特性成为现代应用开发的首选模式。本文将探讨如何通过容器编排工具如Kubernetes以及微服务架构的有效治理,构建和维护高效且稳定的云原生应用。我们将分析容器化技术的优势,并结合案例讨论在多云环境下实现持续集成、持续部署(CI/CD)的最佳实践,同时解决微服务带来的分布式复杂性问题。通过本文的阐述,读者将获得一套提升系统可靠性和业务连续性的策略框架。
7 0
|
5天前
|
监控 数据库 开发者
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第11天】在当今软件开发的世界中,微服务架构已经成为构建可扩展、灵活且容错的系统的首选方法。本文深入探讨了设计、部署和维护微服务系统时面临的挑战,并提出了一系列实用的策略和最佳实践。我们将从服务的划分原则出发,讨论如何确保每个微服务的自治性,以及如何通过容器化和编排技术实现服务的高效运行。文章还将涉及监控、日志记录和故障恢复的策略,旨在帮助开发人员构建一个既高效又可靠的微服务环境。
15 1
|
5天前
|
缓存 负载均衡 API
微服务架构下的API网关性能优化实践
【5月更文挑战第10天】在微服务架构中,API网关作为前端和后端服务之间的关键枢纽,其性能直接影响到整个系统的响应速度和稳定性。本文将探讨在高并发场景下,如何通过缓存策略、负载均衡、异步处理等技术手段对API网关进行性能优化,以确保用户体验和服务的可靠性。
|
5天前
|
存储 监控 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第9天】 在本文中,我们将深入探讨如何在后端开发中构建一个高效的微服务架构。通过分析不同的设计模式和最佳实践,我们将展示如何提升系统的可扩展性、弹性和维护性。我们还将讨论微服务架构在处理复杂业务逻辑和高并发场景下的优势。最后,我们将分享一些实用的工具和技术,以帮助开发者实现这一目标。
|
5天前
|
监控 API 持续交付
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第8天】在当今快速演进的软件开发领域,微服务架构已经成为实现敏捷开发、持续交付和系统弹性的关键模式。本文将探讨构建一个高效且可靠的微服务系统所必须的策略和最佳实践。我们将从服务的划分与设计原则出发,讨论如何通过容器化、服务发现、API网关以及断路器模式来优化系统的可伸缩性和鲁棒性。此外,我们还将涉及监控、日志管理以及CI/CD流程在确保微服务架构稳定运行中的作用。
|
5天前
|
敏捷开发 持续交付 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第8天】 在数字化转型的浪潮中,微服务架构已成为企业追求敏捷开发、持续交付和系统弹性的关键解决方案。本文将深入探讨微服务的核心概念,包括其设计原则、优缺点以及如何在后端开发中实现高效的微服务架构。我们将通过实际案例分析,展示微服务如何帮助企业快速适应市场变化,同时保持系统的可维护性和扩展性。