BizWorks 应⽤平台基于 KubeVela 的实践

前⾔

BizWorks 与 KubeVela 的合作始于 1.0.5 版本，BizWorks 在 1.0.5 版本上完成了关键技术验证并且在 1.2.5 版 本上基础上扩展了 BizWorks 的应⽤部署和运维能⼒。通过近⼀年多的深度合作，BizWorks 通过 KubeVela 解决了⼀些痛点和诉求，同时基于 KubeVela 功能和特性也沉淀了⼀些实践，本⽂将分别通过介 绍 BizWorks 在 KubeVela 使⽤场景来讲述如何探索和实践云原⽣时代新⼀代 PaaS 平台持续交付能⼒的落地。

⼀、BizWorks 介绍

BizWorks(https://bizworks.aliyun.com/)是⼀体化的阿⾥云原⽣应⽤的开发和运营平台，内置阿⾥巴巴 业务中台构建的最佳技术实践。产品主要包括：业务建模平台、业务应⽤平台、演练压测平台、能⼒运 营平台、⼀体化运⾏和运维平台。BizWorks 提供的产品能⼒（图 1-1），普遍适⽤于企业云原⽣应⽤⾼ 效开发以及企业业务能⼒沉淀和复⽤的场景。

image.png

图 1-1 BizWorks 业务架构

BizWorks⼀体化运⾏和运维平台提供⼀站式的应⽤⽣命周期管理、运⾏托管和运维管控能⼒，⽀持多云 适配，因此应⽤的⽣命周期管理是不可或缺的，其中 CICD 作为应⽤持续演进的关键⽅式对客户产品发布 以及升级迭代扮演者⾄关重要的⻆⾊。

CI（持续集成）主要包括中台类应⽤、低代码类轻应⽤、托管类应⽤、集成类应⽤的构建和物料产出， 为客户透出个性化流⽔线能⼒，可以依据⽤户实际需求编排符合业务需求的流⽔线，也可以直接使⽤业 界沉淀的通⽤流⽔线产品。

CD（持续交付/持续部署）主要包括上述⼏类应⽤构建制品部署上线以及运维，为客户提供核⼼的部署 操作能⼒，⽤户可以基于内置的部署引擎完成应⽤的部署，同时也可以接⼊其他部署产品，例如 EDAS。 

本⽂将主要讲述探索如何使⽤KubeVela 在 BizWorks⼀体化运⾏和运维平台应⽤部署中落地。

⼆、应⽤交付的需求与落地

2.1 需求背景

BizWorks 对于应⽤交付的需求主要包括两个思考，第⼀个是在云原⽣技术背景下，应⽤交付应该基于云 原⽣技术架构进⾏设计，因为采⽤的应⽤交付技术选型要能够⽀持相应的技术组件诉求；第⼆个是从业 务需求出发，当前应⽤交付配置⾯临碎⽚化的境况，包括环境配置、资源规格配置、持久化配置、⽹络 ⼆、应⽤交付的需求与落地 2.1 需求背景 3 路由配置等，同时对于应⽤交付制品类型也不尽相同。为了满⾜上述的需求，BizWorks 选择使⽤ KubeVela 来实现应⽤的持续交付，保证客户环境交付终态的稳定性和可靠性。

2.2 应⽤部署架构

⽬前 Bizworks⽀持四种类型的业务应⽤，集成了部分开源或阿⾥云的中间件组件，其部分能⼒主要是通 过使⽤KebeVela 的 Application、Component、Trait 以及 WorkFlow 来实现（如图 2-1）。在 KubeVela Component 基础上 BizWorks 定义⾃⼰的⽆状态组件（stateless-component）、有状态组件（stafulcomponent）、组装⽹络（advanced-ingress-trait）等，然后通过 KubeVela 来屏蔽不同云⼚商或 Kubernetes 底座的复杂性和差异性，构成了当前 BizWorks 的应⽤部署架构。

image.png

图 2-1 BizWork 应⽤部署业务架构

2.2 碎⽚化配置的痛点与解决

对于平台来说提供的功能如果具有可扩展和灵活性的话，可以为平台增强现有能⼒和推出更好体验的功 能点带来强⼤的帮助。但是由于平台⾯对的使⽤者背景和诉求各不相同，为了能尽可能满⾜⼤多数场景 需求可能会导致配置化内容变得多⽽且散乱，这是当时⾯临的碎⽚化配置痛点。BizWorks 的解决⽅案是 借助 KubeVela 丰富和强⼤的插件和运维特征补丁功能，⾸先 KubeVela 的拥有很多常⻅的插件，例如分批 发布、fluxcd 等，并且也内置了很多可⽤性⾼的运维特征补丁，例如标签、注解、init-container、 ingress 等。如果没有定制化需求的话，使⽤KubeVela⾃带的插件和运维特征补丁基本就可以满⾜需求；

如果需要针对平台⾃身能⼒进⾏定制的话也是可以的，这⾥以⾃定义运维特征补丁为例，介绍下 BizWorks 如何实现⾃定义功能。

BizWorks 应⽤在发布时，可以⽀持⽤户⾃⼰配置⽹络路由（如图 2-2），因此就需要⽀持同时⽣效多个 ingress 和 service 的配置。我们在 KubeVela 内置的 ingress 运维特征基础上进⾏了改进，⽀持批量传⼊声 明的⽹络路由配置，然后通过 BizWorks 以⾃定义运维特征的⽅式下发到 KubeVela（相关 cue 定义⻅下⽅ 示例代码），最终⽣效到集群中。

"bizworks-ingress-comp-1-22": {type: "trait"annotations: {}description: "Enable public web traffic for the component, the ingressAPI matches K8s v1.20+."attributes: {podDisruptive: false}}template: {outputs: {// trait template can have multiple outputs in one traitif parameter.route != _|_ {for _, v in parameter.route {"service-\(v.serviceName)": {apiVersion: "v1"kind: "Service"metadata:name: v.serviceNamespec: {selector: "app.oam.dev/component": context.nameif v.serviceType != _|_ {type: v.serviceType}ports: [{port: v.servicePortprotocol: v.serviceProtocolTypetargetPort: v.port},]}}if v["ingressName"] != _|_ {"ingress-\(v.ingressName)": {apiVersion: "networking.k8s.io/v1"kind: "Ingress"metadata: {name: v.ingressNameannotations: {if !v.classInSpec {"kubernetes.io/ingress.class": v.class}if v.annotations != _|_ {for _, t in v.annotations {"\(t.name)": t.value}}}}spec: {if v.classInSpec {ingressClassName: v.class}if v["ingressProtocolType"] == "HTTPS" {tls: [{hosts: [v.domain,]secretName: v.secretName}]}rules: [{host: v.domainhttp: {paths: [{path: v.pathpathType: "ImplementationSpecific"backend: service: {name: v.serviceNameport: number: v.servicePort}},]}}]}}}}}}parameter: {route: [...{// +usage=Specify the port your server want to exposeport?: int// +usage=Specify the protocol your service want to exposeserviceProtocolType?: string// +usage=Specify the name your service want to exposeserviceName?: string// +usage=Specify the port your service want to exposeservicePort?: int// +usage=Specify the type your service want to exposeserviceType?: string// +usage=Specify the type your ingress want to exposeingressProtocolType?: string// +usage=Specify the name your ingress want to exposeingressName?: string// +usage=Specify the domain you want to exposedomain?: string// +usage=Specify the path you want to exposepath?: string// +usage=Specify the tls secret you want to usesecretName?: stringannotations?: [...{name: stringvalue: string}]// +usage=Specify the class of ingress to useclass: *"nginx" | string// +usage=Set ingress class in '.spec.ingressClassName' instead of'kubernetes.io/ingress.class' annotation.classInSpec: *false | bool}]}}

image.png

                     图 2-2 BizWorks 应⽤⽹络路由配置

2.4 实践案例

⾸先以⼀个⽆状态组件应⽤发布为例，介绍如何使⽤KubeVela 完成应⽤发布计划。BizWorks 继承 OAM 设计理念，将应⽤作为⼀个交付的整体，其内部由不同类型的组件构成，并且组件可以通过绑定⾃定义 运维特征补丁。应⽤内的组件可以按照⾃⼰的发布计划⾃⾏发布，并且组件之间产⽣的⼯作负载和⽹络 拓扑不会彼此影响，具体⻅图 2-3.

image.png

图 2-3 BizWorks 应⽤发布计划

BizWorks 还⽀持通过 helm chart 来部署复杂结构的应⽤组件，并且和⽆状态组件⼀样，⽀持⼀个应⽤下 同时发布多个 helm 类型的组件。如图 2-4 所示，模版中⼼提供了 helm chart 类型模版的上传、更新、下 载、删除的功能，然后通过平台定义的 helm 类组件完成模版组件的部署、回滚和删除操作。

image.png

图 2-4 BizWorks helm chart 应⽤发布

2.5 成果与收益

• 具备了基础的部署和运维能⼒ 

    - 借助 KubeVelaRollout，应⽤平台具备的基础的部署和运维能⼒，能够完全平台化覆盖应⽤实例的⽣命周期，运维⼈⼒成本降低 50%，公有云场景消除了产品间来回切换的成本 

    - 灵活的特征机制，为应⽤平台提供了便利的路由配置能⼒ 

• ⼀键搭建测试环境的快捷功能 

    - 基于 KubeVela 的 fluxcdAddon 和应⽤平台的模版中⼼，⽤户可以快速的搭建和释放⼀套测试环境，由原来正常 3-6 个⼩时缩减为 15 分钟左右就可以完整搭建

• 应⽤模型统⼀

    - KubeVela 相较于其他开源 CD 产品最⼤的优势，是其开放应⽤模型 OAM，声明式构建需要的资 源，对于有多云部署和应⽤配置统⼀的产品有很⼤的帮助，配置统⼀后运维⼈员不需要收集各 种格式的资源申请，完全可以通过平台化配置和 OAM 模型完成声明式资源创建，这部分效率⼏ 乎提升 100% 

此外，借助 KubeVela 的 CD 能⼒，BizWorks⽬前管理的集群和 Application 数量已经初具规模。其中公有 云⽀撑 50+集群，总计 300+应⽤；专有云⽀撑 10+局点，当前最⼤局点⽀撑 10+集群，130+应⽤。

三、未来规划

为了更好的⽀持后续平台能⼒的扩展和增强，BizWorks 在可预⻅的近期会继续与 KubeVela 开展深度合 作，⼤致规划包括：

• 可视化分批发布，基于 Kruise Rollout 和 KubeVela，⽀持⽆状态组件以及 helm chart 

• 弹性伸缩，兼容 ACK 和 Kubernetes 原⽣HPA 策略 

• 社区贡献，⾃定义的 definition 转化为 KubeVela 的 addon 

• ⾦丝雀发布，⽀持更好的流量控制和灰度策略

若有收获，点个赞吧～❤️