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