微服务架构

微服务架构将应用拆分为一系列可独立部署的服务，并通过 API 进行通信。这样，每个服务都可单独部署和扩展。这种方法允许快速、频繁地交付庞大且复杂的应用。与单体式应用不同，微服务架构允许团队更快地实施新功能并进行更改，并且大部分现有代码均无需重写。

举例来说，有一个电子商务软件项目。下图所示的电子商务站点包含与多个微服务交互的 Web 应用和移动应用，且每项微服务都为一个领域提供特定的功能。

现代 Web 应用在浏览器中运行，且通常由内容分发网络 (CDN) 提供。CDN 的优势在于可将 Web 应用分发到世界各地的服务器，让 Web 浏览器提供快速下载。CDN 还用于提供图像、音频和视频等媒体资产。例如，在此系统中，在售商品的图像和视频由 CDN 提供。

应用通过各个微服务发布的 REST API 与微服务进行交互。API 网关允许应用依赖微服务所提供的 API，也允许将这些微服务交换为使用相同 API 的其他微服务。

每项微服务均由服务和数据库构成。这些服务负责处理 REST API、实现业务逻辑，并将数据存储在数据库中。对于微服务，我们按照 12 Factor App 协定将它们的资源（如数据库和队列）彼此分离。

对于许多组织而言，从单体式架构开始是第一步。然后需要将代码库拆分为多个服务，实现正确的模式以允许优雅降级并从网络问题中恢复，处理数据一致性，以及监控服务负载等。但这仅仅是从技术层面而言。此外，您需要重组团队，并且很有可能要实施 DevOps 文化。

而后才是棘手的部分：您需要将单体式分解为微服务。重构单体式数据库架构可能是一项精细操作。明确每个服务需要哪些数据集和所有重叠之处非常重要。持续交付有助于降低发布失败的风险，并确保您的团队专注于构建和运行应用，而不是受困于应用部署。

单体式架构是一种传统的软件程序模型，它作为独立自主且不依靠其他应用的统一单元来构建。微服务架构就像单体式架构的对立面，因为它是一种依赖于一系列可独立部署服务的架构方法。在项目早期阶段，单体式架构在代码管理、认知开销和部署等方面非常有利。一旦单体式应用变得庞大而复杂，其扩展就会变得困难，持续部署变得棘手，而且更新可能也会很麻烦。

单体式应用是作为单个不可分单元来构建的，而微服务则将该单元分解为一系列独立单元，从而为更大的整体做贡献。应用则是作为一系列可独立部署、去中心化且能自主开发的服务而构建的。

微服务属于分布式系统的范畴。根据定义，分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。分布式系统有助于提高系统的可靠性和性能，并可实现轻松扩展。

分布式系统中的节点提供冗余能力，如有节点出现故障，其他节点可以替换该故障节点。每个节点都可水平和垂直扩展，从而提升性能。如果系统负载过大，可以添加额外节点来帮助消化负载。

Docker 是一种商业容器化平台和运行时环境，它可帮助开发人员构建、部署和运行容器。虽然 Docker 提供了一种高效方式来打包和分发容器化应用，但仅使用 Docker 来实现大规模运行和管理容器仍面临挑战。

Kubernetes 是一个广受欢迎的开源平台，可以跨越网络资源集群来编排容器运行时系统。它可与 Docker 搭配使用，亦可独立使用。Docker 是一个容器运行时环境，Kubernetes 则是一个用于通过众多容器运行时环境来运行和管理容器的平台。

软件配置管理是对软件系统配置元数据所做的更改进行管理、组织、跟踪和监视的过程。通常与版本控制和 CI/CD 基础架构一起使用。

配置管理通过使用自动管理和监控配置数据更新的工具，帮助工程团队构建强大而稳定的系统。通过创建具有中心配置位置的“数据源”，有助于更好地管理微服务架构中杂乱无章的软件。