云原生，为云而生依云而生

Posted 2021-04-23 运行管理大家谈

从2017年开始关注云原生相关话题，之后一直关注着云原生领域的发展，也一直尝试着相关实践，随着2019年信通院云原生首场大会召开，“云原生”一词如雨后春笋般席卷大地。

前段时间与朋友聊天，正学习和计划推进使用云原生技术，非常希望我写一篇相关稿子，因此这个稿子也算是约稿，在稿子中我要做到的是：

对云原生抽丝剥茧、深入浅出、见林观木、贴近实践......

同时也希望能给予热爱和关注云原生的朋友以指导和帮助。

所有新事物的产生都是在解决一系列问题，云原生的产生解决哪些问题？

 

问题一：过去十几年，云技术得到了快速发展，通过虚拟化技术实现了物理资源上云，但传统的虚拟化平台只提供了基础运行环境，云端强大的服务能力（如动态弹性、高并发）并没有被最大化利用，云计算的红利也没有完全释放；

问题二：面向云应用的开发环境变的更复杂，云端需要提供适应于各业务场景的整套开发环境，以降低用户云应用开发难度，使得用户更加专注在业务逻辑开发上；

问题三：应用开发架构应该更适应于云环境，应该通过应用架构的改变，充分发挥云端的服务能力。

 

基于以上问题的解决，Pivotal公司在2013年诞生并提出了云原生概念。云原生是一系列云计算技术体系和企业管理方法的集合，既包含了实现应用云原生化的方法论，也包含了落地实践的关键技术。

基于云原生的技术和管理方法，更好地让企业开发云应用，或者将应用迁移至云平台，从而享受云的高效和持续服务能力。云原生技术以其高效稳定、快速响应的特点驱动引领企业的业务发展，帮助企业构建更加适用于云上的应用服务。

云原生1.0

两大驱动力

云原生的推进主要有两大驱动，是云原生技术发展的主要动力，也是云原生厂商寻求业务机会的主要依据。

一是基础架构的变革，在自主可控技术的推进下，原有的小型机逐步退出历史的舞台，受限于PC Server管控数量激增，非常需要使用云原生相关技术完成大量节点管控。

二是应用场景的变化，随着移动互联网金融发展、民营银行及泛金融崛起，银行同业间的业务竞争加剧，迫使银行转向通过互联网技术获客和活客，相应的应用系统也必须具备快速迭代、快速应对交易潮涌能力，满足高并发、灵活扩展需求，从而云原生技术成为必要的选择。

 

三大改变方向

       云原生技术的诞生，开启了云原生时代，从开发模式、应用架构，到基础架构都发生了一定的变革，具体如下：

通过变革让云计算的弹性、灵活、自动化等优势得到充分发挥，使得软件工程管理、基础设施管理更加高效和自治，帮助银行管理者将精力集中到业务创新中。

 

四大基础技术

常见的云原生的核心技术包括持续集成、容器、微服务、DevOps，通过持续集成和微服务框架完成微服务的开发和测试，通过容器完成部署和运行，按照DevOps管理理念和框架完成一体化云应用的构建和管理。

其中，在当前的云原生技术实践中，持续集成、容器、微服务都是通过集成多个开源框架来实现的。

 

• 持续集成

持续集成是对软件开发过程管理，用于软件版本分支和集成、审核开发人员代码。在每次集成中，通过自动化的构建（包括编译，发布，自动化测试）验证，尽早发现代码集成错误。常用的持续集成开源框架：

 

• 容器

容器是一种轻量级的虚拟化技术，能够在单一主机上提供多个隔离的操作系统环境，通过一系列的namespace进行进程隔离，每个容器都有唯一的可写文件系统和资源配额。

（1）容器的两种部署模式

（2）使用容器的收益

（3）常用的容器相关开源框架

 

• 微服务

微服务是指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述着一个小业务，系统中的各个简单应用可被独立部署。

微服务之间是松耦合，可以独立对每个服务进行升级、部署、扩展和重新启动等流程。相比传统的单体架构，微服务架构具有降低系统复杂度、独立部署、独立扩展、跨语言编程等特点。

微服务技术架构实践中，主要包括有侵入式架构和非侵入式架构两种实现形式。

侵入式架构是指服务框架嵌入程序代码，实现类的继承，以 Spring Cloud为代表。

有侵入式架构~Spring Cloud

非侵入式架构则是以代理的形式，与应用程序部署在一起，接管应用程序的网络且对其透明，以Service Mesh为代表。

非侵入式架构~Service Mesh

关于Spring Cloud与Service Mesh两种架构的对比，互联网中有大量文章，在此不再赘述。

• DevOps

（1）DevOps初衷

为适应应用的快速迭代、快速发布，需要打破原有的部门壁垒，但同时带来了管理架构的变化、流程制度的变化、增加了运维风险，对于风控要求严格、监管日益趋严的银行业该如何做呢？

