经验总结

  1. 首页 > 生活 > >

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

生活百科


降低操作基础设施的难度既然要设计一款平台级的软件产品，那么就需要将复杂且不易被掌握的技术，抽象成为用户易于理解的功能 。DevOps 工程师设计的云原生平台产品，首要任务之一，是能够降低开发人员使用基础设施的门槛 。这个章节主要讨论的，是开发人员自行管理自己业务系统的运维特征 。
就拿存储这件事来说，开发人员到底关注什么呢？
围绕存储这个概念，我们可以说出一堆名词，块设备、文件系统、对象存储、本地磁盘、磁盘阵列、NFS、Ceph等等 。这些名词毋庸置疑都与存储相关，也的确会被各种业务系统所使用，但我相信，绝大多数的开发人员对这些名词并不关心 。
作为用户，开发人员只关心一件事情，我所负责的业务系统，指定目录中的数据需要被持久化的保存下来 。
大多数情况下，业务系统涉及到的存储场景都应该是简单的 。在云原生时代，我们甚至呼吁开发人员在开发业务系统的时候，应该尽量做到“无状态化”，即在业务系统中，不存在限制实例横向扩容的状态数据，至少做到不同实例之间，数据可以共享 。根据这一点，DevOps 工程师们完全可以为开发人员提供一个能够适应大多数场景的默认存储类型，各个云厂商提供的 NAS 类型存储是个很好的选择 。
使用复杂存储的场景更多见于业务系统所调用的各种中间件中，比如数据库需要高速稳定的块设备类型存储，再比如大数据领域的“存算分离”场景下对接对象存储等等 。然而在大多数场景下，这些复杂中间件的维护并不是开发人员应该关心的事情 。它们由专门的运维人员进行维护，开发人员只需要得到访问它们的地址即可 。
所以在这种简单存储场景下，开发人员最好可以仅仅填写一下自己需要被持久化的目录地址，由云原生平台来实现底层存储的配置 。对存储基础设施的操作，开发人员并不需要关心 。

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

文章插图
从使用体验上来说，Rancher 和 KubeSphere 可选择的存储类型很多，这是因为它们的产品生态优于 Rainbond，比如 Rancher Lab 直接推出了轻量级的存储解决方案 Longhorn，对于各大公有云厂商提供的存储产品驱动也都有集成 。Rainbond 依然在易用性方面做的够好，实现了上文中仅关注业务系统持久化目录的使用体验 。然而仅对 NFS 类型的存储支持比较完善，对于其他类型的存储支持，需要在底层基础设施中自建驱动，安装起来不如前二者方便 。
易于理解的应用模型从工作负载层面上讲，Kubernetes 只通过 Deployment、Statefulset 等抽象描述单个组件的特征，然而多数情况下，开发人员开发出的业务系统会包含若干微服务组件 。那么如何对整个业务系统进行统一的管理就变成了一个问题 。解决方案之一，就是通过云原生应用平台，在单个组件之上，抽象出应用这个概念 。应用应该是由人为规定的一组服务组件（workload）组成，服务组件之间具有显式或隐式的关联调用关系，彼此之间有机组合成为一个整体，作为一套完整的业务系统对外提供服务 。
开发人员可以将所有的服务组件视作一个整体来进行管理，而非机械的单独管理每一个服务组件，这种操作体验无疑会更简单，也便于开发人员理解 。对应用的管理可以包括统一的生命周期管理、统一的安装升级卸载，灵活拼装服务组件之间的调用关系，更合理的处理业务系统的交付流程 。
目前 Kubernetes 领域内较为成熟的交付工具 Helm，其设计也暗合此类模型，一条简单的 helm install xxx 命令，即可安装起一大堆组件以及围绕这些组件的配置 。

经验总结扩展阅读


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

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