谈谈云原生

     之前关于云计算技术底座的部门会谈，我本着程序员实事求是的态度，表示自己其实并不懂云原生。前段时间云技术底座的模型验证，遇到一个测试案例叫做“白屏纳管”，意思是指 CAAS 平台能够对包括云下硬件负载 F5、A10，云上 SLB 等设备进行管理。云原生技术有着太多的这种花里胡哨的名词，将本来很简单的一件事情包装出个能吓住人的词，来提高理解的门槛。作为一个一线开发，我有一种很深切的感受：很多优秀的设计，都是有着简洁优雅的设计原理或者说思想蕴含其中。这种没什么太多内涵的毫无意义的造词运动，对于工程实践，没有任何好处。我们不应该人云亦云盲目从众，也不应该以偏概全一叶障目。

     以下是阿里云公众号某产品经理关于云原生的解释，我截了图如下：

     这段话讲得没有问题，但是似乎又什么都没讲，对于云原生的定义，这种似是而非的说法显然不是一线开发人员想要的答案。

     我们在说云原生的时候，其实是在说“云原生计算”，云原生这个词其实可以拆为“云”和”原生“两个词，这其中其实隐藏了一个词——“云计算”。云原生一定是云计算， 这就要求我们事先已经对云计算的发展历史有所了解。云原生与云计算的区别便在“原生”二字上，那么理解云原生，重点就在理解其为何为“原生”。我这里用一句话来总结云原生：云原生是为了发挥出云计算所有优势的最短路径（这句精辟的提炼摘自《阿里云云原生架构实践》一书）。

     这些想法和做法归纳为三个方面：应用架构、计算模型、代表技术。

• 代表技术 是最容易理解的。代表技术可以是一些狭义上的云原生基础设施，包含了相关的软件或硬件技术，例如裸金属、docker、K8S；也可以是泛化的一些工程技术体系，比如 Spring Cloud，DevOps，DDD ——它们与云基础设施不一样，很多并非为了云原生而生的，但是在云上环境表现活跃，也可以归纳到云原生代表技术中来。有些人说，使用了容器技术，就是云原生，这肯定是不准确的。容器其实只是改变了我们应用的部署方式，应用运行时的形态，以此来定义云原生是非常片面的。

• 计算模型， 既然这个行业这么喜欢遣词造句，那我也造几个词（切，谁还不会啊！！！）。计算模型可以从两个方面来看：

     计算的服务模型： 计算的服务模型是从商业的角度看的。我们从传统的购买硬件送软件，到购买软件和维护再到如今购买云服务，云计算平台将计算、存储、网络像煤电一样卖给我们。需要指出，计算资源的这种服务模型并不是在云原生中才强调的，而是从云计算提出的时候，就已经强调了的。

     服务的计算模型： 这个语境中，“服务”不再是商业上的“服务”，而是指“应用服务”。应用服务的计算模型，强调了应用程序的可伸缩性、弹性、自动化和可维护性，以适应现代云环境中的需求。当然，应用的可伸缩、弹性自动化运维这些并不是应用自身具备的能力，而是在云上环境被赋予的，但是需要从应用侧做一定的改造工作，“以适应现代云环境中的需求”，比如下面要说的——应用架构。

• 应用架构 为了最大化发挥云原生的计算优势，应用侧应该也要做架构升级——例如微服务化，在弹性扩缩的时候以更细的粒度进行算力分配，更精确的分配云计算底座资源（计算、存储、网络）——当然，这只是我简单作示意的一种说法。这种说法换个侧面来看，单体应用就不能上云计算么？当然可以，但是那就不叫云原生了，因为单体无法发挥出云计算的最大优势。

     所以从我自己目前的工作经历总结如下： 云原生一定是云计算，特别的，云原生是有效发挥出云计算所有优势的最短路径。理解云原生，可以从代表技术、云原生计算模型、云原生应用架构三方面着手理解。