云原生、微服务、容器、DevOps概念扫盲，资深技术人员请回避！

随着企业数据量持续增长、业务系统日趋复杂、市场竞争日趋激烈，用户需求需要得到越来越及时的响应，用户服务需要不间断地进行。但采用的传统的云计算服务模式，即按照传统模式开发业务系统然后部署到云上，会使得云计算按需定制、弹性伸缩等优势难以充分发挥。为解决以上问题，“云原生”就此诞生。

云原生是指专门为在云平台部署和运行而设计的应用及架构，包括十二项基本要素，分别是：

1.同一应用对应同一套基准代码，并能多次部署；

2.显式声明第三方依赖；

3.将配置存储至环境变量；

4.将后端服务作为松耦合的资源；

5.严格分离构建阶段与运行阶段；

6.将应用作为无状态的进程运行；

7.通过端口绑定对外发布服务；

8.能够通过水平伸缩应用程序进程来实现并发；

9.可以快速启动和关闭应用；

10.要保持开发环境与生产环境等价；

11.使用事件流处理日志；

12.将后台管理任务当做一次性进程运行。

更具体来说，云原生涉及一系列技术，典型技术包括以Docker和Kubernetes编排工具为主的容器技术、以Service Mesh为发展方向的微服务技术，以及以快速迭代、持续交付为目的的DevOps（开发运维一体化）技术。

关于容器技术。

容器是指将应用程序及其环境一起打包作为交付物，该交付物可以随时构建、装载、运行。由于其它类型容器（如RKT）市场占比较低，容器一般指Docker。

容器编排工具是指让集群中的多个容器能够按计划、有组织运行的工具。Kubernetes作为CNCF孵化项目，相比Mesos和Swarm已经呈现出十分明显的优势。

传统虚拟机包含完整的操作系统，一旦开启即对硬件资源的一部分独占。容器引擎只是一个隔离的进程，对资源并不独占，因此是一种更轻量的虚拟化。这使得容器在文件体积、启动速度、占用资源和开启数量上都具有明显优势。

容器将依赖环境一起打包，因而屏蔽了开发、测试和运行环境的差异，再加上秒启、可多开的特性，使得微服务和DevOps均得以实现。所以可以说，容器技术是云原生的最佳载体，成为云原生的基石

关于微服务。

采用化整为零的概念，将复杂的IT系统部署，通过功能化、原子化分解，形成一种松散耦合的组件，让其更容易升级和扩展。

每个应用组件将其自身功能以服务的形式展现出来，并按照预先定义的协议进行交互，各个服务组件之间是松耦合的。

某个应用组件的编程语言与技术选型不会影响主体应用，如某个服务组件可以用Java 开发，而另一个可以用.NET开发。

每个服务组件都可以享有自己的数据库，且该数据库仅供该服务组件自己使用，其他服务组件都不能读取或者修改。

每个服务组件都是可以自行部署和测试的，任何一个服务组件在测试、部署和运行的时候都不依赖其他服务组件。

任何一个服务组件的故障都应该是隔离的，单个服务组件的故障不应该拖垮整个应用，也不应该影响其他服务组件。

微服务是云原生的实现方式，不仅涉及技术架构，还涉及业务怎么划分以及组织如何管理，如不同步规划将无法发挥其价值。

关于DevOps。

随着企业IT系统越来越复杂，功能迭代、局部升级、A/B Test甚至版本回滚成为常态，这都对开发、运维模式提出了新挑战，DevOps应运而生。

DevOps即开发运维一体化，是敏捷开发的继承和发展，目的是持续集成、持续交付，贯穿于开发到上线的始终。

DevOps因Docker的使用而更加简单，所以完整的DevOps体系中会包含Docker、Kubernetes等工具。

DevOps和微服务很多技术都是重合的，但两者的关注点并不同，微服务帮助我们以一种细颗粒度的方式开发、测试和发布服务，而DevOps提倡小规模和小批量的持续集成和持续部署，两者相辅相成的，共同解决问题；

DevOps进一步增强了云原生的敏捷特性，但其同样对企业内部的业务职责划分和组织架构调整提出了要求。

总结一下，容器+微服务+DevOps是实现云原生的最佳组合，但只有容器是一种比较明确的技术，而微服务和DevOps更像是一种方法论，仅仅有技术层面的配合是远远不够的，还需要有组织架构层面以及管理流程层面的共同配合才能发挥作用。

创作不易，欢迎朋友们关注、评论、转发。