锲子
参与云原生转型项目调研也有近半年时间了，从年初听同事讲云原生的云里雾里，到开始百度云原生的概念，然后接触各大头部云厂商，全面铺开进行方案交流与选型调研，一路走来，确实收获颇多，进境用一日千里来形容也不为过。
一、云原生定义界定
关于云原生的定义有多次发展，从Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念，到2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时，将云原生架构又重新归纳为模块化、可观察、可部署、可测试、可替换、可处理等6大特质；而Pivotal官网对云原生的最新概括为4个要点：DevOps+持续交付+微服务+容器。
2015年云原生计算基金会（CNCF）成立，CNCF参与进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API加了进来。
从这些定义可以看到CNCF将云原生的定义更偏技术化，更偏向于界定云原生应用的技术能力特征，而Matt Stine的定义从最初的技术架构能力特征，逐步演化到研发管理。如果单从企业数字化转型的角度来看，会显得更加立体化又简明易记，也因此更容易做普适性推广，也更符合企业云原生转型的全面目标价值。其对云原生概括为4个要点——DevOps+持续交付+微服务+容器，其实笔者更倾向于将DevOps与持续交付合二为一，统称DevOps——毕竟DevOps敏捷交付体系建设就是为了持续交付、敏捷迭代业务——因此从云原生宣传推广的角度出发，笔者将云原生体系（而不只是云原生技术架构或者云原生应用特征）的定义，还是浓缩为传统三驾马车（DevOps+微服务+容器），这样既囊括技术解决方案，也能包含研发管理建设思路，能真正成为解锁企业数字化转型的“他山之石”。
二、云计算演进之路
这三驾马车中“容器”是承上启下的至关重要的一层，往下，容器技术代表着IT基础设施（计算、存储、网络等）在资源虚拟化技术成熟并商用（第二代云计算）之后，在资源标准化道路上的又一关键进步。
先回过头去看第一代云计算技术代表VMare的虚拟化之路，其最初是诞生于解决应用程序在不同操作系统与兼容型PC机上统一运行的痛点问题，具体实现目标是屏蔽WinTel时代大量兼容型台式机的硬件差异、OS差异（特别是Windows与Linux两大阵营），以期通过虚拟化构建一个“行之四海皆准”的标准化计算环境，供目标应用程序无差别运行。继而，在此基础上再拓展出资源动态扩缩容等企业级商用支撑能力，最终形成企业IT架构中Iaas层的商用解决方案，这便有了第一代的云计算技术。
在1999年当时的时代背景下，其在资源虚拟化方面的贡献是革命性的，但是VMare基于普适全市场PC机的宿主机型设计思路，必然需要花费了大量架构精力去做各类异构资源的兼容，因此其虚拟化技术从一开始就是“负重奔跑”的，其带来的巨大性能损耗也是可以预见的。
但是，不可否认，其代表的第一代云计算技术，为企业IT架构特别是运行架构的发展做出了非常卓越的贡献，其弹性扩容、资源超卖、故障迁移等云计算典型能力特征，在云计算技术演进到第三代的今天，依然是评估一朵云基础技术能力的关键性基础指标。
在VMware将计算资源虚拟化的基础上，云计算第二代技术集中体现在“软件可定义”这个关键词上，其中尤为值得大书特书的便是软件定义网络（简称SDN）。严格来说，在VMware将计算资源实现虚拟化之后，云平台已经具备一定的软件定义计算的能力了，而SDN的出现则大幅下推了软件可定义的IT体系架构下界——由计算层(主要是OS)下推到了网络层，而又大幅扩展了企业IT架构虚拟化的范围——从单机拓展到了大型数据中心级别。
这种演进带来的技术进化也不仅仅是将网络控制能力虚拟化、软件化，而是已经开始产生变革性的局部IT体系架构升华。例如，头部云厂商，在设计云内VPC之间互联互通方案时，不约而同地采用了隧道直通方案，从而省去了传统云上VPC互通时的网元中转环节，这一点与传统云厂商的设计思路形成鲜明的方案对比。传统云厂商依然是按照传统机房网络思维在设计云上网络方案，说直白一点，不过是把传统IDC网络联通方案Copy到了云上，而头部公有云厂商，因为有大流量、高并发等高性能互联网场景诉求，于是在云上网络方案的设计上做了更大胆的突破。其实，如果从这个角度再反过头来审视“网络的本质”，你会对网络有更高一层的认知（后续有机会我们再来深入探讨）。
第二代云计算技术伴随着AWS、Azure、阿里云、腾讯云、华为云等公有云厂商的崛起而发扬光大，直至今日依然时刻影响着各类大中小型企业的IT架构演进，“上云”已然成为企业IT架构升级的必由之路。
然而，IT上云的“前浪”还未上岸，云原生转型的“后浪”又已经轰然而至。随着容器技术大规模应用于云上，基本可以判断，云计算技术演进到第三代了，即云原生时代。而且云原生时代，对于云的运用已经提升到了全新的层次。以往云计算对企业IT架构的支撑仅仅是停留在IT资源层面，即其只是作为一项IaaS层的资源管理落地方案来实现其价值的，贡献巨大但依然不够全面彻底。而云原生在基于云计算技术的基础上，演进成了一整套体系解决方案——容器、微服务、DevOps。当然，这三架马车是需要长于云上的（现阶段也有大量专家脱离云，基于其商业目的或自身技术认知局限，独独侧重容器来谈云原生，这是非常片面因而值得商榷的），笔者的观点也非常直接鲜明——只有充分结合云的能力形成的云原生解决方案，才是真正能有质变性提升、可落地的解决方案，才能真正发挥云原生1+1+1>3的效果。
三、基于云计算再来看云原生三驾马车——老树发新芽
如果单论三驾马车的单项解决方案，其实都不是新玩意。这三者，也就容器技术看似相对新潮一点，但其实早在2001年，通过 Jacques Gélinas 的 VServer 项目，隔离环境的实施就进入了 Linux 领域，这便是容器技术的雏形。只不过直到2008年，Docker的崛起才让容器技术发扬光大、广为人知(引自RedHat官网《容器简史》)。因当前Docker+Kubernetes已成容器技术领域事实上的产业标准，因此本文所讨论容器相关技术均以此两类技术为默认基准。
微服务技术，就更不新鲜了，借助下图，软件应用架构从最初的单体式架构，到上个世纪80年度的MVC架构(1979年，Trygve Reenskaug在一篇论文中首次提出MVC模型)，再到前后端分离后的跨进程互访的RPC架构(Birrell和Nelson在1984 发表于ACM Transactions on Computer Systems 的论文《Implementing remote procedure calls》对 RPC 做了经典的诠释)，再到上个世纪90年代中期提出、2002年Gartner提携的SOA，再到2014年Martin Fowler 与 Jam es Lewis共同提出的微服务，其一路就是IT软件开发技术的演进发展历程。就技术本质而言，从RPC架构其实就已经与现在的微服务技术同宗同源了。
而DevOps，最早于2009 年6月，在美国圣荷西举办的第二届Velocity大会上，一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，便成为了DevOps 萌发的标志。
所以若单论各单项技术（这里的“技术”不单指开发技术，而是涵盖整个信息技术知识体系的各项专业技术，有此基础认知共识，才比较适合阅读本文），都是10年前的“老”技术了，但是在云上进行组合后，所产生的“化学反应”才真正标志着云原生时代的到来！
1、云+容器质变性推进计算环境的运行标准化进程
当前第三代云计算技术，首先是基于第二代云计算厂商的公有云大规模实践发展而来，即便沉淀到私有云领域，基本都是沿用公有云架构，再做的企业级能力下沉，其在基础资源管理方面，也充分体现了公有云的特点。
首先便是基础硬件的标准化思路的变革——第二代云对于基础硬件的标准化思路与第一代云截然相反，第一代云计算技术企图以软件虚拟化技术去全面兼容市面参差不齐的异构PC机，也正由于在普适兼容方面投入过多，从而导致性能损耗过大，而第二代云在此方面做了减法，基于大规模公有云实践经验，其反向要求入云纳管的硬件设备，特别是计算服务器首先必须是标准化的（甚至根据云厂商要求进行定制），要求满足云厂商的硬件兼容标准，由此来大幅降低硬件兼容范围，基于此再来进行针对性调优、推动虚拟化核心技术沉入OS内核、推动硬件虚拟化技术支持，以此来大幅降低虚拟化性能损耗。目前头部厂商均宣称其基于KVM的虚拟机技术，性能损耗均已能降低到5%以内（优秀者可以到3%以内）。
由此可以预见，全行业级别的云基础硬件规格标准必然在不远的将来出台，并由此倒推整机硬件厂商进行标准化生产，再上溯倒逼上游零部件厂商标准化生产，最终实现全行业全产业链路的标准化。
第二点，随着AWS的Nitro硬件卡、阿里神龙卡的出现，结合英特尔的DPDK技术，出现了服务器上网络处理指令“绕过”CPU、将流量卸载到PCI扩展卡处理的性能优化方案，此方案能大幅提升云上网络性能、全云存储性能（追赶者还有腾讯云的黑石、华为云的擎天等），应用此类智能网卡的服务器在特定领域（例如高性能计算、云存储、裸机容器）将拥有无可比拟的性能优势。
基于此类应用的前景，随着头部云厂商的市场占比不断攀升，定制版智能网卡、定制版服务器的市场占比也将不断提升，继而可以进一步展望一下，智能网卡能否分担更多特定CPU/GPU的任务指令（全局内存、CPU资源调度等，神龙卡能力已经涵盖CPU、内存、存储、GPU等关键计算能力，基本等同于一台低配服务器）？而回到本节中心观点，在通过增加PCI扩展卡方式提升通用云服务器特定领域性能的同时（目前已实现的是网络、存储，GPU应该是可以预见的），进一步增加了云厂商在服务器领域的标准制定话语权，也更能反向推动传统服务器厂商的标准化生产程度。
第三点，过往云端计算资源的全局调度、弹性伸缩能力，均是依托虚拟化技术（不论是VMware的软件虚拟化，亦或VT-x/VT-d的通用硬件虚拟化技术）来实现，本质上依然是借力云服务器的宿主机操作系统的资源调度能力来实现，而在“云服务器定制化、SDN技术的出现使得云上网络也可软件定义、智能网卡能力不断强化”这三方面因素驱动下，操作系统级控制能力下沉、软硬协同一体化的硬件级全云资源调度管理成为了可能，这一点对于传统虚机类应用或许收益不那么明显，但是在容器领域，将是革命性的。
容器技术如果要达到真正生产级可用，说到底，依然需要云服务器上宿主OS环境的全局统一调度可控，故若不能做到OS控制能力下沉到硬件，还是基于“宿主机+VM“模式（全局资源调度依然只能依靠虚拟化技术，也即是常见的宿主OS+虚拟OS+Docker容器的三级运行模式），始终是无法实现物理机部署模式的性能替代的。只有真正实现裸金属容器方案落地（即宿主OS上直接运行容器，并实现资源自动弹性扩展），才能彻底替代物理机部署模式，来满足企业日益高涨的高性能、大并发、高算力、高容错的互联网场景需求。只有有了OS控制能力下沉到硬件，容器便能真正运行在硬件服务器环境（即裸金属），实现硬件级的弹性扩缩容，上述互联网场景类应用的容器化改造才有达到性能基线要求的可能性，系统云原生改造的第一步”迁移上云“才能真正全面实现。
第四点，容器服务长在云上，相比物理机环境或者VMare虚机环境，容器网络性能可借力SDN得到大幅提升，同时可将容器网络平面与云上网络平面拉平，做统一规划设计，也便于容器化应用与传统应用的统一网络管理与安全策略控制。当前开源容器网络解决方案如flannel、calico、weave、Canal等，均是基于过往Internet模式下海量分散单机寻址路由的背景进行设计，方案着力点都在容器或宿主机。而云上容器服务的网络解决方案，从调研来看，均是直接借力SDN能力，将容器网络与Overlay网络拉平，依托VPC、智能网卡等先进云平台技术统一提升容器网络性能，方案设计出发点便是以全数据中心容器网络传输整体性能提升为目标，不论方案高度还是深度均非开源纯容器网络方案可望其项背。这也是笔者坚持”不能脱离云单以容器来论云原生“的另一核心原因！
2、云+容器+微服务，拔高基础设施上限至PaaS层
依托云平台的资源软件可定义能力，搭建统一大集群规格的PaaS服务，为传统企业瞬时提供能比肩一线互联网企业高性能、高可靠性的中间件服务与应用开发框架能力，并进一步推动企业内开发框架标准化进程。
微服务的核心思想便是能力拆分、功能解耦，其与容器是天然一对——服务的并发弹性支撑可通过容器的水平伸缩能力来匹配实现、服务的高可靠可通过容器的自动恢复特性来满足。同时，基于应用服务的全面容器化之后，应用开发框架中的大部分非业务相关的框架性能力便能与业务应用解耦，以SideCar方式独立运行，既能实现应用框架独立于业务应用的自主升级，也能使业务开发团队更加聚焦于业务功能开发。同时，为跨系统、跨技术栈的全链路服务追踪、全局服务治理提供了技术落地可能性，这便是ServiceMesh。
而即便不用容器技术，仅基于云+微服务使用场景，应用开发相关的中间件服务（例如常见的Redis、MQ等）也能通过云端标准PaaS服务提供，并支持分租户、实例级隔离使用。此类公共组件，依托云端的大规模集群部署能力，可轻松提供比肩一线互联厂商的大并发、高性能、自动弹性扩缩容的高性能中间件服务，为业务应用的性能提升、稳定性提升提供统一化、规模化、专业化技术服务保障。
在第三代云计算技术，PaaS服务也成为了云端基础设施，在短时间内大幅提升传统企业系统的运行性能、稳定性的同时，也能大幅降低企业应用的中间件建设成本、开发框架的维护成本、架构人员能力要求与投入，同时，借助业务上云，也能轻松实现应用开发框架收敛、中间件服务标准化，将其版本迭代管理、能力演进节奏都依托云端实现，其企业架构治理前景也是非常可观的。
3、云+容器+DevOps，依托运行标准化，降低DevOps对接成本，真正使研发全流程自动化成为可能。
基于云+容器来进行DevOps敏捷化运作，其核心收益点在于——容器依赖自包含特性带来的CD环节（持续发布）的对接改造成本的大幅降低、基础运行环境大幅软件可定义之后系统资源的自动化申请与创建使得研发全流程自动化有了真正落地可能。
DevOps这个概念并不新鲜，但是在云原生时代以前，除了一线互联网企业，鲜有成功案例，其一大原因在于应用依赖环境的繁杂，特别传统企业，历史遗留系统多、技术栈庞杂、框架版本碎片化严重，若要在CD环境对接改造所有系统的各类运行环境，对接成本高、技术复杂度高、发布后监控反馈环节对接难度大，最终导致改造后系统运行风险反而不可控。故而只能在Java等少数“先进且标准”、对接成本更低的领域试点，全面推广几无可能。
而容器技术出现后，业务应用统一打包成依赖自包含的容器镜像，对运行环境的依赖程度大幅降低，DevOps的流水线系统只需要对接云上统一的容器发布系统，即可轻松实现各类技术栈应用的自动化发布，再依托云平台全栈的容器运行状态监控机制、ServiceMesh流量劫持等能力，在应用发布后状态监控环节，也有了可低成本实现的标准化解决方案。整体自动化发布方案也更加立体，更具备生产落地可行性。
第二个原因在于，在传统机房的基础设施运行环境，系统运行资源、网络、安全策略等程序运行相关的配置类资源的下发多为手工操作、流程断节，即便在编码研发环节能做到持续集成、自动化构建，应用包自动化推送与部署，中间环节的应用配置下发或变更依然是手工操作，并不能真正实现全流程自动化，也就依然无法实现快速迭代发布。而在第二代云计算技术之后，有赖云上技术、存储、网络、安全等资源的软件可定义，程序运行所需配置类资源通过调用云端标准接口即可开通或下发，使全流程自动化发布真正成为可能。
第三点在于，在ServiceMesh出现以前，大部分应用运行保障相关的框架级非功能特性（如弹性、韧性、安全、可观测性、灰度等）均依赖不同技术栈的应用开发框架能力来保证，甚至如在开发框架上述能力缺失的情况下，还需要业务开发团队自建，这就导致了此类特性涉及的运维自动化、运行监控等工具能力也需要重复建设多套，很难做标准统一的同规格高质量建设，因此即便前面CI/CD做到了全流程自动化，自动化发布后也不敢在生产无值守运行。这一点在容器环境，伴随着ServiceMesh技术的出现，才真正有了标准化解法。
综上所述，在云原生时代，通过云上环境的软件可定义能力、标准化能力，已经可以使大量研发管理操作、运维监控操作由过去的手工处理变为自动化、标准化的系统动作，从而整体性提升企业IT运维自动化水平、质变性跃升软件系统基础架构能力与服务稳定性，最终加快业务研发敏捷迭代速度。
也因此，我们可以看到，云原生时代的三驾马车，已经不仅仅是针对云原生应用的技术面的能力表述，还蕴含了依托云的IT研发全生命周期管理含义与研发团队组织思想，因为更立体。在此，我们可以大胆定义——云原生体系是企业管理模式向互联网模式进化的核心关键技术与管理思想、组织流程的深度融合，应该也能成为实现国家的互联网+战略的一条重要路径，也必将大幅推动中国乃至世界企业的互联网化进程！
