经验总结

  1. 首页 > 生活 > >

云原生时代的DevOps平台设计之道( 五 )

生活百科


云原生时代的DevOps平台设计之道

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

文章插图
Rancher 由于其自身的定位，产品中没有集成任何微服务相关的能力，用户需要手动安装 Istio 等微服务框架，通过复杂的 yaml 配置，来引用微服务能力 。
KubeSphere 和 Rainbond 都在应用层面默认集成了 Service Mesh 微服务框架，不同之处是前者集成了 Istio 方案，而后者的 Service Mesh 微服务框架是自研的 。从使用体验上来说，KubeSphere 产品化的包装了 Istio，大幅度降低了 Istio 的使用体验，但这不意味着用户可以完全抛却 Istio 这一层的概念，应用内部的拓扑依靠事先的配置来体现 。Rainbond 自研的微服务框架易用性更高一些，已经实现了拖拉拽式的微服务拼装模式，这一点还是很惊艳的 。然而自己造的轮子过多，外部的其他方案有好的特性时想要快速集成接纳，就需要在微服务规范的对接层次更上层楼，毕竟 Istio、Linkerd 这些 Service Mesh 微服务框架一统江湖的情况下，其他生态的结合都会以它们为标准，而非自研框架 。目前 Rainbond 也提供集成方式接纳了 Istio 治理模式，但还没有得到大量用户的使用验证 。

经验总结扩展阅读


上一篇：2023年10月12日打水井好不好 2023年10月12日打水井吉日一览表

下一篇：药品阴凉柜温度和湿度