《Spring Cloud微服务架构进阶》——1.3　云原生与微服务

1.3　云原生与微服务

提及云原生，首先需要了解一下CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多个企业与机构，包括亚马逊、微软、思科等巨头。目前CNCF所托管的应用已达14个，知名的项目有Kubernetes、Prometheus、Envoy等。

1.云原生

CNCF宪——章中给出了云原生应用的三大特征，概括如下：

容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。

动态管理：通过集中式的编排调度系统来动态管理和调度。

面向微服务：明确服务间的依赖，互相解耦。

云原生包含了一组应用的模式，用于帮助企业快速、持续、可靠、规模化地交付业务软件。如图1-7所示，云原生由微服务架构、DevOps和以容器为代表的敏捷基础架构组成。

图1-7　云原生的组成

2. 12原则

12原则（12-Factors）经常直译为12要素，12原则由公有云PaaS的先驱Heroku于2012年提出（https://12factor.net/），目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。12原则包括：

基准代码。

显式声明依赖关系。

在环境中存储配置。

把后端服务当作附加资源。

严格分离构建、发布和运行。

无状态进程。

通过端口绑定提供服务。

通过进程模型进行扩展。

快速启动和优雅终止。

开发环境与线上环境等价。

日志作为事件流。

管理进程。

另外还有补充的三点：API声明管理、认证和授权、监控与告警。

12原则提出来已有六年多，12原则的有些细节可能已经不那么跟得上时代，也有人批评12原则的提出从一开始就有过于依赖Heroku自身特性的倾向。不过不管怎样，12原则依旧是业界最为系统的云原生应用开发指南。

3.容器化

Docker是一个开源引擎，可以轻松地为任何应用创建一个轻量级的、可移植的、自给自足的容器。最近几年Docker容器化技术很火，在各种场合都能够听到关于Docker的分享。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker根本的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了Docker的机器上运行，而不用关心底层操作系统。

Docker可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括：

隔离应用依赖。

创建应用镜像并进行复制。

创建容易分发的、即启即用的应用。

允许实例简单、快速地扩展。

测试应用并随后销毁它们。

虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下，结合使用Docker显然能带来更多的好处。

一旦拥抱了容器，这就需要一个编排框架来调度和管理容器。最常见的编排框架有Kubernetes、Mesos、Docker Swarm。编排框架是容器平台的关键组成部分。

4. DevOps

DevOps是软件开发人员（Dev）和IT运维技术人员（Ops）之间的合作，目标是自动执行软件交付和基础架构更改流程，使得构建、测试、发布软件能够更加地快捷和可靠。它创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件。通过DevOps流水线加上Docker容器，可以实现自动化工程管理，实现开发、测试环境的自动申请和构建。通过Docker标准化打包应用配置和环境，可以生成轻量容器镜像，并使用镜像方式迭代开发、测试、部署，加速应用上线。自动化运维在合理保障应用高可用的前提下，能够提升资源利用率，降低成本。

DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”，例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。

5.微服务

微服务将单体业务系统分解为多个可独立部署的服务。这个服务通常只关注某项业务，或者最小可提供业务价值的“原子”服务单元。

微服务架构有以下优势：

当人们将业务领域分解为可独立部署的环境时，能够将相关的变更周期解耦。只要变更限于单一有限的环境，并且服务继续履行其现有合约，那么这些变更可以独立于与其他业务来进行和部署。其结果是实现了更频繁和快速的部署，实现了持续的价值流动。

扩展更多的部署组件本身可以加快部署。在原本的单体应用中，由于沟通和协调的开销，在添加更多的人手时，往往会使软件开发流程变得更长。《人月神话》的作者弗雷德里克·布鲁克斯很多年前就教导我们，在软件项目的晚期增加更多的人力往往会使软件项目更加延期。但是在微服务架构中可以在有限的环境中构建更多的沙箱，而不是将所有的开发者都放在同一个沙箱中。由于学习业务领域和现有代码的负担减少，并且团队较小，因此添加到每个沙箱的新开发人员可以更快速地提高并使得工作变得更高效。

可以加快采用新技术的步伐。大型单体应用程序架构通常与对技术堆栈的长期保证有关。这些保证的存在是为了减轻采用新技术的风险。技术选型的错误在单体架构中的代价非常昂贵，因为这些错误可能会影响整个企业架构。如果可以在单个服务的范围内采用新技术，就将隔离并最大限度地降低风险，就像隔离和最小化运行时故障的风险一样。

微服务提供独立、高效的服务扩展。单体架构也可以扩展，但要求我们扩展所有组件，而不仅仅是那些负载较重的组件。当且仅当相关联的负载需要它时，才缩放微服务。