（2）DevOps表现形式

迭代加速，频繁上线，但如何完成回归测试、如何保障代码质量呢？

（3）DevOps生态

面对庞杂的开源生态，如何集成是最优模式，如何保障集成后的框架稳定性、安全性及性能，如果保障框架的换代更新呢？

实践感悟：不要被DevOps的理念所迷惑，任何事务落地都需要配套投入、持续投入，不要因为有了一点点投入，就希望达到翻天覆地的变化，因地制宜、最适合自己的永远也是最正确的。

云原生的推进，对运维提出了很高的要求和变革挑战，运维部门需要做好充足的准备，积极应对人员、技术、流程和资源四大方面的变革。

关于敏态运维的变化，请阅读本号下“银行业双态IT运维实践”文章，本文重点关注云原生推进需要解决的问题和实践方法。

哪些银行需要云原生

最近几年在国有银行、股份制银行客户中，纷纷开展使用云原生技术，但在省农信、城商行群体，受限于技术积累及经营区域的限制，多数仅使用了虚拟化技术，虽然有些银行已经建设了私有云，但往往也停留在虚拟化层面。

随着以互联网为渠道的金融业务开展，部分银行对个别应用系统微服务改造，相应也使用了容器技术，甚至有些银行成立了敏捷部落，真正实践DevOps管理体系。

结合近几年的实践，需要使用云原生的银行总结如下：

云原生问题如何解决

（1）开发与运维隔离：开发运维一体化（DevOps体系）并不是将开发与运维进行融合，而是创造更加便捷的互动方式，不因快速迭代、快速发布造成应用版本质量的下降，不因应用发布对在线业务造成影响，不给运维造成难以承担的工作量：

通过镜像实现对接、通过一键操作完成发布

通过灰度发布，保障在线业务正常运行

（2）容器厂商选择：

银行业对应用的可用性及连续性有着较高的要求，所以选择容器厂商最好具备多个同行业、大型应用相关案例，或者自我具备一定的研发能力，采用与厂商共研模式建立容器平台，容器厂商一般具备持续集成、微服务开发平台，可以一起打包选择。

（3）DevOps体系的整体推进：

    这是一个综合工程，单纯依靠开发部门或运维部门，都无法完成DevOps体系的整体推进，至少需要科技部门的架构部门整体推进，或者在全行级进行组织架构变革，如成立敏捷组织等，目前大力宣传DevOps体系的都是非银行案例，非银行客户无需涉及开发与运维隔离问题。

从以下银行实例中，敏捷部落中并没有运维人员，所以DevOps并不涉及开发部门或运维部门的整合。

 

云原生的实施过程

云原生各技术实施没有必然的强制性逻辑关系，可以根据自身的实际情况确定先后顺序，当然为减少系统的迁移工作，可以几个平台一步到位建设。

如果微服务部署节点比较少，容器发挥的效力不会很显性，只有节点比较多时，容器应用的迁移、扩容、部署才会显得非常简单和省力。

落地容器比如关键的一步是微服务容器化，需要微服务开发厂商与容器厂商进行配合和对接，工作量一般很少，很容易完成。

云原生2.0

云原⽣领域的标准化进程将持续深化 

我国云原生技术的标准建设仍处于起步阶段，标准较为分散、不成体系。需要国内的标准化组织统筹规划，做好云原生领域的标准规划和顶层设计，充分发挥标准的引领指导作用。

 

云原生技术生态日趋完善，细分项目不断涌现

云原生已趋于细分、多元化发展，不再局限于容器、微服务、DevOps 等技术领域，逐步扩展至底层技术、编排及管理技术、安全技术、监测分析技术以及场景化应用等众多分支，如云原生服务器、云原生存储、云原生网络、安全容器、裸金属容器、云原生数据库等，最终将形成支撑云应用的全生命周期技术链。

云原生2.0技术生态

 

云原⽣助⼒⼈⼯智能从云端扩展⾄边缘 

微服务架构的盛行正在加速 AI 生态系统中功能解耦。AI 模型中不同粒度的功能如分类、聚类、识别、预测、自然语言处理、卷积、重现等都再向微服务化转变。借助云原生技术，云端智能正在加速向边缘智能扩展。实现边缘智能化，需要把云上的模型，快速迁移到线下，将云上智能改造为边缘可用的轻量级智能，适配边缘软硬件环境和使用场景。

 

“新基建”开启云原⽣新篇章 

后疫情时代随着企业全面复工复产稳步推进，“上云用数赋智”已经成为企业共识，空前的市场需求和政策利好引爆数字技术的资本市场，以云计算为核心的新一代数字技术迎来新的发展机遇。云原生成为下一代云计算的技术“内核”，云原生技术栈统一的标准化交付能力大幅提升云端效能。

 

<全文完>