硅谷火爆的云原生，你会玩吗？

软件行业内，对于“什么是云”各执一词，对“云”的理解也因人而异。套用一句关于BigData 流行的笑话，放在“云”上也适用。Cloud is like teenage sex,everybody talks about it;however,nobody really knows what it is.

云原生到底是什么？

在云计算行业里有很多跟太极一样重意不重形的概念，“云”本身就是一个这样的概念，“云原生”亦然。

从“形”上讲，云原生是面向“云”的软件设计、开发、测试、运维、监控的一整套理念、原则、方法、工具。因此云原生的“形”包含但不限于开发运维一体化（DevOps）、持续交付（Continuous Delivery）、微服务（MicroServices）、容器技术（Container）、康威定律（Conways Law）、精益软件开发（Lean Software Development）。

目前，这类公司已越来越多。但是，原生云有很大一部分是由 DevOps 实践发展而来，需要采用新的工作方法以及学习文化才能从中受益，并不是你花钱就可以买到的。如果你处于一个缓慢变化、严格管控的传统环境，你可能就无法从原生云基础设施受益。

云原生与传统架构的区别并非是关于某项具体的技术或者工具，而主要在于云原生的“意”。云原生的“意”强调应用的快速迭代、弹性伸缩、反脆弱。

为什么在硅谷那么流行？

根据IBM公司在2018年的调查，实践云原生后：

---

应用性能	提高85%，改进的应用程序性能不仅与易于开发相关，而且与改进的应用程序质量，多语言编码支持，应用程序开发自动化和减少的依赖性相关。
灵活性和速度	提高75%，包括增加功能的灵活性以及向上或向下扩展资源以满足用户需求，对于应用程序开发主管来说尤为重要。这可以提高员工的工作效率，加快应用更新速度和业务实施速度，促进业务增长

超过50％的人认为：他们通过云原生应用程序开发取得成功的关键是文化转型的这7个要领：

(1) 小团队拥有整个应用程序的特定组件
(2) 持续开发，交付和性能监控
(3) 应用程序开发人员和IT运营专家之间的协作
(4) 主要利益相关者的积极参与
(5) 更好地分析与最终用户行为相关的数据
(6) 在整个团队中不断集中整合源代码更新
(7) 在开发、测试、预发和生产环境中部署应用程序的管道

“云原生”企业相较于依靠传统IT支撑平台的企业，会具备更高的业务敏捷性、更短的业务上市时间（Time-To-Market），更好的客户体验，以及更强的通过软件的弹性伸缩支撑业务快速增长的能力。

总而言之，人是最重要的，时间最有价值。

云原生与传统三大云(IaaS,Paas,SaaS)将会是谁主沉浮？

这两年IT界“云”烟四起，IaaS、PaaS、SaaS风生水起，三足鼎立。那么云原生与传统云们又有什么关系呢？

云原生的技术部分是构筑在传统三朵云上的，敏捷基础设施对应IaaS部分，微服务则可以对应PaaS和SaaS部分，但是云原生比传统云多了一些企业管理的方法。

注：Cloud Native从技术上更强调敏捷基础设施和微服务的概念，这并不意味着它是完全抛开传统三朵云而独辟蹊径。

云原生的六大护法

(1) DevOps：（Development+Operations）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、运维和质量保障部门之间的沟通、协作与整合。打破部门之间的墙，从而达到1+1>2的效果。

(2) 持续交付：是一系列的开发实践的方法，用来确保代码能够快速、安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。

持续交付可以采 用：CI（持续集成）、代码检查、UT（单元测试），CD（持续部署）等方式，打通开发、测试、生产的各个环节，持续的增量的交付产品。

(3) 微服务：微服务专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序。多种监控方式，路由断路机制也提供了可靠的安全保障。充分展现了高内聚，低耦合的服务优势。

(4) 容器：让应用程序布署在软件货柜下的工作可以自动化进行，借此在Linux操作系统上，提供一个额外的软件抽象层，以及操作系统层虚拟化的自动管理机制。常用Docker+K8s，真正实现了环境分离及易于迁移的特性，根据业务需求自动伸缩监控的功能。

(5) 康威定律：业务云化推行，从某种意义上讲也是一种变革。既然是变革，必然会涉及组织的各个层面，开发、质量、运维等等都会涉及。康威定律则准确的描述了系统架构和组织的关系：组织决定系统架构！

(6) 精益软件开发：和精益制造原则的概念相近，精益开发也可以总结为如下七条原则：消除浪费、增强学习、尽量延迟决定、尽快发布、下放权力、嵌入质量、全局优化。

现阶段大部分企业部署运维痛点及云原生解决手段：

痛点	手段	论证
更快的上线速度，传统的服务上线速度以年、季为单位，跟不上现在的市场需求速度。	持续交付、DevOps、微服务，将上线速度提升到以月、周、日为单位。	现在生存法则不是以大鱼吃小鱼，而是快鱼吃慢鱼，窗口期缩短至数月、数周，快速上线是刚需。
细致的故障探测和发现，服务的复杂度日益增加导致锁定问题难，锁定问题慢等问题。	微服务、容器技术完整的流程监控，服务监控机制可快速锁定服务问题，可以对部分问题进行自动化处理。	千里之堤，毁于蚁穴，早期的米聊拥有先发优势及稳定的米粉客户群，但后面之所以没干过微信，核心原因就是服务器不稳定体验差。
故障时能自动隔离，单体架构通常如果某一模块故障很有可能导致全面瘫痪。	微服务、容器技术就可以将任何⼀个微服务的故障范围限制在这个容器服务内消化。	早期阿里对淘宝做第一次大的架构升级，很大一部分原因就是解决一个小bug导致系统全面崩溃的问题。
故障时能够自动恢复，在传统的服务部署体系下，就算是因为很简单的原因也难以诊断恢复。	微服务、容器技术凭借可视化、故障隔离和容错能⼒，使我们拥有确定故障所需的⼯具，从故障中恢复。	微服务与容器技术会在发现简单故障时无需人为干预就可以恢复服务正常，极大减少了后期运营维护人员的工作量及服务风险。
方便的水平扩容，如果服务量与日俱增，那么一定会给与超量的资源冗余防止服务崩溃，但这些冗余只在某一时刻使用。	微服务的多实例部署及k8s的水平伸缩技术将大大缓解资源浪费的情况。	去年淘宝在央视春晚拿到冠名权，当晚的流量是当年双十一流量的15倍，那么如果我们平时就准备那么多资源，岂不是杀鸡用牛刀。
灰度升级，用户用的好好的，要升级怎么办？一说到这点许多运维朋友就头大，传统直接替换风险太大。	微服务+容器技术可实现灰度升级，也就是先升级一个实例等到实例稳定后再替换其他实例规避了升级风险。	快速迭代已成为大势所趋，如何保证服务一直稳定地给用户带来舒适的体验，微服务+容器技术会给你答案。