编辑/子蕊

校对/正宇

1月16日，中科院计算所博士高级工程师，深信服前云计算首席专家李明宇，参加了第一新声举办的“数字中国-2021年高科技高成长年度峰会”，并以《云原生与数字化转型》为主题进行了分享。

主要内容有，数字化转型带来新的两大挑战，一是导致业务系统复杂度和规模迅速的增长。二是业务对IT系统的依赖达到了空前的高度；未来分布式应用和多云/混合云架构成为主流，而云原生落地需要容器、服务网格、微服务、不可变基础设施、声明式API等技术，其中Kubernetes是重点；此外，还提供了十几种云原生应用的设计模式可以参考。

以下为演讲实录，经第一新声编辑整理，有删减：

数字化转型带来两大新挑战

传统的IT系统建设模式下，一个企业构建 IT系统的基本单元是机器，即准备一台或多台机器，安装软件，实现完整的大、小系统。

后来出现了虚拟机，虚拟机是通过软件方式，在一台物理机器上创建多台虚拟的机器，目前云的世界里经常提到的云服务器、云主机，也是基于这种技术实现，在虚拟机中安装软件实现IT系统，本质上还是基于机器的模式。这种模式存在时间很长，即使现在有了云也仍然广泛存在，租用云主机并安装应用软件来构建系统即属于这种模式的实践。

过去十几年，随着信息化和数字化的发展，IT系统尤其是应用软件越来越庞大，对资源的可管理性要求越来越高，例如灵活性、供给效率等。虚拟化的优势是，机器是虚拟出来的，可以被云平台统一管理，根据应用、业务的需要去创建多台虚拟机器，从而使硬件资源管理的灵活性，硬件配置的效率得到提升。

现在数字化转型带来新的两大挑战。一是导致业务系统复杂度和规模迅速地增长。践行数字化转型的过程中，会发现一台机器甚至多台机器组成集群也不能够满足需求，这时候分布式应用以及底层的云平台，还有多云、混合云架构逐渐成为主流。

二是业务对IT系统的依赖达到了空前的高度。第一要有高度可用性，如果 IT系统不转了，业务就会受到非常大的影响，IT系统停一秒钟，业务直接造成损失。第二敏捷性，业务想做调整、改变，对IT系统也跟着提出调整和演进的需求。第三业务在不断地发展，对于可扩展性也提出了新的要求。

这些新的挑战导致无论是物理机器还是虚拟机器，在机器上安装软件构建IT系统，这种基于机器的模式都不能够满足需求。

而云平台是数据中心级别的，管理一个数据中心，也可能是跨多个数据中心，这种大的云平台也可能是混合云、甚至跨多个云的多云平台。

 

那么能否有一种模式，由管理数据中心级别资源的平台，向上提供API，直接支持应用系统的构建？

应用是基于云平台去构建，而不再基于一个个机器的模式。分布式应用和数据中心级别资源统一管理，这两个事情配合在一起，突破以前基于机器的模式，形成一种新的模式，这就是人们所说的 “云原生（Cloud Native）”模式。相应的，我个人把之前基于机器的传统模式称之为“Machine Native”。从Machine Native逐步演进到Cloud Native（云原生），让业务系统的可用性、敏捷性和可扩展性得到大幅提升，从而解决现在面对的数字化转型所带来的新挑战。

云原生落地需要哪些技术？

实现“云原生”的落地，需要有技术的支撑。

云原生计算基金会（CNCF，Cloud Native Computing Foundation）给出了一个关于“云原生技术”的定义，中间提到了一些典型技术，例如容器（包括容器编排）、服务网格、微服务、不可变基础设施、声明式API等。

CNCF给出了一张技术全景图：

 

技术不断地发展，全景图也在演进和扩大。这里重点介绍Kubernetes，这个软件在云原生技术体系里，有非常重要的基础性和核心地位。整个云原生技术体系很大程度上都是基于K8s构建。

从产业视角来看，可以说Google正在试图在数据中心领域复制它在移动领域的成功。我们现在都知道智能手机领域的两大阵营：安卓和苹果，Google当年开源安卓，对抗的并不是苹果，而是为了防止微软在移动领域复制其在桌面领域的成功，Google创建了开放手机联盟，构建了一套现在非常庞大的基于安卓的体系。

类似的，在云计算领域，AWS是该领域有绝对地位的头部企业，Google开源了K8s并正在领导社区建立一个基于K8s的云原生体系。类似于智能手机联盟，这里有云原生计算基金会。

 

在发展的过程当中，K8s作为云原生体系的技术核心也像当年安卓一样，已经淘汰了其他的对手。开源开放并不意味着和平，也是充满了残酷的竞争。像以前Android在市场上淘汰了Symbian、Windows Mobile等，当年也有一些引发了高度关注的云原生平台核心基础软件，例如Mesos、Docker Swarm等，在Google和K8s社区的影响下，现在都已被淘汰退出了历史舞台。这里面有技术因素也有非技术因素。

分享一个数字化转型的实际案例，某集团下面有n个厂，存在能效不够优化的问题。而国外已经有先进的方法，即利用生产过程多个环节中收集的数据，通过数据分析手段，得出优化方案。

