2021-03-13

云原生（Cloud Native）打通云计算之路“最后一公里”，云原生四驾马车：持续交付、DevOps、微服务、容器

伴随云计算洪流的滚滚浪潮，过去这3-5年Cloud在国内可谓得到了充足的养分和环境，得以快速发展，落地生根，从最初的虚拟化部署，私有化部署，逐渐转向公有云，混合云模式。这已经不是新鲜的技术了，可以说未来传统的业务不上云真的会死掉的，面临技术高速革新和发展的今天，资源利用效率，节约成本，快速，高速变得尤为重要，可以说时间就是金钱，谁走在前面，谁更高瞻远瞩更能抓住机遇，更能成功。

现在我们经常会听到云原生这样一个概念，那么什么是云原生呢，今天我们来深度解析一下。全文比较长，需要至少10分钟。由于Docker内容比较多，此处我主要剖析

可持续交付，DevOps、微服务，至于容器我会在其他文章单独讲解。

翻阅众多的资料，多数人都会看得云里雾里，搞不懂到底是什么，雾里看花分不清，之所以很多文章解释不清楚，是因为没有确切的定义。任何技术的变革，一定是思想先行，

一、云原生的诞生之路

云原生（Cloud Native）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor App）等几大主题。2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

要明确的是云原生，它不是一个产品，而是一套技术体系和一套方法论，而数字化转型是思想先行，从内到外的整体变革。更确切地说，它是一种文化，更是一种潮流，是云计算的一个必然导向。云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

就云原生四个关键的核心要素，我们可以从下面图片分析，云原生的四要素：持续交付、DevOps、微服务、容器

1、微服务：

微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

微服务是一种构建分布式系统的可演进架构模式,

1. 微服务架构是一种架构模式，将单体应用划分成一组小的服务，服务之间互相协作，共同实现系统功能
2. 每个服务运行在其独立的进程中，服务间采用轻量级的通信机制协作（通常是基于Restful API）
3. 每个服务都围绕着具体业务进⾏构建，由独立的小团队负责设计、开发、测试，并可以独立部署到生产环境

 

 

 

为了让您更好地理解微服务，我们可以想象一下在线购物时的情景。您应该使用了网站上的搜索栏来浏览产品。这个搜索功能就是一项服务。您可能也看到了相关产品推荐，这些推荐项均来自顾客偏好数据库。而这也是一项服务。您有将商品添加到在线购物车中吗？没错，这又是另一项服务。

所以说，微服务就是应用的各项核心功能，而且这些服务均可独立运行。但是，微服务架构不只是应用核心功能间的这种松散耦合，它还涉及重组开发团队、涉及如何进行服务间通信以应对不可避免的故障、满足未来的可扩展性并实现新的功能集成。

在什么样的情况下我们会用到微服务？我认为有三个标准：

1.有HA（High Available）的需求需要微服务。

2.有性能调校的需求（例如：图片的呈现或者搜寻）需要微服务。

3.经常变更的需要微服务。

最后我们来看看微服务的优势有哪些？

微服务可通过分布式部署，大幅提升您的团队和日常工作效率。您还可以并行开发多个微服务。这意味着更多开发人员可以同时开发同一个应用，进而缩短开发所需的时间。

1）加速做好面市准备

由于开发周期缩短，微服务架构有助于实现更加敏捷的部署和更新。

2）高度可扩展

随着某些服务的不断扩展，您可以跨多个服务器和基础架构进行部署，充分满足自身需求。

3）出色的弹性

只要确保正确构建，这些独立的服务就不会彼此影响。这意味着，一个服务出现故障不会导致整个应用下线，这一点与单体式应用模型不同。

4）易于部署

相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，所以您无需为它们的部署操心。虽然对部署时的协作要求更高，但之后能获得巨大回报。

5）易于访问

由于大型应用被拆分成了多个小型服务，所以开发人员能够更加轻松地理解、更新和增强这些服务，从而缩短开发周期（尤其是在搭配使用敏捷的开发方法时）。

6）更加开放

由于使用了多语言 API，所以开发人员可以根据需要实现的功能，自由选用最适合的语言和技术。

2、DevOps

(1)（DevOps定义）

DevOps的本质是集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。

大家可以看下AWS给了一个非常清晰且形象的场景。

             

 

（2) DevOps 的工作原理

在 DevOps 模式下，开发团队和运营团队都不再是“孤立”的团队。 有时，这两个团队会合为一个团队，他们的工程师会在应用程序的整个生命周期（从开发测试到部署再到运营）内相互协作，开发出一系列不限于单一职能的技能。

