今年受邀参加华南CIO大会，由于疫情延期到本周末在广州进行。在10月23日我写过一篇整理了数字化转型和架构规划方法论的内容。可以先参考。
今天继续把后续云原生架构设计的一些关键点做下整理。
云原生基本概念-从长到云上到生在云上
云原生是云计算不断发展演进下一系列技术实践和管理实践的融合。技术实践包括了微服务，ServiceMesh服务网格，ServerLess无服务器化，声明式API，不可变基础设施等；管理实践包括了持续交付，DevOps，康威定律，敏捷方法论。
简单总结云原生四要素就是微服务，容器云，DevOps和持续交付。
但是要理解云原生还得从原生两个词理解。
原生两个词在原生家庭里面用得比较多，什么意思呢？
就是你不是长大了再保养过来的，而是从一出生就在这个家庭里面长大。对应到云计算也是同样的道理。不是一个业务系统都开发好了再申请资源部署到云平台上，而是一开始就采用云服务提供的环境框架进行设计，进行软件过程管理，最终交付到云上去。
这也是华为云大会上提出的从长在云上到生在云上。
云原生本质-抽象和标准化
第二点，云原生的本质是抽象和标准化。
即是整个关注重心从资源到服务不断上移的一个过程。早期的云服务更多都是谈IaaS层，但是云原生时代重心在PaaS层。IaaS层你关注的是资源，但是PaaS层你关注的是服务。
云基础设施的资源层，不论是物理资源还是虚拟化后的逻辑资源都你都不可见，你更多关注的是服务能力的使用。类似数据库服务，消息服务，缓存服务等。
当真正迁移到服务层后，所有的底层技术细节，高可用和扩展性等你都不再需要关注，都应该是云平台提供的服务能力帮助你解决。
云原生时代-开源和开放是大趋势
可以看到，云原生时代，开源和开放是一个大的趋势。
典型的就是CNCF云原生基金会，该基金会是Linux下的一个基金会于2015年成立的，当前已经有200多个开源项目，覆盖了云原生技术各个方面。国内的华为，阿里，腾讯，京东，青云等都为基金会贡献了大量的项目。
所以你可以看到，一个企业要构建一个云原生的技术平台，从微服务开发框架到API网关，从运维监控到微服务治理，基本都能够找到对应的开源项目协作你完成整个架构解决方案。也正是开源社区和开源软件，进一步推动了云原生的发展。
模仿和创新，开创性的工作不需要都去做，更多的还是站在巨人的肩膀上。
云原生整体知识框架和成熟度
上图是一个初步的云原生知识体系，不完善。
当时构建这个框图的时候注意基于两个维度进行。其一是横向的从支撑过程到资源层，服务层，组织管控的横向分层；其二是覆盖整个云原生时代从规划设计，到开发交付，到治理运维的软件全生命周期过程管理。
比如对于DevOps实际是属于关键的过程支撑能力。而对于API网关则是云原生服务层设计开发的一个关键组件。对于微服务划分或领域建模等则可以纳入到规划设计阶段的关键能力。
传统传统IT架构的演进过程
企业传统IT架构的演进大致可以分为三个阶段。
第一个阶段即传统的单体应用，烟囱式的系统建设，然后再通过类似SOA集成平台进行集成。在这个过程中即使使用了云服务，一般也仅仅是做了IaaS虚拟化资源层，而没有太多的的平台层能力。平台层能力在各个系统内部，而是系统内各个模块也紧耦合。
第二个阶段是逐步构建自己的PaaS平台，但是一般还是做虚拟机的资源调度和应用托管。同时上层应用逐步开始拆分和解耦。
第三阶段则PaaS平台发展到当前主流的容器云PaaS平台，虚拟机变成了轻量的容器。同时对于数据库，消息，缓存等各种技术服务能力全部也由PaaS平台提供。在共性技术平台下沉后上层应用全部微服务化，彻底解耦。但是微服务应用开发和底层的容器云平台之间需要有一个集成和协同的桥梁，方便微服务应用快速交付到云平台上，因此这个时候需要通过DevOps来实现上下衔接和集成。
上层是微服务应用，中间是DevOps过程支撑，底层是容器云平台。而这三者恰好就是当前云原生平台的核心架构要素。
电信运营商云原生架构对比
由于我们本是做电信运营商的项目比较多。当前电信云原生架构中的DevOps过程支撑平台云道也是我们在做技术支撑。包括我们做移动集团的SOA项目，近期也开始做想移动集团的磐基云迁移的实施计划。
从电信和联通的云原生架构对比来看。
都包括了四个关键部分的内容。其中两个子系统我在前面也谈到了，第一个就是底层的容器云平台和技术服务能力提供；第二个是DevOps过程支撑平台。
除了这两个外要构建一个完整的云原生平台，还需要考虑对外能力的开放，因此都存在一个对外的API能力开放平台或聚合平台，而应用上线后本身也涉及到后续的监控运维和可观测性，因此两边的平台架构都会涉及到监控运维平台。
从上图也可以看到两个集团的云原生基础架构和关键组件基本是一一对应的关系。
云原生总体架构参考
基于前面的分析可以看到。
云原生整体架构应围绕微服务，DevOps和容器云三者的基础上。基于云计算标准的资源-服务-应用分层架构模型，和平台+应用构建思想，体现出整个IT应用从开发到执行到运维监控的软件全生命周期管理和全生命周期的治理能力。
在底层是重要的容器云PaaS平台并需要具备技术服务能力提供，在上层则是围绕微服务设计开发全面生命周期管理能力，覆盖开发态，运行态和运维监控态。而中间则是重要的DevOps过程能力支撑平台。
为了进一步体现平台+应用构建思想，下沉到平台层的能力最终又可以通过能力开放平台通过API接口的方式对外进行能力开放，实现和外部的连接能力。
低代码开发平台-核心对象驱动
在云原生时代的低代码开发平台需要具备如下几个关键特征。
其一是我经常谈到的对象驱动，即对象驱动建模，向上是界面层，向下是数据库对象。对象模型起到很好地承上启下的作用。
其二是低代码平台本身应该和云原生架构很好地融合，即低代码平台开发的应用本身就应该符合微服务架构标准，各个应用能够使用云原生平台提供的资源服务和消息缓存各种技术服务能力，其次低代码开发平台开发完成的应用能够结合DevOps持续交付到云平台上。最终达在运行态能够完全脱离低代码开发平台的目标。只有这样低代码开发平台开发完成的应用才具备足够的高可用和可扩展性。
其三是要低代码而非零代码，特别是对于企业级复杂业务系统的开发，要相信没有银弹的道理。即使规则引擎出来这么多年仍然没有很好解决这个问题。因此对于低代码开发平台，对于复杂规则建议仍然是自己写代码完成，并将实现好的规则开放为API接口服务，供前端在界面建模的时候调用。
云原生下的传统企业IT架构全面上云
注意如果仍然是购买点公有云服务商的虚拟机服务，将开发好的应用部署到云平台上，这个不叫云原生，还是传统的IaaS层云服务模式。
而云原生时代的全面上云，一个核心还是从资源层到服务层的转变。举个简单例子，你原来是自己购买虚拟机，然后安装数据库，但是云原生建议你直接购买数据库服务器。
同时企业全面上云是一个系统工程，设计到开发框架环境，微服务，开发过程管理，IT治理，运维监控等一系列的过程改进和实践。这个本身对企业本身已有的IT能力是有要求的，没有具备一定的信息化基础很难全面迁移云原生。
当然全面上云本身也是一个逐步迁移和逐步实施的过程。
在很长的一个阶段，你会发现是企业内部私有云平台和外部的公有云平台共同存在的状态，同时又借助前面谈到的DevOps来实现私有云向公有云的持续交付能力。
阿里云最近推出的CNStack云原生技术中台，实际就是将公有云的云原生技术服务能力下沉到企业内部的IT应用构建上，同时又搭建一个具备混合云管理能力的管理平台，起到有效衔接企业内部私有云和外部公有云之间的一个桥梁作用。