这个集团也想采用类似的方案，于是开发了一个数据分析软件，部署到各个厂。一开始用传统集成架构，在开发的过程中由多方服务商合作完成，整个生产流程各个厂可能不一样，设备的采购选型也不一样，导致没有一家服务商能够把所有的数据收集、分析等链条做下来。另外，这个软件是不断迭代开发演进的，一方面因为这本身就具有探索性质，另一方面也是数字化转型中常见的现象，因为数字化转型需要IT直接支持业务，市场在不断变化，业务系统如果不具备敏捷性，就会被淘汰。

集团采用先试点后推广的方式，这是对的，也是新技术、新模式导入的常见方式，但是后来遇到问题了。

开始先试点，有3~5个的算法和数据分析模块集成到一起，部署到1~2个厂应用到2~3套生产流程。部署的时候是采购计算能力比较强的工控机，部署到现场再安装软件。可以看到这就是典型的前面提到过的“Machine Native”的模式。

试点的效果很好，推广的时候出现问题了。整个系统集成的数据分析组件或者算法增长到了20~30个，因为要尽可能的把需要分析的环节都纳入进来做分析。 另外，需要适配10~20个工厂、30多套不同生产流程，中间有些环节的问题是共性的，有些是个性化的。定制化不可避免，这就意味着需要针对应用维护很多个版本，分发到不同的厂子去做部署。系统的复杂度增长加上分支版本过多，导致bug频出、迭代周期变长，20~30个组件集成在一起的时候又是多方合作，最终导致系统难以维护、版本混乱、新功能无法实现等。

后来的做法是采用Cloud Native（云原生）的模式对其进行重构。把算法模块用一个个微服务给跑起来，基于容器镜像进行打包发布。突破了以往采用集成框架把算法模块集成起来的做法，而是开发了一个编排引擎，采用了服务编排（服务治理）及容器编排的方式把独立运行的算法微服务编排起来。

 

在实部署实施的时候，不再是以机器为模型，而是到云平台上通过镜像+服务的方式发布。在云端开租户，这里的租户相对弱隔离，适用于一个集团内部各个厂或者业务线。在租户上面，根据生产流程去设计算法编排的模板，把模板提交上去，相应的算法就会被调度发布出来，然后面向新业务生产流程的数据去进行分析。

通过这种方式，资源规划、部署、算法、迭代的问题都解决了。不需要再去考虑每个厂的数据量、生产流程不一样，采购什么样的机器。每一个算法更新自己镜像就可以了，滚动发布上线，不会对业务系统的运行造成停顿，也降低了几十个合作方做集成联调的频率。不同生产流程下来的数据量不一样，特别是对于数据量比较大的业务线，在云平台上对每个租户用多少资源也可以灵活调度管理。

数据存储全部用服务化的方式，存储设备不在服务器的本地。这样数据的共享、可靠性、可用性都得到了提升。

用Cloud Native（云原生）的模式对业务系统进行重构以后，以前沉淀下来的算法得以继续利用，把整个架构用新的模式整改，前面提到的问题迎刃而解。这是在数据化数字化转型中用Cloud Native去解决问题的一个实际案例。

云原生应用模式如何设计？

一个单点技术并不能解决一个应用场景的所有问题，需要通过多个技术组合起来。并且企业发展过程中可能面对IT架构设计、评审、开发-运维的协同，问题排查等诸多问题。

新技术导入时经常遇到的一个问题是：一个应用场景有多个技术点去支撑才能够做好，中间可能考虑得不够全面，导致效果不佳。这些新技术本来是为企业服务的，但因为对其没有充分地利用，在引入新技术以后面临新的困难。在GitHub上面看到很多云原生技术相关的issue或者bug，都是因为对技术的使用没有很好的匹配应用场景。

那么云原生技术具体到里面众多的技术点如何去组合应用，才能有效解决企业数字化系统构建中各种应用场景的问题？云原生应用到底怎么样设计是合理的？在企业的IT架构评审、问题排查等工作中，如何能够快速达成共识？

以往解决方式是依靠有经验的架构师根据过去踩坑的经历总结出来的东西进行设计，并且在工作中传递和说服同事、领导。这就要依赖架构师的个人水平和推动事情的能力，效率很低。

我把以往做过的几十个云原生项目，把一些针对企业里各个应用场景的技术和套路总结下来，并形成模式，把它称之为云原生应用的设计模式，供企业在解决这些问题时作为参考。

 

总结了十几种设计模式，一是基础模式，例如无状态服务模式、有状态服务模式、服务网关/API网关模式、Operator模式等；二是复杂模式，例如服务网格模式、云-边协同模式、Data Pipeline模式、Serverless模式等；三是子模式，子模式不能单独使用，而是在各种基础模式和复杂模式中被复用，例如Pod模式、服务注册/发现模式、配置中心模式、基础设置即代码模式......

说到“设计模式”，有一本书被广为流传，介绍了23种设计模式称为可复用面向对象软件的基础，是非常经典的著作。企业可以根据实际情况，参考这样的方式去工作，可能会有很好的效果。

最后给一些管理方面的建议，Amazon集团的CTO有一句话，我认为在云原生领域里，对于管理者很有启发。

就是“You build it，you run it”，直译过来是“你建造，你运行”，从汉语的IT语言体系翻译为“谁开发，谁运维”更加贴切一些。

从管理角度来看，如果真的要践行数字化转型，利用云原生技术把整个IT系统的敏捷性以及持续演进、可用性等一系列事情做好，可能应用开发和运维是不能够割裂的。