在一些 DevOps 模式下，质保和安全团队也会与开发和运营团队更紧密地结合在一起，贯穿应用程序的整个生命周期。当安全是所有 DevOps 团队成员的工作重心时，这有时被称为“DevSecOps”。

这些团队会使用实践经验自动执行之前手动操作的缓慢流程。他们使用能够帮助其快速可靠地操作和发展应用程序的技术体系和工具。这些工具还可以帮助工程师独立完成通常需要其他团队协作才能完成的任务（例如部署代码或预置基础设施），从而进一步提高团队的工作速度。

(3) DevOps 的优势

 

1、速度

高速运转，让您可以更快速地针对客户进行创新、更好地适应不断变化的市场，同时更有效地推动业务成果。DevOps 模式能够帮助您的开发人员和运营团队实现这些目标。例如，微服务和持续交付能够让团队充分掌控服务，然后更快速地发布更新。

2、快速交付

提高发布的频率和速度，以便您能够更快速地进行创新并完善产品。您发布新功能和修复错误的速度越快，就越能快速地响应客户需求并建立竞争优势。持续集成和持续交付是自动执行软件发布流程（从构建到部署）的两项实践经验。

3、可靠性

确保应用程序更新和基础设施变更的品质，以便您能够在保持最终用户优质体验的同时，更加快速可靠地进行交付。使用持续集成和持续交付等实践经验来测试每次变更是否安全以及能够正常运行。监控和日志记录实践经验能够帮助您实时了解当前的性能。

 

4、规模

大规模运行和管理您的基础设施及开发流程。自动化和一致性可在降低风险的同时，帮助您有效管理复杂或不断变化的系统。例如，基础设施即代码能够帮助您以一种可重复且更有效的方式来管理部署、测试和生产环境。

5、增强合作

建立一个适应 DevOps 文化模式的更高效的团队，强调主人翁精神和责任感。开发人员和运营团队密切合作，共同承担诸多责任，并将各自的工作流程相互融合。这有助于减少效率低下的工作，同时节约大家的时间（例如，缩短开发人员和运营团队之间的交接时间，编写将运行环境考虑在内的代码）。

6、安全性

在快速运转的同时保持控制力和合规性。利用自动实施的合规性策略、精细控制和配置管理技术，您可以在不牺牲安全性的前提下采用 DevOps 模式。例如，利用基础设施即代码和策略即代码，您可以大规模定义并追踪合规性。

 

DevOps 实践经验

为例让大家更好地理解DevOps,以下列举了一些 DevOps 最佳实践： 

• 持续集成
• 持续交付
• 微服务
• 基础设施即代码
• 监控和日志记录
• 沟通与合作

三、持续交付：持续交付——缩小开发者认知，灵活开发方向

1. 定义：

敏捷开发要求持续交付，因为敏捷开发要求随时有一个版本可以上到大群环境，所以要持续交付。而换句话说，持续交付就是不误时开发。

采用持续交付时，系统会构建并测试每一个代码变更，然后将其推送到非生产测试环境或临时环境中。生产部署前可能存在多个并行测试阶段。持续交付与持续部署之间的区别在于，需要手动批准才能更新到生产环境。对于持续部署，生产会在没有明确批准的情况下自动发生。 

持续交付可实现整个软件发布流程的自动化。提交的每一个修订都会触发一个自动化流程，即构建、测试并提供更新。部署到实际生产环境的最终决定由开发人员触发。

举一个例子，有些公司非常喜欢谈需求，谈很久，可是开发只剩1/3时间就开发完成，然后交付，再上线运营。这就会碰到一个问题，就是你开始谈需求到最后交付产品的时间，短则三月，长则半年，这中间市场已经变化了，需求也随之变化了。因此市场上出现了新的想法，即是不是能够小步快跑，把交付的周期缩短一点，我可以实现快速交付，每次交付都可以重新确认方向，这样尽量避免与未来期待的落差。

现在公司大部分部署都是研发团队帮忙部署应用的，研发团队部署五次，要改版五次就需要部署一次，这是无法实现的。而且每次部署的时候都要面对停机，而实际公司的应用经不起一天停机五次部署。

在互联网的思维之下，零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面，第一版还在线上服务，第二版先做封测，封测完成后，让外面的流量进来一些，看log是不是开发人员要的，确认后再把全部的流量导到新的版本上

“蓝绿部署”在系统过多过复杂的情况下，在传统架构上实现非常困难，所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此，持续交付的优势在于，它可以缩小开发者认知，重新确认开发方向。

2. 持续交付的优势