共计 3731 个字符，预计需要花费 10 分钟才能阅读完成。
云原生是当下的热点话题，然而很多人对云原生有很多误会，特地是传统产业物联网或工控、物联网行业对云原生显得 ” 后知后觉 ”。与其在这里说是预测，不如说是当初进行时，只是因为传统产业自身的技术包袱和组织集体意识水平差别，目前倒退并不见快。目前大部分的零碎还是停留在旧年代，只是不到火候，还没到尝鲜和推倒重来的必要。然而，面对将来业务的持续增长和行业竞争，必然要面临一个技术的现代化转型降级，即：应用新技术代替老技术，应用新观点代替老观点的苦楚过程。否则老零碎必然会变成企业倒退的一个瓶颈，因为基于老零碎的修修补补只会使零碎变得更加简单和难以保护，最初期待他们的是要么推到重来，要么是逐年生锈老化（修修补补又三年）。我这里针对早先的云原生作为一个切入点，来阐明一下为什么说云原生会成为将来企业技术变迁的一个趋势。
概念诞生
云原生（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 的加持，开发成本会继续的靠近单体我的项目的老本，当二者趋势统一的时候，就是引爆的时候。
以上是集体的浅见，你感觉云原生对于研发团队的意义了吗？你感觉在研发效力，业务规模化变更和推动传统技术现代化降级上有没有价值呢？心愿你能留言探讨，聆听您不一样的浅见。
欢送关注公众号【码农开花】一起学习成长
我会始终分享 Java 干货，也会分享收费的学习材料课程和面试宝典
回复：【计算机】【设计模式】【面试】有惊喜哦
