【重识云原生】第一章——不谋全局不足以谋一域-刊发版

前言：第一篇有幸受创原会邀稿，发布在第三期，因为重新整理梳理了一遍，也发一下。

作者介绍：云原生转型项目调研负责人。

一、 “三驾马车”奠定云原生体系核心

        云原生（Cloud Native）的概念最早是由Pivotal公司的Matt Stine于2013年提出，并在《迁移到云原生架构》一书中总结为——12因素、微服务、自敏捷架构、基于API协作、扛脆弱性等。而云原生计算基金会（CNCF）成立后，将云原生代表技术定义为容器、服务网格、微服务、不可变基础设施和声明式API。笔者从企业数字化转型实践角度出发，依然将云原生体系（而不只是云原生技术架构）的定义浓缩为传统三驾马车——DevOps+微服务+容器，这样既能囊括技术解决方案，也能包含企业研发管理建设思路，使其能真正成为解锁企业数字化的“他山之石”。

云原生三驾马车

二、从云计算发展再来重新认识云原生

        云计算技术从1999年VMware公司推出商业虚拟化软件VMaware Workstation起，到现在，仅仅二十多年时间，便已历经虚拟化、公有云、云原生三代。以往云计算对企业IT的支撑仅仅停留在IT资源的运维管理层面，对企业研发管理变革的影响力有限。而云原生体系，基于资源全面虚拟化、应用运行高度标准化、业务研发全线拉通，可以IaaS、PaaS、SaaS的高要求高收益反向推动企业研发管理变革，从而全面驱动数字化转型车轮快速向前运转。

1.1 云+容器质变性推进软硬运行环境的标准化

        当前第三代的云计算技术，首先是基于第二代公有云的大规模实践发展而来，即便沉淀到私有云领域，基本都是沿用公有云架构再做的ToB能力下沉，其在IaaS层基础资源管理方面也充分体现了公有云的特点。

        首先便是基础硬件标准化思路的变革——第二代云对于基础硬件的标准化思路与第一代云截然相反。第一代云计算技术企图以软件虚拟化技术去全面兼容市面参差不齐的异构PC机，也正由于在普适兼容方面投入过多，导致性能损耗过大，而第二代云则在此方面做了减法，其基于大规模公有云实施经验，反向要求入云纳管的硬件设备，特别是计算服务器首先必须是标准化的（甚至需根据云厂商要求进行定制），要求满足云厂商的硬件兼容标准，由此来大幅降低硬件兼容适配范围，再进行针对性调优、推动虚拟化核心技术沉入OS内核、推动硬件辅助虚拟化技术发展，以此来大幅降低虚拟化性能损耗。目前头部厂商均宣称其基于KVM的虚拟机技术，性能损耗均已能降低到5%以内（优秀者可以到3%以内）。

        由此可以预见，全行业级别的云基础硬件生产标准必然在不远的将来出台（当然这也有赖国家主导成立的相关云计算产业协会来牵头），以此逐级实现上游全产业链的深度协同标准化生产。

        第二点，随着AWS的Nitro硬件卡、阿里神龙Moc卡等智能网卡技术的出现，结合英特尔的DPDK/SPDK技术，服务器上部分网络或存储处理指令可以移到用户态处理、且将流量直接卸载到智能网卡中，此方案能大幅提升云上网络传输性能、全云存储性能（陆续出来的还有腾讯云的黑石、华为云的擎天卡等），应用此类智能卸载技术在特定云上领域（例如高性能计算、云存储、裸机容器、零信任安全保护等）将拥有无可比拟的性能优势与更体系化的软件定义能力。凭借此类革命性技术优势，定制版智能网卡、定制版服务器的市场占比必将不断提升，从而进一步提升云厂商在云服务器领域的标准话语权。

        第三点，第一代云计算技术的资源全局调度能力、弹性伸缩能力，均是依托单机虚拟化技术（不论是VMware的软件虚拟化，亦或基于Intel VT-x/AMD-v的硬件辅助虚拟化技术）来实现，缺乏数据中心级的大规模自动化调度能力。而从第二代云计算技术开始，特别是SDN技术的出现使得软硬协同一体化的数据中心级(甚至跨地域级)全云资源调度管理成为常态，此举必然大举推动企业网络环境的标准化进程。

        第四点，传统云下容器运行模式是宿主机+虚拟机+容器的三级运行模式，一般就意味着容器网络传输需经过三级转换，故传输性能不如人意，难以大规模商用。而容器运行在云上，通过云网络技术（例如VxLan、SDN）可将容器网络平面与云上(Overlay)网络平面拉平，再将流量卸载到智能网卡上加速，既方便做灵活的统一网络规划与安全策略控制,也能减少一次网络转换、加速容器网络性能。

        当前开源容器网络解决方案如flannel、calico等，均是基于过往Internet模式下海量分散单机寻址路由的思路进行设计，且仅仅站在容器层来设计网络方案，故而不论性能还是实际落地代价均不理想。而云上容器的网络解决方案，从调研来看，均是直接融合了云端网络虚拟化能力，将容器网络与Overlay网络拉平，依托VPC、智能网卡等先进技术来简化传输链路、提升性能，且方案出发点便是以全数据中心云上云下网络一体化拉通为落地目标，故不论方案深度还是可落地性均非开源纯容器网络方案可望其项背。这也是笔者坚持“不能脱离云单以容器来论云原生”的另一关键原因！

