云原生这个词由来已久，IT行业也永远不缺乏新概念。2015年，Pivotal公司的马特·斯泰恩（Matt Stine）提出Cloud Native这一概念，并对云原生的概念进行了详细的阐述。云原生的主旨是构建运行在云端的应用程序，致力于使应用程序能够最大限度地利用云计算技术特性的优势，提供更加优质的应用服务。
云原生也是一种构建和运行应用程序的方法，它充分利用了云计算的优势，重点关注如何在云计算交付模式下创建和部署应用程序。云原生应用适用于公共云和私有云，开发人员可以充分利用当前云计算平台上的资源来构建应用，采用适用于云计算环境下的开发方法进行软件开发。通过云原生的方式构建和运行应用程序，使企业更敏捷地进行创新，以更快速地向市场推广产品和服务，做到更快速地响应客户需求。
云原生与传统云计算最大的区别在于，传统云计算关注的是如何提供性价比最高的计算、存储、网络资源，而云原生关注的是如何让产品能够支持快速验证业务模式，如何简化复杂的开发流程、提升研发效率，如何保障产品的高可用性让业务无须承受成长之痛，如何实现大规模弹性伸缩轻松应对业务爆发等。
为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。云原生可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。另外，云原生也很好解释了云上运行的应用应该具备什么样的架构特性——敏捷性、可扩展性、故障可恢复性。
云原生的内容
云原生是面向“云”设计的应用，因此技术部分依赖于传统云计算的三层概念，即基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。例如，敏捷的不可变基础设施交付类似于IaaS，用来提供计算网络存储等基础资源，这些资源是可编程且不可变的，可以直接通过API对外提供服务；有些应用通过PaaS服务就能组合成不同的业务能力，不一定需要从头开始建设；还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务，即SaaS能力，用户直接面对的就是原生的应用。
应用基于云服务进行架构设计，对技术人员的要求更高。除了对业务场景的考虑外，对隔离故障、容错、自动恢复等非功能需求会考虑更多。借助云服务提供的能力也能实现更优雅的设计，例如弹性资源的需求、跨机房的高可用、11个9（99.999999999%）的数据可靠性等特性，基本是云计算服务本身就提供的能力，开发者直接选择对应的服务即可，一般不需要过多考虑本身机房的问题。如图所示，目前业界公认的云原生主要包括以下几个层面的内容。
- 敏捷基础设施
正如通过业务代码能够实现产品需求、通过版本化的管理能够保证业务的快速变更，基于云计算的开发模式也要考虑如何保证基础资源的提供能够根据代码自动实现需求，并记录变更，保证环境的一致性。使用软件工程中的原则、实践和工具来提供基础资源的生命周期管理，意味着工作人员可以更频繁地构建更强可控或更稳定的基础设施，开发人员可以随时使用一套基础设施来服务于开发、测试、联调和灰度上线等需求。当然，同时要求业务开发具有较好的架构设计，不需要依赖本地数据进行持久化，所有的资源都可以随时拉起、随时释放，同时以 API的方式提供弹性、按需的计算和存储能力。
技术人员部署服务器、管理服务器模板、更新服务器和定义基础设施的模式都是通过代码来完成的，并且是自动化的，不能通过手工安装或克隆的方式来管理服务器资源。运维人员和开发人员一起以资源配置的应用代码为中心，而不再是一台台机器。基础设施通过代码来更改、测试，在每次变更后执行测试的自动化流程中，确保能维持稳定的基础设施服务。 - 持续交付
持续交付是一系列的开发实践方法，分为持续集成、持续部署、持续发布等阶段，用来确保从需求的提出到设计开发和测试，再到让代码快速、安全地部署到产品环境中。
- 持续集成：是指开发人员每提交一次改动，就立刻进行构建和自动化测试，确保业务应用和服务能符合预期，从而可以确定新代码和原有代码能否正确地集成在一起。
- 持续交付：是指软件发布的能力，在持续集成完成之后，能够提供到预发布之类的系统上，达到生产环境的条件。
- 持续部署：是指使用完全的自动化过程来把每个变更自动提交到测试环境中，然后将应用安全地部署到产品环境中，打通开发、测试、生产的各个环节，自动持续、增量地交付产品，也是大量产品追求的最终目标，当然，在实际运行的过程中，有些产品还会增加灰度发布等环境。
总之，持续交付更多的是代表一种软件交付的能力，过程示例如图所示。
-
DevOps
DevOps从字面上理解只是Dev（开发人员）+ Ops（运维人员），实际上它是一组过程、方法与系统的统称。DevOps 的概念从 2009 年首次提出发展到现在，内容非常丰富，有理论也有实践，包括组织形式、自动化、精益、反馈和分享等不同方面。
（1）组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合。简单而言，组织形式类似于系统分层设计。
（2）自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，例如上述的持续交付过程必须实现自动化才有可能完成快速迭代。
（3）DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。
总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件，如图所示。
-
微服务
传统业务架构面临的一些问题：
① 单体架构在需求越来越多的时候无法满足其变更要求，开发人员对大量代码的变更会越来越困难，同时也无法很好地评估风险，所以迭代速度慢。
② 系统经常会因为某处业务瓶颈导致整个业务瘫痪，架构无法扩展，木桶效应严重，无法满足业务的可用性要求。
③ 整体组织效率低下，无法很好地利用资源，存在大量的浪费。
微服务的优势：
①微服务是一种架构风格，也是一种服务；
②微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成，
③它采用 UNIX 的设计哲学——每种服务只做一件事，是一种松耦合的、能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）。
一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小。每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。
根据业务的需求，不同的服务可以根据业务特性进行不同的技术选型，是计算密集型还是I/O密集型应用都可以依赖不同的语言编程模型，各团队可以根据本身的特色独自运作。服务在压力较大时，也可以有更多容错或限流服务。
云原生应用的技术手段
从宏观概念上讲，云原生是不同思想的集合，集目前各种热门技术之大成，根据云原生的内容，可对应图8.6所示的几个关键技术。
在实际的云原生开发过程中，团队需要一个构建和运行云原生应用程序的平台，这个平台需要具有高度自动化和集成化的特点。从具体的技术手段来说，它会涉及微服务、DevOps、持续集成（Continuous Integration，CI）与持续交付（Continuous Delivery，CD）、容器等技术。
-
微服务技术
微服务将应用程序开发为一系列小型服务的体系结构，每个服务都实现独立的业务功能，运行在自己的进程中，并通过HTTP API或消息传递进行通信。每个微服务都可以独立于应用程序中的其他服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分，能够在不影响最终用户的情况下频繁更新现场应用程序。
值得一提的是，微服务领域有一个著名的“康威定律”：设计系统的组织、最终产生的设计等同于组织之内、之间的沟通结构。这意味着设计系统的企业生产的设计等同于企业内的沟通结构。下图形象地说明了这一概念，展现了企业现有沟通结构。简单地说，企业结构等于系统设计。 -
DevOps
DevOps技术通过自动化软件交付和架构变更的流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
可以把 DevOps 看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。传统的软件组织将开发、IT运营和质量保障（OA）设为各自独立的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发）是一个重要的课题。按照从前的工作方式，开发和部署不需要IT部门支持或者QA跨部门的支持，而现在却需要极其紧密的多部门协作。DevOps考虑的还不只是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。需要频繁交付的企业可能更需要了解DevOps。如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。
DevOps的引入对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”。例如运营人员要求更好的可靠性和安全性，开发人员希望基础设施响应更快，而业务人员的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
以下几方面因素可能促使一个组织引入DevOps：
- 使用敏捷或其他软件开发过程与方法；
- 业务负责人要求加快产品交付的速度；
- 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍；
- 数据中心自动化技术和配置管理工具的普及。
DevOps 经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随而来的生产环境的风险也得到降低。
DevOps的落地实现需要通过一套集成的工具链，具体包括以下目标： - 开发、交付和运维工具之间的实时协作；
- 实现从需求获取和需求评审到设计和代码分析的持续规划；
- 落实测试策略以实施持续测试；
- 当成功完成代码签入后，通过自动触发构建持续集成；
- 测试自动化脚本可以按照作业计划执行，实现持续交付；
- 通过报告和仪表板持续监测程序发布质量；
- 可通过自动化的缺陷识别和解决方案，帮助用户快速响应变更；
- 可以提供基于关键绩效指标（KPI）的有价值的报告，以便用户快速做出决策；
- 通过跟踪发布流水线实现持续交付。
- 持续集成与持续交付技术
持续集成是一种软件开发的实践方法，它要求团队成员经常整合他们的工作成果（通常是程序代码）。通常情况下，团队成员中的每人每天至少提交一次自己的代码到代码仓库做集成构建，这样对于整个项目而言，每天就会有多次集成构建。每次构建都自动集成，这个过程通常还包括通过测试用例进行验证，以尽快检测构建错误。实践证明，许多团队都发现这种方法可以显著减少软件的构建错误，并且可以让团队更快速地交付整体软件功能。
持续交付是一种以可持续的方式安全快速地将所有类型的软件变更（包括新功能开发、配置更改、Bug修复等）转化为生产环节下的工作产品交付给用户直接使用的软件过程控制方法，它的最终目标是将变更直接部署到生产环境。即使面对大规模分布式系统、复杂的生产环境或是嵌入式系统的开发，以及平时软件的日常维护，持续交付都可以有条不紊地进行，在这个过程中，可以确保程序代码始终处于可部署状态。所以，即使是面对每天都需要进行软件开发和维护的数千名开发人员的大团队，也可以做到有条不紊地系统作战，这就完全消除了传统上必须遵循的按部就班的僵化开发流程。 - 容器技术
容器技术与虚拟机技术相比，拥有更高的资源使用效率，因为它并不需要为每个应用分配单独的操作系统，所以实例规模更小、创建和迁移速度也更快。相对于虚拟机，单个操作系统能够承载更多的容器。云提供商十分热衷于容器技术，因为在相同的硬件设备中，可以部署数量更多的容器实例。此外，容器易于迁移，但是只能迁移到具有兼容操作系统内核的其他服务器当中，这样就给迁移选择带来限制。因为容器不像虚拟机可对内核或者虚拟硬件进行打包，所以每套容器都拥有自己的隔离化用户空间，从而使得多套容器能够运行在同一主机系统之上。正因为创建和销毁容器的开销低，所以容器成为部署单个微服务的理想计算工具。
容器化最大的好处是保持运行环境的一致性，只要应用可以打包成容器镜像（通常使用 Docker容器），就可以一次编译后，在各处运行。
同时，容器也可以作为应用运行的最小组件来部署，且更适合作为无状态应用运行。结合容器编排工具（如Kubernetes）将大大增强系统的扩展性和自愈能力，轻松应对大流量下的高并发场景，加快业务的迭代速度。Kubernetes作为CNCF（云原生计算基金会）成员的核心，本身就是与云原生应用的理念紧密结合的产物。
综上，我们可以归纳出云原生的三个主要目标：
- 充分利用云计算技术的优势：采用云端优先策略，从云服务中获取最大价值；
- 实现快速、敏捷、频繁的交付模式；
- 通过技术创新更多地扩展云计算技术的边界。
云原生中包含的不同思想，与其所解释的云上应用架构应该具备的特性几乎是一一对应的： - DevOps、持续交付对应更快的上线速度，即敏捷性；
- 微服务对应可扩展性及故障可恢复性；
- 敏捷基础设施实现了扩展能力的资源层支持；
- 康威定律在组织结构和流程上确保架构特性能够快速实施。
实际上云原生应用架构应该适用于任何应用类型。云原生应用架构适用于异构语言的程序开发，不仅仅是针对Java 语言。目前云原生应用生态系统已经初具规模，CNCF成员不断发展壮大，基于Cloud Native的创业公司不断涌现，Kubernetes引领容器编排潮流和Service Mesh技术，Go语言的兴起等，这些都为将传统应用迁移到云原生架构提供了更多的选择。
云原生应用开发的原则
云原生的开发范式是软件开发演进的一种新型范式，它不仅仅是将应用程序迁移和移植到云平台上运行，更加关注如何利用云计算并最大限度地发挥其优势。为了实现这一目标，在生产和开发过程中，软件开发相关的部门都需要认真关注如何使用云服务，进而关注并实践如何构建云原生应用。综合前面章节的内容，可以归纳云原生应用开发的几项原则。
- 原则1：云服务优先策略
原则：云服务优先策略（Cloud-First）。
描述：在评估技术解决方案中的服务或组件时，首先要考察目前市面上是否有可用的云服务功能，并优先考虑使用最适合用户需求的云服务。
理由：将需要自己负责全新开发的软件模块数量降到最低、最合理水平。例如可以直接利用云端的应用程序平台、数据库、持续集成、持续交付、数据分析服务、缓存服务、负载平衡服务等云服务功能，开发团队仅围绕这些服务构建定制化的软件，将主要的开发精力聚焦在业务功能的实现上。
参考建议：
云原生的服务应该部署在云端，除非受限于一些特殊的环境因素，如安全、合规问题，或者受限于特殊的网络、集成需求问题。
SaaS适用于一些大中型应用功能，同时也支持自定义和个性化设置，这一点相对于版权许可软件来说更具灵活性。
必须权衡考虑版权许可软件和开源软件。 - 原则2：基础设施即代码
原则：基础设施即代码（Infrastructure as Code，IaC）。
描述：以处理应用程序代码相同的方式来管理基础设施配置以及工作流的定义。
理由：通过 API 的方式来构建环境，提供管理和执行运行环境工作流的工具，这使得环境配置可以视为软件功能的一部分。通过管理环境配置代码和应用程序代码，可以获得更好的总体配置管理体验。整个运行时环境都可以用版本化的方式进行管理。
参考建议：
需要使用支持IaC的工具；
需要为应用软件及其运行环境编写相应的测试脚本；
环境的准备和配置不可以通过手动操作的方式进行。 - 原则3：敏捷交付
原则：敏捷交付（Agile Delivery）。
描述：在交付过程的各个阶段争取敏捷，包括开发前的项目启动和计划阶段，以及开发后发布管理和运维管理阶段。
基本原理：敏捷软件开发过程通常能使产品更快地投入生产，但如果开发过程控制过于死板，项目开发就无法敏捷，只有力争各个阶段保持敏捷，才可以最大限度地提高效益。
理由：
前期开发规划应充分考虑项目迭代周期与开发交付周期之间的呼应关系，使软件的开发过程适应敏捷开发的过程控制方式。
必须设定一个初始交付目标，这个交付物必须是可以运行的工作成果。
随着业务目标的调整，对于开发过程中的需求变更应该抱有开放的态度，拥抱变化。
开发团队和运维团队紧密合作，力求做到频繁发布，充分采用DevOps的开发理念。
快速试错，避免冗长的QA测试环节，最大程度地降低交付风险。 - 原则4：自动化交付原则
原则：自动化交付原则（Delivery Automation）。
描述：力求在开发运维过程中做到从构建到发布的全自动化。
理由：实现软件构建、环境准备、测试和部署的自动化能力可以使得产品在加速市场化的过程中占据绝对的优势。
参考建议：
这个原则建立在前面的基础设施即代码的原则之上。
自动化测试工具是必需的。
“快速试错”的方法是为了加快部署和自动化生产。
应该设计一个监控系统和回滚计划，以便快速检测和回退有问题的版本，而不用等待错误修复。 - 原则5：基于服务架构
原则：基于服务架构（Service-Based Architecture）。
描述：必须按照既定的项目目标和期望的特点来遵循各种形式的基于服务的体系结构（SBA）。
理由：所有形式的基于服务的体系结构都有其优点，应该加以利用。
虽然在选择一种具体的形式时需要权衡，但应该考虑和评估各种服务形式，为给定的解决方案确定最合适的架构方法。
参考建议：
为了确定基于服务的体系结构最适合的应用，在软件开发生命周期的早期就需要进行一些分析。
所有形式的SBA都要求按API的规范化开发。
应采用API优先开发战略。
需要考虑API的接口风格的标准化。
需要考虑API的接口的安全性，并采取相应的措施保障API不暴露给不安全或不受信的网络。 - 原则6：12要素应用
原则：12要素应用（Twelve-Factor Applications）。12要素如图所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SUgnF8j5-1648698704363)(http://image.huawei.com/tiny-lts/v1/images/3f8b45b8783da32c8aa8b70690a14a1e_413x438.png@900-0-90-f.png ““12要素”的内容”)]
描述：遵循最佳实践（如12要素应用原则），开发云原生应用程序。
理由：一些组织多年来一直致力于开发云原生应用程序，并开始记录最佳实践，需要吸取别人的教训，并在适当的时候采取最佳作法。
参考建议：
构建过程，发布过程和配置管理实践可能受某些最佳实践的影响。
一些最佳实践会影响应用程序的部署和管理方式，因此可能有必要查看运营团队成员的最佳实践。
扫一扫
3633
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
