为何说云原生会成为将来企业技术变迁的趋势

云原生是当下的热点话题，可是不少人对云原生有不少误解，特别是传统产业物联网或工控、物联网行业对云原生显得"后知后觉"。与其在这里说是预测，不如说是如今进行时，只是因为传统产业自己的技术包袱和组织我的认识程度差别，目前发展并不见快。目前大部分的系统仍是停留在旧年代，只是不到火候，还没到尝鲜和推倒重来的必要。可是，面对将来业务的持续增加和行业竞争，必然要面临一个技术的现代化转型升级，即：使用新技术代替老技术，使用新观念代替老观念的痛苦过程。不然老系统必然会变成企业发展的一个瓶颈，由于基于老系统的修修补补只会使系统变得更加复杂和难以维护，最后等待他们的是要么推到重来，要么是逐年生锈老化（修修补补又三年）。我这里针对新近的云原生做为一个切入点，来讲明一下为何说云原生会成为将来企业技术变迁的一个趋势。

概念诞生

　　云原生（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的加持，开发成本会持续的接近单体项目的成本，当两者趋向一致的时候，就是引爆的时候。

　　以上是我的的浅见，你以为云原生对于研发团队的意义了吗？你以为在研发效能，业务规模化变动和推动传统技术现代化升级上有没有价值呢？但愿你能留言探讨，倾听您不同的高见。

参考文章：

• 畅谈云原生和K8S发展
• 云原生