1.2 云+容器+微服务，拔高基础设施上限至PaaS层

        依托云平台的资源软件可定义能力，搭建统一大集群规格、可弹性伸缩的PaaS服务，可为传统企业瞬时提供能比肩一线互联网企业的高性能、高可靠性的中间件服务与应用开发框架能力，并大力推动企业内开发框架标准化进程。

        微服务的核心思想便是能力拆分复用、功能解耦，其与容器是天然一对——服务的并发弹性支撑可通过容器的水平伸缩能力来匹配实现、服务的高可靠可通过容器的自动恢复特性来自动化满足。同时，基于应用服务的全面容器化之后，应用开发框架中的大部分非业务相关的框架性能力便能与业务应用逐步解耦，以SideCar方式伴生运行——此举既能实现应用框架独立于业务应用的自主升级，也能使业务开发团队更加聚焦于业务功能开发，同时为跨系统、跨技术栈的真正全链路服务追踪、全局服务治理提供技术落地可能性，这便是ServiceMesh。

        而即便不用容器技术，仅基于云+微服务使用场景，应用依赖的中间件服务（例如常见的Redis、MQ等）也能以云端标准PaaS服务的方式提供，并支持大规模弹性、分租户申请、实例级隔离使用，为业务应用的性能提升、稳定性提升提供统一、规模化、专业化技术服务保障。故而，在云原生时代，PaaS服务也已成为云端基础设施的一部分。

        在云原生时代，PaaS服务也成为了云端基础设施，在短时间内大幅提升传统企业系统的运行性能、稳定性的同时，也能大幅降低企业应用的中间件建设成本、开发框架的维护成本、架构人员能力要求与精力投入。同时，借助业务上云，也能轻松实现应用开发框架收敛、中间件服务标准化，将其版本迭代管理、能力演进节奏都依托云端实现，其企业架构治理前景也是非常可观的。

1.3 云+容器+DevOps，依托运行标准化，降低流水线对接成本，真正实现产研运全流程自动化

