技术专题·云原生(Cloud Native)
一、李明宇
李明宇，独立技术咨询师，前中科院软件所课题组负责人
点评内容：
最近，我们听到越来越多的人谈论“云原生”(Cloud Native)，这是一个非常喜人的现象。我在从事云计算领域技术工作的几年里，致力于帮助传统行业的企业实现IT系统的云化。我们经常面对的一个问题是要向传统行业的客户说清楚：云不是把原先在物理服务器上跑的东西放到虚拟机里跑，也不是在Dashboard上点点鼠标创建虚拟的网络和路由器，真正的云化不仅仅是基础设施和平台的事情，应用也要做出改变，改变传统的做法，实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变，真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是我们今天所说的“云原生应用”(Cloud Native Application)。云原生架构和云原生应用所涉及的技术很多，如微服务、容器技术等等，我这里列举几个比较容易被忽视但在我的工程实践中曾发挥过重要作用的：
1. 云平台的API
如今成熟的云平台都有完备的API。不论是公有云还是私有云，不论是闭源商用产品还是开源的OpenStack，API都扮演了极其重要角色，它彻底改变了我们对基础设施的使用模式，我们可以在应用的代码中通过调用API来创建、管理和删除基础设施，包括计算、存储、网络资源以及云平台上提供的数据库、大数据框架、负载均衡集群等服务的实例。成熟的云平台中Web界面和命令行工具本身的所有功能都是通过调用API来实现的。
一般来说，云平台的API是基于HTTP的RESTful Web API，许多云平台能够兼容亚马逊AWS的API。比较成熟的云平台中还提供Orchestration服务，方便大家用基于Yaml的模板来实现对API的调用。使用Orchestration服务还可以实现对复杂云应用的快速部署。
2. 自动伸缩服务
通过自动伸缩服务来充分发挥云的弹性，在应用压力过大时，自动创建实例分担负载;在应用压力降低时，自动删除实例释放空闲资源。自动伸缩服务和负载均衡服务往往需要配合使用。
结合容器技术，并以微服务架构设计和开发应用时，每个微服务都可以配置为自动伸缩组，这样可以做到非常细粒度的弹性，准确有效地化解应用的瓶颈，提高资源的利用效率。
3. 大数据即服务(Hadoop等大数据系统的云化)
与传统IT架构中的应用类似，云上的应用同样需要用到大数据处理技术，而Hadoop、Spark等大数据系统在设计时考虑的是在物理机器上运行的，加上这些系统本身的复杂性，如果直接将其放到虚拟机或者容器中运行，可能会遇到很多问题。这时候应当通过一些专门为大数据系统云化准备的技术，例如OpenStack的Sahara、SequenceIQ的CloudBreak、AWS的EMR等，或者一些商用方案，实现“大数据即服务”(Big Data as a Service)。应用在使用大数据技术时，通过调用服务创建云上的大数据系统，再通过调用服务使用这些大数据系统。而不是创建一堆虚机或者容器，并在里面安装一套大数据系统出来。也就是说，一方面，大数据系统本身也要实现云化;另一方面，云原生应用对大数据系统的使用是通过调用云服务来实现的。
4. 服务化的存储
存储的服务化往往是容易被忽视的地方，因为我们太习惯使用文件系统了，不论是本地文件系统还是NAS，即便是使用了云硬盘、Virtual SAN和类似OpenStack Manila的“文件系统即服务”，在应用这个层面上，使用存储的接口还是传统的、本地的文件系统接口，而不是使用服务。这种方式不论是对于应用还是存储本身，其可扩展性和可用性都是挑战。云原生架构中应当使用服务化的存储，服务化的存储分为两类——数据库和对象存储。数据库以记录的形式存储和访问数据，可以是结构化的或者非结构化的。数据库本身即能够以服务的形式提供访问，对于与云原生架构来说，还应当采用“数据库即服务”(Database as a Service)，其原因和做法与上述采用“大数据即服务”类似。而对于类似于BLOB的非结构化数据存储，传统的做法是存在文件系统中，在云原生应用中应当使用对象存储，对象存储通过HTTP提供服务化的数据读写接口。
二、杨海明
杨海明，京东云首席架构师
点评内容：
新的业务生态催生了新的技术架构，传统的烟囱型应用经历了SOA的第一次变革，现在进入了Cloud Native的新形态。
传统的烟囱型架构，由服务器、操作系统、中间件、及专属业务流程软件构成。回顾近些年IT界流行的趋势，软件定义环境、数据状态功能分离、弹性扩展、自动高可用、Devops等最新的业界趋势构成了Cloud Native的业务形态。
从业务角度，云把传统复杂的定制的小众的业务以标准化的形式给更多的用户提供出来，从技术角度，需要有能支撑标准化扩展业务的基础技术提供出来。在云的业务需求下，下层的IT技术需要可以跨平台的弹性扩展，在整个开发测试流程中更agile，在业务出现灾难时更容易的恢复。Cloud native的诞生，不是一个技术推动的产物，而是云业务发展到一定阶段对技术架构的需求。传统IT时代，是个Scale-up的时代，为了支持更多业务，需要基础IT架构的纵向升级，比如更强大的机器;但是在云的时代，个体的需求往往不是很复杂，但是Scale-out的需求更强烈。
基础IT如何支撑新的业务形态?在看起来，Cloud Native的技术是一个明显的答案。在新的技术下，硬件技术，操作系统技术，中间件技术，以及应用逻辑均进行了有效的重新定位。在京东云平台Cloud Native的实践中，充分体验到了弹性扩容，自动灾备的好处，并经历了双十一和618的大考;可以预见在未来的技术发展中，Cloud Native会催生出更多的业务向云转型，并带动新的IT技术发展。
三、喻勇
喻勇，DaoCloud联合创始人
点评内容：
在未来几年，Cloud Native将从一个技术术语，转变为一个管理命题。
计算机技术发展至今，每一代的硬件平台，都会催生对应的软件架构，从大型机到PC时代的C/S桌面应用到互联网时代的B/S架构。如果把云计算看作是一个全新的硬件或者资源平台，在此基础上的软件开发，就是Cloud Native。过去很多年，由于虚拟化的便利，云计算经历了新瓶装旧酒的过程，如今，随着互联网业务的深入发展，开发者并不满足于把旧有应用简单的向单一的云主机迁移，而是希望把云平台作为一个整体，在此基础上完成分布式的、动态弹性的 Cloud Native Application。在技术领域，最近广受关注的容器技术、微服务架构、十二要素法则、不可变基础设施等等，都是为了Cloud Native Application 订立标准。
从另外一个角度来看，大量的传统企业拥抱互联网，除了在软件架构层面实现Cloud Native，越来越多企业会从组织架构、决策流程、销售策略等方向进行管理转型。以 Cloud 为载体的互联网经济学，讲究唯快不破，企业为了在快速变化的互联网市场取得成功，需要拥抱 Cloud Native 式的管理哲学：轻量级、高速响应、按需弹性，对应于管理，就是更加扁平的组织架构、更具弹性的的决策流程，传统和常见的市场、分销、甚至人力资源管理，都将逐步进化到 Cloud Native 的层面。仅仅在技术层面做架构变革，背后的管理和组织架构不发生变化，是很快会遇到瓶颈的。
四、编辑
云计算频道编辑 于雪
最近，“Cloud Native”快速走进越来越多技术人的视野。2015年7月，谷歌、IBM、英特尔、Joyent Docker 等19家知名公司共同创建起一个名为“云原生计算基金会”的年轻的开源基金会组织，其目标在于解答一个困扰业界的难题——云体系应该采用怎样的架构来服务现代应用程序。