云原生概念的诞生

摘要：所谓云原生，它不是一个产品，而是一套技术体系和一套方法论，而数字化转型是思想先行，从内到外的整体变革。更确切地说，它是一种文化，更是一种潮流，是云计算的一个必然导向。

随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型，它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。随着云化技术的不断进展，云原生的概念也应运而生。

云原生概念的诞生

云原生（Cloud Native）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor App）等几大主题，不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。

The Twelve-Factor App

顾名思义，云原生是面向“云”而设计的应用，因此技术部分依赖于传统云计算的3层概念，基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS），例如，敏捷的不可变基础设施交付类似于IaaS，用来提供计算网络存储等基础资源，这些资源是可编程且不可变的，直接通过API可以对外提供服务；有些应用通过PaaS服务本来就能组合成不同的业务能力，不一定需要从头开始建设；还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务，即SaaS能力，用户直接面对的就是原生的应用。

云原生并不是一个产品

最近讨论云原生应用越来越多。关于云原生应用，简单地说，就是大多数传统的应用，不做任何改动，都是可以在云平台运行起来，只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式，仅仅是把虚拟机当物理机一样使用，不能够真正利用起来云平台的能力。

云并非把原先在物理服务器上跑的东西放到虚拟机里跑，真正的云化不仅是基础设施和平台的事情，应用也要做出改变，改变传统的做法，实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变，真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多，如容器技术、微服务、可持续交付、DevOps等。

而云原生应用最大的特点就是可以迅速部署新业务。在企业里，提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险，因为犯错及改错也需要花费同样的时间成本，竞争优势就会由此产生。

所以云原生不是一个产品，而是一套技术体系和一套方法论，而数字化转型是思想先行，从内到外的整体变革。更确切地说，它是一种文化，更是一种潮流，是云计算的一个必然导向。意义在于让云成为云化战略成功的基石，而不是障碍。它可以根据商业能力对公司进行重组的能力，既包含技术、也包含管理，可以说是一系列云技术和企业管理方法的集合，通过实践及与其他工具相结合更好地帮助用户实现数字化转型。

云原生计算基金会（CNCF）

CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包括亚马逊、微软、思科等巨头。

目前CNCF所托管的应用已达14个，下图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系。

Cloud Native Landscape新版

CNCF(云原生计算基金会)认为云原生系统需包含的属性：

容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。

自动化管理：统一调度和管理中心，从根本上提高系统和资源利用率，同时降低运维成本。

面向微服务：通过松耦合方式，提升应用程序的整体敏捷性和可维护性。

正因为如此，你可以专注于创新，解决业务问题，而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。

云原生的四要素：持续交付、DevOps、微服务、容器

从云原生的概念中，我们总是能看到持续交付、DevOps、微服务、容器等技术的出现，那么它们到底是什么，这里引用Pivotal***云计算资深架构师的部分观点，为大家逐一揭开他们的神秘面纱！

01

持续交付——缩小开发者认知，灵活开发方向

首先是持续交付，什么样的时候客户要求持续交付？敏捷开发要求持续交付，因为敏捷开发要求随时有一个版本可以上到大群环境，所以要持续交付。

而换句话说，持续交付就是不误时开发。举一个例子，有些公司非常喜欢谈需求，谈很久，可是开发只剩1/3时间就开发完成，然后交付，再上线运营。这就会碰到一个问题，就是你开始谈需求到最后交付产品的时间，短则三月，长则半年，这中间市场已经变化了，需求也随之变化了。因此市场上出现了新的想法，即是不是能够小步快跑，把交付的周期缩短一点，我可以实现快速交付，每次交付都可以重新确认方向，这样尽量避免与未来期待的落差。

用小步快跑的方式，打破瀑布式开发流程

那么问题来了，持续交付对于开发的人谈的需求、开发的方式有改变，那它对于开发有影响吗？如果说公司的开发团队一天可以交付五次，那研发团队要帮忙部署一次吗？现在公司大部分部署都是研发团队帮忙部署应用的，研发团队部署五次，要改版五次就需要部署一次，这是无法实现的。而且每次部署的时候都要面对停机，而实际公司的应用经不起一天停机五次部署，在互联网的思维之下，零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面，第一版还在线上服务，第二版先做封测，封测完成后，让外面的流量进来一些，看log是不是开发人员要的，确认后再把全部的流量导到新的版本上。

图：蓝绿(Blue-Green) 部署

