初心
DataWorks 是集团内外广泛使用的全域智能大数据平台,包含了 DataStudio、StreamStudio、HoloStudio、AppStudio、GraphStudio、PAIStudio、WebExcel 等众多的线上产品,每个产品都是类似于 IDE 形态的富交互单页应用。
但是,DataWorks 服务于集团各大业务线上万名数据开发者和数据生态的参与者,这艘巨大的航母却不能准确地表达每一个用户的述求,「众口难调」。
因此,DataWorks 在架构升级的关键节点,决心将插件化、服务化定制的能力彻底落地,解开过重的业务共建模式在研发上的耦合羁绊,向更轻量的更开放的平台化迈进,不忘服务初心,帮助我们内外客户的业务定制快速落地。
那么如何开放 DataWorks 的定制化能力?
我们建立了一整套完整的微服务研发管控体系, DataWorks 微服务平台(DMSP:DataWorks MicroService Platform),以满足业务开发者定制服务化需求,帮助业务整合 DataWorks 输出的中台能力,重新定义属于自己的业务数据研发平台。
轻车快马
轻装上阵,是对用户(开发者、业务方)而言的。要做到用户的轻,作为平台方,我们就要做得更多。
对于业务而言,最轻量的,就是「只需要关注业务逻辑」。
即,业务开发者仅仅专注在业务逻辑上,而不需要再自己关注 入流量 的安全认证、路由、负载均衡、镜像、限流;出流量 的超时、重试、访问控制;服务间调用的隔离策略、熔断、分布式追踪等与业务逻辑无关的内容。
过去,微服务生态周边发展出了大量组件、框架,帮助我们很好地解决上述的业务以外的问题。但是这些组件框架门槛高、维护成本高、开发语言耦合,对于大多数开发者而言,成本太高,不适用于有敏捷开发需求的新兴业务。
近年来火热的服务网格(Service Mesh)技术,正能够解开这一困局。参见[《Service Mesh 入门》][1]。
微服务集群能力
DMSP 是一套基于 Kubernetes 集群的微服务运行平台。我们在 K8S 的基础上,基于 Operator 开发打造了一个完整的微服务生命周期管理体系。
整体上, DMSP 分成几个领域的能力来增强微服务:
领域 | 说明 |
---|---|
Service | Service 相关的功能包括: 1、服务注册 2、多版本部署 3、AutoScaling 4、资源 Quota 管理 等 workload 相关的能力。 主要关注 service mesh 管控之下的 workload 生命周期,不属于 mesh 层有 |
Route | Route 是指服务路由控制相关的功能(区别于 Traffic 中的高级流量控制能力),主要包括: 1、金丝雀部署流量控制(按流量比例权重的灰度) 2、规则灰度(基于 header、params 等判断的规则灰度) |
Security | 服务安全相关的管控,也包括一些全局的安全 Filter: 1、CORS 2、CSRF 3、Ingress 流量登录认证 4、Egress 流量访问白名单 5、服务 mTLS 认证与访问权限控制(Authentication and Authorization) |
Traffic | Traffic 中包含高级的流量控制能力,除了 Route 流量路由以外的其它功能,包括: 1、限流(Rate Limit) 2、熔断(Circuit Breaking) 3、镜像(Mirroring) 4、超时(Timeout) 5、故障注入(Fault Injection) |
Telemetry | Telemetry 翻译过来是遥测,这里我们称为服务治理,包括: 1、访问跟踪(Tracing) 2、日志归集(Logging) 3、服务监控 & 访问统计(Metrics) 4、可视化(Visual) |
Js中文网 – 前端进阶资源教程 www.javascriptC.com,typescript 中文手册
专注分享前端知识,你想要的,在这里都能找到
DMSP Service Mesh 架构
基于上述集群能力的要求,我们将 Istio 的 Service Mesh 能力落地。整体架构如下:
下层 SOA 服务包括了 DataWorks 已有的许多重量级服务,包括租户、数据开发、AI 平台等。
DMS Console 是微服务管控台,它是微服务开发者与服务集群之间的管控交互唯一路径,负责管控所有(包括阿里巴巴内部、阿里云公有云 22 个 Region )的集群,前面提到的部署、流量控制与灰度、动态的安全策略、服务治理(日志 & 监控 & 报警)等能力都会在这里承上启下。
管控台与集群控制平面 Control Plane 之间的交互,完全基于 K8s ApiServer,通过抽象的一层 CRD 进行交互,再由特定的 Operator 基于 CRD 执行管控逻辑。透过对 Istio 的管控,基于服务 Sidecar 达到对服务能力的延展。业务服务就像插上了翅膀,无缝地获得了集群赋予的能力,用最小的开发成本,享受最多的最健全的微服务能力。
Why Operator and CRD?
扩展 K8s 的最佳实践,是以 Operator + CRD 的方式来实现扩展。
Operator:
https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
基于 Kubernetes 的 Operator ,将服务部署和 Service Mesh 控制层面的工作直接前移到集群上,降低原本需要多集群多配置需求中心部署管控的复杂度
最终一致性保证
管控操作的可靠性强,能够保证最终一致性,依靠两个优势:
1、Operator 框架基于 K8s 的 Event&Watch 机制( Reconcile Cycle ),事件触发通过多发 + 幂等保证最终一致性。(而实际上幂等性不需要开发者过分关注,因为有下面第二个优势)。
2、 K8s Resource CRUD 的 Generation 机制能保证 CRD 操作的原子性
基于这两个优势,开发 Operator 时只需要专注于最终结果是什么,在任何情况下都往最终你想要的结果推进即可。
业务逻辑边界清晰
利用 Kubernates Operator 操作自定义的一套 CRD ,业务逻辑配置的复杂度降低了,将每一个业务逻辑抽象出一个 CRD 定义,业务功能边界清晰可维护,健壮性非常高。
管控链路安全可控
基于 CRD 的交互,集群不需要透出额外的控制接口,所有外部管控操作都可以基于原生的 apiserver 规范进行控制,完全可复用 k8s 的 rbac 体系,一定程度上也保证了管控链路的安全可靠,权限精细可控。
具体可参考 OpenShift 的这篇最佳实践:
https://blog.openshift.com/kubernetes-operators-best-practices/
对 Istio 的抽象设计
Istio 的 CRD 体系较为复杂,因此我们需要实现一层简单的控制平面,对 Istio 做一层抽象,用简单易懂的 API 做管控交互。
达到四两拨千斤的效果。例如:
基于 Istio 原生的控制配置,需要大约 100 行, 3 个 CRD 协作完成的控制,抽象的一层管控逻辑只需不到 10 行, 1 个 CRD :
JS中文网 – 前端进阶资源教程 https://www.javascriptc.com/
一个致力于帮助开发者用代码改变世界为使命的平台,每天都可以在这里找到技术世界的头条内容
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
调整后,对服务流量监控进行可视化的效果:
规则灰度
按照特定的匹配规则,将服务流量定向到特定的版本。
spec:
service: myservice1
rules:
- version: "2.0"
matches:
- headers:
gray:
exact: "1"
- queryParams:
debug:
exact: "true"
// JS中文网 - 前端进阶资源教程 [https://www.javascriptc.com/](https://www.javascriptc.com/)
// 一个致力于帮助开发者用代码改变世界为使命的平台,每天都可以在这里找到技术世界的头条内容
描述了当 header 中包含 gray=1 或者 query 参数中包含 debug=true 时,流量访问到版本 1.1 。
我们通过埋在 Response 中的 header ,就可以知道灰度的效果:
服务安全
服务安全针对流量方向分为 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 。
未注册的服务效果如下:
JS中文网 – 前端进阶资源教程 https://www.javascriptc.com/
一个致力于帮助开发者用代码改变世界为使命的平台,每天都可以在这里找到技术世界的头条内容
$ 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 同理
白名单机制
然后,基于默认拒绝的策略,我们在这个基础之上增加白名单。
全局白名单
首先,ServiceEntry 这套 API 并没有 selector 支持对单独某些 workload 生效,一旦配置存在,就是全局有效的。它只支持 namespace 级别的隔离(基于 ExportTo 参数)。
我们将其抽象出一层动态配置,便于未来平滑支持更多的配置规则:
spec:
service: sleep
hosts:
- "www.aliyun.com"
观察流量,可以看到所有流量都走了 Entry 定义的端点,访问得以放行:
服务访问控制
服务访问控制是指微服务之间的访问授权机制。在 0 信任网络中,默认是拒绝所有服务的访问。
在网格中, mTLS 机制用于服务之间身份校验,每个服务都有自己的基于 K8s 的 ServiceAccount ,根据 istio 提供的 mTLS 机制对证书进行身份校验。
因此,服务之间互相访问就有了身份的区别,那么就可以通过 AuthorizationPolicy 直接进行流量的权限控制。
配置默认拒绝:
JS中文网 – 前端进阶资源教程 https://www.javascriptc.com/
一个致力于帮助开发者用代码改变世界为使命的平台,每天都可以在这里找到技术世界的头条内容
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 等相关技术方向。
作者:
链接:https://www.infoq.cn/article/dawOLPXApOD2q5TvgleQ
看完两件小事
如果你觉得这篇文章对你挺有启发,我想请你帮我两个小忙:
- 把这篇文章分享给你的朋友 / 交流群,让更多的人看到,一起进步,一起成长!
- 关注公众号 「画漫画的程序员」,公众号后台回复「资源」 免费领取我精心整理的前端进阶资源教程
本文著作权归作者所有,如若转载,请注明出处
转载请注明:文章转载自「 Js中文网 · 前端进阶资源教程 」https://www.javascriptc.com