云原生时代运维开发的年终技术总结

Posted 2021-04-02 图解源码

在过去一年技术上的工作整体上就是两个关键字kubernetes与cloud, 这里给大家分享下过去这一年的思考，以及关注和探索的方向

Kubernetes

云原生

云原生(Cloud Native)通常被定义为Devops、微服务、敏捷基础设施三者的组合，通过敏捷的基础设施快速的进行业务架构的设计，并基于微服务的方式进行快速的业务开发与迭代，最终通过Devops快速的交付业务价值。如果是基于这个定义则更多的感觉还是Native，而并没有描述清楚Cloud的概念，在很长一段时间自己也在思考，既然kubernetes是云原生的基础底座，那他也必然是Cloud的实现，这块后续有时间整理整理这块，再做详细的分享

Kubernetes

年初的kubernetes源码系列分享让我认识了很多朋友，也让自己更深入的理解了云原生时代的技术底座的实现，也影响了在新公司自动化系统的设计，在更多的时候都期望以一种面向终态的思想去架构自动化系统，但是我低估了不确定性的环境和状态带来的不确定性。面向终态的设计更多的时候是期望系统根据期望状态进行自动化的决策，从而达到期望状态，通过一致性的决策与自动化流程，达到系统自运维的能力。但是在新公司由于基础环境的复杂性，根本无法适用这套理论，所以在后期的设计中，更多的时候我都是在思考如何安全的、快速的失败。不过我仍然相信未来所有的运维服务都会建立在kubernetes上，即使是非容器服务，未来也应该参考kubernetes的模型来构建，未来应该是"all in kubernetes, all in cloud"的方向，不过在传统运维本质上是面向过程的，如果要想转变成面向终态的，还是需要趟不少的坑，而且可以参考的实践也很少。

Cloud

Cloud是新工作的主要探索方向，这里给大家分享下这半年的方向性的探索，主要分为概念、云化、编排三个部分

概念篇

由于一些历史背景以及当前的环境因素，新的公司的运维系统进化并不是传统的paas路线，也不是devops路线，在加上公司的一些其他因素，导致平台的演进多少有点跳跃性，并且老板主要的目标是云控制平台，所以面临的挑战也比较大。

关于怎么构建Cloud的资料是真的不多，要么是纯方法论要么就是传统的基于虚拟化的，可以参考的设计是真的少，下面先给大家分享下技术方向，可落地的实践后续在慢慢分享。在做Cloud的时候，我们首先得思考自己做的是什么？Cloud从大的分类上当前分为：公有云、私有云、混合云。很多公司的建设应该都是先建立私有云，然后再利用公有云构建混合云，从而满足业务的弹性需求。从Cloud提供的服务类型上通常又分为: Iaas、Paas、Saas，相对于公有云公司内部平台的优势则通常是提供更贴近公司场景的专属Paas平台，结合Devops提高业务交付速度和质量。由于公有云的成熟，这两年有很多公司开始做云管理方面的平台和服务：cmp和msp。CMP全称是Cloud Management Platform即云管理平台，提供面向公有云、私有云、混合云的统一集成管理平台，也是这两年比较火的方向，开源的比较典型的有onecloud与crossplane，业务层架构通常如下：

接入层：提供自服务的门户以及对应的api和cli，提供多种用户入口，方便用户自助使用各种资源控制层：提供统一的资源模型、业务流程、数据同步、监控告警、调度、容灾等控制逻辑，为用户决策和分配对应的资源适配层：根据控制层的资源模型，来进行不同供应商的适配，提供无限扩展的能力

MSP全称是Managed Service Provider即云服务提供商，为客户提供了云基础设施和应用程序迁移方面的完整生命周期解决方案。他们在四个关键领域提供支持：规划和设计；构建和迁移；运行和操作；以及优化(引用自AWS MSP计划说明)，个人认为，在服务云化后，传统的运维除了Sre方向，则就是朝着MSP方向转变，以公司的云平台为基础成为业务团队的MSP

结合上面的概念，结合公司现状从可落地角度梳理出作为云控制平面的核心功能主要分为两部分：应用管理、基础服务云化，通过应用管理为业务提供从应用程序运行、迁移、自动化等完整的全生命周期管理的能力，提供服务云化提供敏捷的基础设施，打造自服务门户，下面重点聊下服务云化方向的思考

云化

服务云化从用户体验上简单来说就是可以让用户像使用公有云服务一样使用公司内部各种基础服务，核心是按需、弹性、自助；用户的所有操作能不能一站式自助操作完成？服务从申请到交付需要多长时间？如何满足用户的这些需求呢？

服务云化本质上有些类似服务集成，在传统的云计算中服务集成主要是通过SOA来进行，而在在以kubernetes为基础搭建的主流的paas平台中则是采用服务目录和Operator的两种集成模式。这里我们就只简单聊下服务目录和Operator。服务目录是基于open service broker云服务开放协议的实现，在kubernetes中是通过service catalog来实现，是目前能够找到比较成体系可落地的实践了，不过很多公司当前已经不在使用了。Operator则是基于k8s的crd模型的交付模式，主要代表则是crossplane、openshift项目，以及各大公有云提供的基于k8s的控制器。

两者本质区别在笔者看来则是一个是面向交付过程的，一个是基础设施及代码和面向终态的。Service catalog主要是通过一致的交付流程和协议来实现，而operator则是利用基础设施即代码和面向的思想，系统来自动化完成基础服务的交付。如果底层的基础服务已经稳定，结构确定，则通常使用operator的方式来进行交付更好，否则优先采用Service catalog的方式，可以保障业务快速交付。

编排

控制台除了将各个基础服务的数据集成之外，还有另外一个核心的功能就是编排。在应用管理领域通常我们有cicd流水线的编排，实现从source code到Image甚至到最终release的编排，而在服务云化里面则有多种服务组合交付的编排。为了应对分布式环境的不确定性以及运维工作本身的复杂性，除了传统的工作流编排之外，云控制台里面的编排，更多的还要提供状态的管控、容错、决策功能，以事件驱动的方式，感知业务环境的变化，并且自动做出决策，同时保障整个过程中的一致性状态，毕竟操作虽然是无状态的，但运维本身是有状态的。

未来

上面提到的这些概念以及相关系统的设计大多数已经完成了，有的部分也已经在开发和落地的过程中，今年的技术方向依旧是kubernetes和cloud，但是由于新公司的kubernetes实践机会会比较少，会主要分享一些基于kubernetes构建上层系统的实践和原理, cloud方向则主要的工作上半年会集中在服务云化接入与编排上，会分享一些对应系统的架构设计与实际遇到的问题，也希望正在做这个方向的朋友可以多多交流