但“蓝绿部署”在系统过多过复杂的情况下，在传统架构上实现非常困难，所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此，持续交付的优势在于，它可以缩小开发者认知，重新确认开发方向。

02

微服务——内聚更强，更加敏捷

第二部分是微服务。微服务是什么？有客户表示，提供商出产品，客户把应用全部放上去，结果就是一个微服务。这种认知是错误的，因为微服务是一个架构的改变。那么微服务是怎么做的呢？它所面临的最大挑战是什么？

是切割。那么如何切割呢？其实这件事情早在1968年康威就提出了——康威定律，系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法，我认为拿来做微服务的切割非常适用。

Going Agile - Breaking the monolith

Conway's Law and Microservices

这样按照组织架构划分的优势在于：

1.内聚更强，所有遵循同一种业务准则的人内聚在一起，就容易解决问题。

2.服务解耦，变更容易，更加敏捷。当做到解耦合的时候，要变更就容易。所以微服务应该是切分成这个样子，由上而下来切，根据Function来切。

另外一个划分微服务的技巧，可以运用领域驱动设计(Domain Driven Design)的理论，而领域驱动设计亦可算是面向物件的一种设计思维；聚合可以让微服务划分更有依据，也让未來的系統变更具有弹性。值得一提的是领域驱动设计，也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段，相当容易也常见，但在微服务架构中，如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计，是目前最好的解決办法。

那么在什么情况下需要微服务？我认为有三个标准：

1.有HA（High Available）的需求需要微服务。

2.有性能调校的需求（例如：图片的呈现或者搜寻）需要微服务。

3.经常变更的需要微服务。

实际上，微服务需要关注的源代码范围比较小，使得各个服务解耦、变更容易，内聚更强，因为都会集中在服务里。另外，它更容易单独改版，因为微服务之间是用RESTful间接起来的，用RESTful只要API的界面不改，原则上则不会错，也更敏捷。

但微服务也会留下一些问题，例如App团队如何分工？环境怎么配合？如何实现自动化部署?

03

容器技术——使资源调度、微服务更容易

再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程，与任何其他进程无异。那么，为什么容器如此受欢迎呢？原因在于这个进程被隔离和限制的方式。这种方式很特殊，可简化开发和运维。

其实1979年就有容器技术，很多人会以为说Docker是不是等于容器，其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念（cgroup、namespaces和filesystems）在独立的区域运行。容器的神奇之处在于将这些技术融为一体，以实现最大的便利性。

VMware之前的技术专家在2011年发展出一个技术，把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有，而且它第一版是用SLC的技术去做的。后来陆续一路成长，使得为服务的实现更容易了。

从 Infra 角度来看技术演进 

从上面这个表中可以看出，从左边开始，IaaS，虚拟化技术有了之后，刚刚提到的所谓第三代平台，这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进，对于客户的负担越到后面越小，而对于开发人员的想象力则愈发抽象。

大家一定会遇到下列这些计算，一个是所谓的单体应用，或者翻译成巨石应用。此外，你们一定会有一些批次的管理，另外就是所谓的数据库的部分，开始可能会有容器技术，像K8S、Dock。

Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器，谷歌建立了Kubernetes。它提供了一些强大的功能，例如容器之间的负载均衡，重启失败的容器以及编排容器使用的存储。

容器生态图 /作者：Jimmy Song 

容器为云原生应用程序增加了更多优势。使用容器，你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上，而无需重新配置环境，这样就实现了强大的可移植性。

04

DevOps——以终为始，运维合一

最后让我们走向DevOps，它不是一种工具，DevOps其实要谈的是运维合一。

DevOps如果从字面上来理解只是Dev（开发人员）+Ops（运维人员），实际上，它是一组过程、方法与系统的统称，其概念从2009年首次提出发展到现在，内容也非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。

首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。

其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。

总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。在内部沟通上，你可以想象DevOps是一个敏捷思維，是一个沟通的文化。当运营和研发有良好的沟通效率，才可以有更大的生产力。如果你的自动化程度够高，可以自主可控，工作负担降低，DevOps能够带来更好的工作文化、更高的工作效率。

总结

综上所述，云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分，需要以全局地眼光看待问题，脱离任何一个元素，对于企业来说都是“管中窥豹”、“一叶障目”，只有加以整合才能见到云原生的全局风貌。

面对业态各异的业务上云以及碎片化的物联网解决方案部署，利用云原生思维和模式，构建基于云原生的物联网平台以及解决方案，势必将加速企业，甚至整个社会的数字化转型。