整体体系结构和微服务体系结构
Fabrikam 将其新的无人机服务集成到了其现有应用程序中。 他们意识到，这一解决方案不是适用于其应用程序的良好的长期计划。 现有系统采用整体体系结构，但这到底意味着什么？
什么是整体体系结构？
整体体系结构是指应用程序的所有组件都位于单个单元中。 此单元通常在应用程序的单个运行时实例中受到约束。 传统应用程序通常包含 Web 界面、服务层和数据层。 在整体体系结构中，这些层都合并在应用程序的一个实例中。
整体体系结构通常是适用于小型应用程序的解决方案，但随着应用程序的增大，它们可能会显得过于庞大。 最初的小型应用程序可能快速发展成为难以缩放、难以部署和难以创新的复杂系统。
所有服务都包含在一个单元中。 随着业务和后续系统负载的增长，这一安排带来了挑战。 其中一些挑战如下：
- 难以独立缩放服务。
- 随着代码库的扩大，开发和管理部署会非常复杂，这会减慢发布和新功能实现的速度。
- 该体系结构与单个技术堆栈捆绑，这会限制新平台和 SDK 中的创新。
- 数据架构更新可能越来越困难。
这些挑战可通过了解微服务体系结构等替代体系结构来加以解决。
什么是微服务体系结构？
微服务体系结构中所包含的服务具有规模小、独立和松散耦合的特点。 可以单独对每个服务进行部署和缩放。
微服务很小，一个小规模的开发人员团队就能编写和维护微服务。 由于可独立部署服务，因此团队可以更新现有服务，而无需重新生成和重新部署整个应用程序。
每个服务通常负责其自己的数据。 其数据结构是独立的，因此架构升级或更改不依赖于其他服务。 数据请求通常通过 API 处理，并提供定义完善的一致访问模型。 内部实现细节均对服务使用者隐藏。
由于每个服务都是独立的，因此可使用不同的技术堆栈、框架和 SDK。 常见的情况是，通过使用定义完善的 API 而不是远程过程调用 (RPC) 或其他自定义通信方法，服务依赖于 REST 调用来进行服务到服务的通信。
微服务体系结构与技术无关，但通常会看到用于其实现的容器或无服务器技术。 持续部署和持续集成 (CI/CD) 经常用于提高开发活动的速度和质量。
微服务体系结构的优势
为什么要选择微服务体系结构？ 微服务体系结构具有几个主要优势：
- 敏捷性
- 小代码，小团队
- 混合技术
- 复原能力
- 可伸缩性
- 数据隔离
敏捷性
由于微服务是独立部署的，因此我们可以更轻松地管理 bug 修复和功能发布。 无需重新部署整个应用程序即可更新服务，出现问题时可回滚更新。 在许多传统的应用程序中，如果在应用程序的一个部分中发现 bug，就会阻止整个发布过程。 因此，新功能可能会被搁置，等待集成、测试和发布 bug 修复。
小代码，小团队
微服务应该足够小，单个功能团队就能对它进行构建、测试和部署。 小型代码库更易于理解。 在大型整体应用程序中，随着时间的推移，代码依赖关系往往会变得混乱。 添加新特性需要在很多地方修改代码。 通过不共享代码或数据存储，微服务体系结构将依赖关系减到最少。 这会使新功能的添加变得更容易。
小型团队的规模也能大幅提升敏捷性。 “两块披萨的原则”是指团队的规模应该足够小，两块披萨就能让他们吃饱。 显然，这并不是一个确切的指标，因为食量还取决于团队成员的胃口！ 但要点在于，大型团队的工作效率往往更低，因为沟通效率较低，管理开销上升，敏捷性下降。
混合技术
团队可选取最适合其服务的技术。 他们可以根据需要使用混合的技术堆栈。 每个团队都可独立改进支持其服务的技术。 由于这种独立性，服务可以使用不同的开发语言、云服务、SDK 等。 团队可为其服务选择最佳选项，同时将对服务使用者的任何外部影响降到最低。
复原
单个微服务在不可用的情况下不会中断整个应用程序，但前提是所有上游微服务能够正确处理故障（例如，通过实施断路机制）。 为应用程序创造始终可用的体验，这会使用户或服务使用者受益。
可伸缩性
微服务体系结构允许每个微服务独立进行缩放。 可以横向扩展需要更多资源的子系统，而无需横向扩展整个应用程序。 这种安排可以提高应用程序的整体性能。 并且还有助于最大程度地降低成本。 可以将更多资源仅添加到需要资源的服务，而不是纵向扩展整个应用程序。
数据隔离
微服务体系结构可改善数据架构更新的执行能力，因为只会影响单个微服务。 在整体应用程序中，架构更新可能会变得具有挑战性。 应用程序的不同部分可能会接触到相同的数据，这使得对模式的任何更改都会产生风险。 使用微服务体系结构，可以更新架构，但保持 API 表面不变。 无论基础数据体系结构如何，服务使用者都会有相同的体验。
微服务体系结构的潜在挑战
微服务体系结构有很多好处，但它不是万能的。 微服务架构有其自身的一系列挑战：
- 复杂性
- 开发和测试
- 缺乏监管
- 网络拥塞和延迟
- 数据完整性
- 管理
- 版本控制
- 技能集
复杂性
与同等的整体应用程序相比，微服务应用程序具有更多移动部件。 每个服务更简单，但整个系统从整体来看更为复杂。 利用服务发现、业务流程和自动化工具，整个应用程序中有更多要管理的部分。
开发和测试
编写依赖于其他依赖服务的小型服务，需要不同于编写传统的整体或分层应用程序所采用的方法。 现有工具的设计目标并不总是处理这些服务依赖关系。 跨服务边界进行重构可能很困难。 测试服务依赖关系也有一定难度，尤其是在应用程序快速发展时。
缺乏监管
用于生成微服务的分散式方法具有一定优势，但也可能导致许多问题。 用户在生成过程中可能采用了许多不同的语言和框架，从而使应用程序变得难以维护。 设置一些项目范围的标准可能较为有用，同时不过分限制团队的灵活性。 需要统一标准尤其适用于日志记录和指标等跨领域功能。
网络拥塞和延迟
使用大量小型的精细服务可能会增加服务间的通信量。 如果服务依赖关系链变得过长（例如，服务 A 调用 B，B 调用 C...），则这些网络调用的额外延迟可能会成为一个问题。 精心设计 API。 应避免过于繁琐的 API，考虑使用序列化格式，并找到可以使用异步通信模式的位置。
数据完整性
每个微服务负责其自己的数据暂留。 因此，数据一致性可能是个挑战。 如果可能，应采用最终一致性。 还可能最后获得重复的数据和庞大杂乱的数据体系结构。 这种情况会提高原始存储成本，以及针对服务和数据重复的数据平台服务成本。
管理
成功使用微服务需要成熟的 DevOps 经验。 跨服务的关联日志记录可能很难。 通常情况下，日志记录必须关联多个服务调用才能用于单个用户操作。
版本控制
对某个服务的更新不应中断依赖于它的其他服务。 可在任意给定时间更新多个服务。 若不精心设计，可能会遇到向后或向前兼容性问题。 未采用新 API 版本的服务可能会增加旧 API 所需的资源和维护。
技能集
微服务是高度分布式的系统。 这些分布式系统通常需要不同的技能集来正确地进行开发、管理和维护。 请仔细评估团队是否具有成功使用微服务所需的技能和经验。 请留出团队提高能力所需的时间并作出计划。
何时应选择微服务体系结构？
基于对背景信息的了解，那么微服务体系结构最适用于哪些情况呢？
- 需要较高发布速度的大型应用程序。
- 需要高度可扩缩的复杂应用程序。
- 具有多个域或多个子域的应用程序。
- 具有小型开发团队的组织。