云原生时代的DevOps平台设计之道( 四 ) _生活百科

易于理解的应用模型从工作负载层面上讲，Kubernetes 只通过 Deployment、Statefulset 等抽象描述单个组件的特征，然而多数情况下，开发人员开发出的业务系统会包含若干微服务组件。那么如何对整个业务系统进行统一的管理就变成了一个问题。解决方案之一，就是通过云原生应用平台，在单个组件之上，抽象出应用这个概念。应用应该是由人为规定的一组服务组件（workload）组成，服务组件之间具有显式或隐式的关联调用关系，彼此之间有机组合成为一个整体，作为一套完整的业务系统对外提供服务。
开发人员可以将所有的服务组件视作一个整体来进行管理，而非机械的单独管理每一个服务组件，这种操作体验无疑会更简单，也便于开发人员理解。对应用的管理可以包括统一的生命周期管理、统一的安装升级卸载，灵活拼装服务组件之间的调用关系，更合理的处理业务系统的交付流程。
目前 Kubernetes 领域内较为成熟的交付工具 Helm ，其设计也暗合此类模型，一条简单的 helm install xxx 命令，即可安装起一大堆组件以及围绕这些组件的配置。

文章插图
Rancher 并没有实现自己的应用模型，其应用的安装方式集成了 Helm，并没有体现出应用管理能力。
KubeSphere 则更进一步，在项目下的应用负载中提出了应用的概念。在应用中可以通过 Helm 或自建的形式部署服务，集成了微服务治理、单个组件的版本控制、路由管理、灰度发布等能力。其对 Helm 模板的支持，使得其从理论上可以支持任何市面上已有的 Helm Chart 包的安装部署。
Rainbond 的应用概念是最完善的，除了常规的生命周期操作、整个应用级的版本控制这样的常规能力之外，还有些非常易用的自研功能，能够简化开发人员对自己应用的管理。比如基于泛解析域名机制实现的对外服务域名，点击开启对外服务，就会生成一个公网可用的域名访问自己的应用，这比一层一层的配置 Ingress 规则容易太多。又比如应用复制能力，可以批量的将整套应用复制到另一个工作空间，而不必重新手动搭一套。
应用模板是 KubeSphere 和 Rainbond 均提出的一个概念，应用模板存在的意义是可以将开发好的应用复制到不同的环境中去，是一种制备新一代制品并交付分发的技术。应用模板的基础使用体验，是可以快速方便的安装整套应用系统，最好是一键化的体验， KubeSphere 和 Rainbond 都提供了应用商店，供用户快速安装一些已经制作好的应用模板。应用模板更高层次的使用体验，则是开发人员可以无任何技术负担的开发出自己的应用模板，而不仅仅是从应用商店拉取别人制作好的应用模板。
易于掌控的微服务架构微服务架构也是云原生平台不可缺少的一个元素。微服务架构旨在帮助开发人员建设高类聚、低耦合的现代应用系统，将以往烟囱式的业务系统架构，拆散成为一大堆彼此间更为独立，包含自身功能特点的微服务模块。容器与相关编排技术的成熟，为微服务架构的落地打下了基础。云原生应用平台，则为开发人员更简单的入手微服务框架提供了可能。
云原生平台首选的微服务框架，应该是以 Istio、Linkerd 为代表的 Service Mesh 微服务框架，也被称为“服务网格” 。相对于 Spring Cloud 、 Dubbo ，这种微服务框架提供了更高的自由度和适应性，开发人员不需要被某种开发语言或产品绑定，只需要回归网络编程即可将自己的业务系统连接成为一个整体。这里要重点提出的是微服务架构对业务代码无侵入，只有无侵入的实现，才能最大限度降低开发人员花费精力学习其他领域知识的可能性。
DevOps 工程师可以通过设计云原生平台功能来进一步优化配置微服务的使用体验，大胆设想一下，开发人员只需要在两个服务组件之间拖动一条表征微服务调用关系的线，就可以生成对应的微服务配置。这样的操作体验完全可以使注册中心、控制平面这种微服务领域中复杂的概念对开发人员屏蔽。本质上讲，维护注册中心或者控制平面也是运维人员需要关心的工作。