云原生产品生命周期研发体系

        基于云+容器来进行DevOps敏捷化运作，其核心收益点在于——容器依赖自包含特性带来的CD环节（持续发布）的对接改造成本的大幅降低、基础运行环境大幅软件可定义之后系统资源的自动化申请与创建使得研发全流程自动化有了真正落地可能。

        DevOps这个概念并不新鲜，但是在云原生时代以前，除了一线互联网企业，鲜有成功案例，其一大原因在于应用依赖环境的繁杂，特别传统企业，历史遗留系统多、技术栈庞杂、框架版本碎片化严重，若要在CD环境对接改造所有系统的各类运行环境，对接成本高、技术复杂度高、发布后监控反馈环节对接难度大，最终导致改造后系统运行风险反而不可控。故而只能在Java等少数“先进且标准”、对接成本更低的领域试点，全面推广几无可能。而互联网企业恰恰因为历史包袱少、技术栈相对单一，便有了成功运作的相对标准化技术环境基础。

        而容器技术出现后，业务应用统一打包成依赖自包含的容器镜像，对运行环境的依赖程度进一步降低，DevOps的流水线系统只需要对接云上统一的容器发布系统，即可轻松实现各类技术栈应用的自动化发布，再依托云平台全栈的容器运行状态监控机制、ServiceMesh流量劫持等能力，在应用发布后状态监控环节，也有了可低成本实现的标准化解决方案。整体自动化发布方案也更加立体，更具备生产落地可行性。

        第二，在传统云下环境，运行资源调度、网络策略下发、安全策略配置等均是相互割裂，相关配置工作多为手工操作，故即便在编码环节能做到持续集成、自动化构建，应用包也能自动化推送与部署，但中间的应用配置变更依然是手工操作，终究不能真正实现全流程线上化、自动化，也就依然无法实现快速迭代发布。而在第二代云计算技术之后，有赖云上计算、存储、网络、安全等资源的软件可定义，程序运行所需配置信息通过调用云端标准接口即可开通或下发，使CI/CD各节点均可线上化打通实现，全流程自动化发布才真正成为可能。

        第三点，在ServiceMesh出现以前，大部分应用运行保障相关的框架级非功能特性（如弹性、韧性、安全、可观测性、灰度等）均依赖不同技术栈的应用开发框架能力来保证，甚至如在开发框架上述能力缺失的情况下，还需要业务开发团队自建，这就导致了此类特性涉及的运维自动化、运行监控等工具能力也需要重复建设多套，很难做标准统一的同规格高质量建设，因此即便前面CI/CD做到了全流程自动化，自动化发布后也不敢在生产无值守运行。这一点在容器环境，伴随着ServiceMesh技术的出现，才真正有了标准化解法。

三、云原生体系加速业务敏捷迭代

        在云原生时代，通过云上环境的软件可定义能力、标准化能力，已经可以使大量研发管理操作、运维监控操作由过去的手工处理变为自动化、标准化的系统动作，从而整体性提升企业IT研发运维自动化水平、质变性跃升软件开发架构能力与PaaS服务稳定性，最终加快业务研发敏捷迭代速度，是一场彻底的科技引领业务的转型变革。

        一方面云上应用开发框架、PaaS服务充分结合了云的特性，其持续迭代、运营运维的能力要求，对平台框架开发人员、业务团队架构师的能力要求变得更高了，以往上述人员只需要精于软件开发框架，而云原生体系下，还需要懂云、懂容器，技术能力需要往全栈方向延展；另一方面，传统IT部门中研发与运维是分离的，部门并行设立、工作独立开展，而上云之后，因敏捷迭代要求，开发与运维的协作需要更加紧密，不论是平台开发框架、PaaS服务、业务系统，均需要以产品化思路来运作，这就要求管理者、架构师、业务人员、开发人员、运维人员、运营人员均需要从过往工具化软件开发思维提升到产品化研发思维中来，并形成配套的产品型研发团队，即便业务部门、研发部门与运维部门依然并行设立，但“人”与“事”也要开始做分离，以“事”聚“人”，如此才能适应云上快速迭代要求，业务也才能真正“敏”起来。

云技术变革逐层驱动企业研发与管理模式的变革

