前言
云原生是当下的热点话题，但是很多人对云原生有很多误解，特别是传统产业物联网或工控、物联网行业对云原生显得”后知后觉”。与其在这里说是预测，不如说是现在进行时，只是由于传统产业本身的技术包袱和组织个人认识程度差异，目前发展并不见快。目前大部分的系统还是停留在旧年代，只是不到火候，还没到尝鲜和推倒重来的必要。但是，面对未来业务的持续增长和行业竞争，必然要面临一个技术的现代化转型升级，即：使用新技术代替老技术，使用新观念代替老观念的痛苦过程。否则老系统必然会变成企业发展的一个瓶颈，因为基于老系统的修修补补只会使系统变得更加复杂和难以维护，最后等待他们的是要么推到重来，要么是逐年生锈老化（修修补补又三年）。我这里针对新近的云原生作为一个切入点，来说明一下为什么说云原生会成为未来企业技术变迁的一个趋势。
概念诞生
云原生（Cloud Native）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。
这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括：
- DevOps
- 持续交付（Continuous Delivery）
- 微服务（MicroServices）
- 敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor App）等几大主题。
不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。
概念理解
云原生我这里简单的把它拆成云+原生两个部分来理解。
云：和本地相对。很多人提到云容易先入为主的认为是阿里云，百度云。其实这朵云可以是阿里的公有云，也可以是自家的私有云，或者是混合云，不能简单的理解云原生就要把应用部署在阿里云。运用跑在哪朵云需要权衡利弊再抉择。
不同于传统的是，站在研发的整个工程纬度来看，从研发的开始阶段就要设计面向云的系统，而不是先按传统的思路来设计开发，再去做迁移部署，最后导致迁移水土不服。
什么是设计面向云的系统呢？这就要来理解原生的内涵。
原生：就是土生土长的意识，也就是应用一出生就带有云的基因。所谓云的基因是基于微服务原理而开发的应用，以容器方式打包，在运行时，容器由运行于云基础设施(PASS或者叫云操作系统)之上的平台进行调度，应用开发采用持续交付和DevOps实践。
根据刚才的理解，我把这些概念抽象成脑图：
理解了整体概念，其中蕴含的价值也能逐渐明白清晰，接下来我逐个来展开分析，重点看下其中内置的四个子概念。
微服务
微服务的终极价值在于借鉴乐高思想，把应用服务按照领域划分成一个个微服务。
微服务是种理念，它的本质就是分而治之。可以是物理的拆分，也可以是领域的划分，或者是软件接口划分等等。
从中台纬度看，不管是产业互联网、还是传统互联网，亦或是新兴的物联网，他们在系统底层都有相通的技术支撑：比如都需要硬件基础设施层(iaas)，需要中台服务层(paas)，需要软件服务层(saas)。不同是软硬件规模大小，复杂度高低的差异。
微服务能力的强大在于，提供了灵活多变的定制化能力，比如在物联网领域，从功能维度可以分为：统一身份认证服务、设备管理服务、设备告警监控服务、故障预测服务、报表分析服务等（具体划分可以参看我的另外一篇文章《微服务划分的姿势》），最后达到服务之间的任意拼装，极大的提高了服务的复用，同时降低了重复开发成本。
容器化
- 一键部署
容器化技术通过打包机制和自动化编译发布能力，解决了单个服务部署麻烦的问题。服务在不同的开发、生产环境下再也不用因为环境不一致而头疼。
服务一次打包，合理编排即可随处运行，极大地提高了部署效率，几乎可以做到一键部署。
- 混合编排
应用服务之间需要拼装才能自由组合。容器化技术给混合编排提供了可能，借助k8s的能力，服务的发布和编排变成了一个个yml文件的简单配置。
DevOps
DevOps如果从字面上来理解就是Dev（开发人员）+Ops（运维人员），开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。实际上，它是一组过程、方法与系统的统称。
首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和测试部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。
其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。
再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。
总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。在内部沟通上，你可以想象DevOps是一个敏捷思维，是一个沟通的文化。当运营和研发有良好的沟通效率，才可以有更大的生产力。如果你的自动化程度够高，可以自主可控，工作负担降低，DevOps能够带来更好的工作文化、更高的工作效率。
持续交付
持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，换句话说，持续交付就是不误时开发，用小步快跑的方式，打破瀑布式开发流程的拖延。要做到这点非常非常难。
首先我们要理解整个软件的开发模式（具体详见我之前的一篇文章《软件开发模式：瀑布与敏捷》）
有了软件开发模式的知识储备，我们知道了什么是敏捷开发模式，什么是每日站会，敏捷团队人员数量控制等等。我们再回头看下如何做得持续交付？
交付的速度要高速度，还要高可用，这怎么落地？为此，我这边还要一个一个概念要分享叫MVP（最小可行性产品），这是产品经理耳熟能详的。
我把他翻译成白话一点并举个场景的案例：加入我要一辆特斯拉智能电动车，我不会一下子给你在某个时间点交付整车。我会在前期设计一张核心蓝图，交付的过程类似分期付款，我先根据任务的优先级顺序，把最重要最紧急的任务，比如发动机花一个月时间造好了交付给你；接下来根据优先级队列，我可能会取出排在第二的任务，比如说轮胎，再花一周时间造好了给你。直到整个任务池的任务全部完成为止。
因此，持续交付的优势在于:
- 它可以缩小开发者认知，重新确认开发方向；
- 同时可用让这些任务并行开发，甚至采用7*24小时的开发机制，两班倒(通常游戏开发就是这么玩的)
- 如果中间发现问题，因为船小好调头，修修改改也就特别快了。
当然，持续交付也是有代价的，比如沟通成本，前期设计考虑不周导致的返工和修改成本。但是对于市场经济讲求高效和淘汰的原则，这些代价都可用忽略不计。试想，如果王者荣耀采用瀑布式来交付产品，那么市场上早就没有它的一席之地了，更别谈其他同类游戏开发了。
云基础设施
我们从三个维度来看云基础设施：
- 逻辑层面：可以理解成是抽象的超级计算机，通过软件比如k8s，把n台服务器组装成一台抽象的超级计算机，他是属于pass层（平台即服务）
- 物理层面：
- 这个集群由很多节点组成，而且可以按需添加更多节点，这些节点可以是物理机也可以是虚拟机。
- 每个节点都有一定的CPU和内存容量。
- 整个集群的CPU和容量是所有节点的CPU和容量总和，而且可以按需给这台计算机添加更多的CPU和内存。
从这个层面理解，它是iaas层。
- 部署层面
- 公有云，可以是阿里云，微软或亚马逊云，前提是应用要设计成面向云原生应用。
- 私有云，可以自建数据中心或者是集团企业的数据中心，这个数据中心可大可小，大到成百上千台服务器，小到1台服务器。当然这里运维的人员也会跟着变动。
- 混合云，对上面两种部署的混合使用，也就是一部分应用放在公有云，比如说统一认证授权服务；一部分应用放在私有云，比如说核心数据。
这里为什么没有saas，因为saas是运行于云操作系统至少的应用，面向的是业务层面，不能算是基础设施。
回顾:
至此，你对云原生的内涵理解应该达到了”充血模型”了，那么我们来总结一下云原生技术变迁：
- 云原生的技术变迁受到各自因素影响，前期发展缓慢，后期爆发的一个过程。比如业务发展，技术的历史包袱，组织和个人对云原生的重视程度等等，并不会发展得那么快，那么一帆风顺，可能会是一个3-5年甚至更久的过程，但是整个势头是不可阻挡的。
- 云原生涉及到的不仅仅是技术层面的升级，更是是文化、组织架构、方法论的变更。
- 微服务因为有了容器技术(k8s)和DevOps的加持，开发成本会持续的接近单体项目的成本，当二者趋向一致的时候，就是引爆的时候。