四、小结

         因此，云原生时代的三驾马车，已经不仅仅是针对IT的技术侧能力表述，还蕴含了业务上云后的研发全生命周期管理含义与研发团队组织思想变革。云原生体系是企业管理模式向互联网模式进化的核心关键技术与管理思想、组织流程的深度融合，应该也能成为实现国家“互联网+“战略的一条重要路径，也必将大幅推动中国乃至世界企业的互联网化进程！

云原生体系知识地图大纲：

参考链接

什么是Linux容器？

微服务浅述---架构演进

RPC发展史

微服务架构诞生的今世前生大揭秘

DevOps的那些事儿——DevOps的前世今生

虚拟机的实现原理

智能网卡（SmartNIC）行业概览（2021）

 《重识云原生系列》专题索引：

1. 第一章——不谋全局不足以谋一域
2. 第二章计算第1节——计算虚拟化技术总述
3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
4. 第二章计算第3节——主流虚拟化技术之Xen
5. 第二章计算第4节——主流虚拟化技术之KVM
6. 第二章计算第5节——商用云主机方案
7. 第二章计算第6节——裸金属方案
8. 第三章云存储第1节——分布式云存储总述
9. 第三章云存储第2节——SPDK方案综述
10. 第三章云存储第3节——Ceph统一存储方案
11. 第三章云存储第4节——OpenStack Swift 对象存储方案
12. 第三章云存储第5节——商用分布式云存储方案
13. 第四章云网络第一节——云网络技术发展简述
14. 第四章云网络4.2节——相关基础知识准备
15. 第四章云网络4.3节——重要网络协议
16. 第四章云网络4.3.1节——路由技术简述
17. 第四章云网络4.3.2节——VLAN技术
18. 第四章云网络4.3.3节——RIP协议
19. 第四章云网络4.3.4节——OSPF协议
20. 第四章云网络4.3.5节——EIGRP协议
21. 第四章云网络4.3.6节——IS-IS协议
22. 第四章云网络4.3.7节——BGP协议
23. 第四章云网络4.3.7.2节——BGP协议概述
24. 第四章云网络4.3.7.3节——BGP协议实现原理
25. 第四章云网络4.3.7.4节——高级特性
26. 第四章云网络4.3.7.5节——实操
27. 第四章云网络4.3.7.6节——MP-BGP协议
28. 第四章云网络4.3.8节——策略路由
29. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
30. 第四章云网络4.3.10节——VXLAN技术
31. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
32. 第四章云网络4.3.10.3节——VXLAN隧道机制
33. 第四章云网络4.3.10.4节——VXLAN报文转发过程
34. 第四章云网络4.3.10.5节——VXlan组网架构
35. 第四章云网络4.3.10.6节——VXLAN应用部署方案
36. 第四章云网络4.4节——Spine-Leaf网络架构
37. 第四章云网络4.5节——大二层网络
38. 第四章云网络4.6节——Underlay 和 Overlay概念
39. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
40. 第四章云网络4.7.2节——virtio网络半虚拟化简介
41. 第四章云网络4.7.3节——Vhost-net方案
42. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
43. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
44. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
45. 第四章云网络4.7.8节——SR-IOV方案
46. 第四章云网络4.7.9节——NFV
47. 第四章云网络4.8.1节——SDN总述
48. 第四章云网络4.8.2.1节——OpenFlow概述
49. 第四章云网络4.8.2.2节——OpenFlow协议详解
50. 第四章云网络4.8.2.3节——OpenFlow运行机制
51. 第四章云网络4.8.3.1节——Open vSwitch简介
52. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
53. 第四章云网络4.8.4节——OpenStack与SDN的集成
54. 第四章云网络4.8.5节——OpenDayLight
55. 第四章云网络4.8.6节——Dragonflow

56.  第四章云网络4.9.1节——网络卸载加速技术综述

57. 第四章云网络4.9.2节——传统网络卸载技术

58. 第四章云网络4.9.3.1节——DPDK技术综述

59. 第四章云网络4.9.3.2节——DPDK原理详解

60. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

61. 第四章云网络4.9.4.2节——智能网卡实现