克服微服务采用挑战

对复杂性、最终一致性和延迟的担忧：所有这些都可能让那些刚开始采用微服务的人产生疑虑。我们的解决方案简报，《微服务的缓存和消息代理》，重点介绍了可以帮助您解决这些常见障碍的设计模式。

微服务架构可以成为改变游戏规则的力量，帮助组织降低组织应用程序现代化和云迁移之旅的障碍，并让他们在市场竞争中领先。一个微服务架构将业务领域分解成各自的服务，这些服务依赖于用例或功能，同时通过 API 保持所有服务之间的通信畅通。每个领域通常都有自己的自主开发团队，他们独立于所有其他领域创建、管理、测试和部署服务。这使得每个服务都有自己的发布周期，从而加快了上市速度。

这是一个现实世界的例子

以航空业为例，航空业通过众多应用程序在各种业务领域之间交换实时数据。业务领域（您可以将它们视为部门）可能包括预订系统、行李处理和旅客值机系统。如果 Joe Smith 从亚特兰大购买了飞往迈阿密的机票，该信息将进入预订系统。在 Joe Smith 乘坐航班当天在机场自助值机机上办理值机手续时，可以轻松检索该数据。当 Joe 将行李交给航空公司时，另一个部门（与预订和值机服务分开）确保 Joe 的行李在到达迈阿密时与他一起到达。

每个领域都有自己的企业工具和资源，并且可能使用独特的技术栈或数据库平台。一个微服务可能使用 Java 和 NoSQL JSON 文档存储；另一个服务可能使用在 COBOL 和关系数据库上运行的旧式大型机系统。所有这些分布式服务都通过 API 网关连接，该网关使航空公司能够构建调用来自多个来源（如机场自助值机机、预订网站和行李处理）数据的应用程序。关键在于：所有这些解耦的服务都可以通过 API 实时访问相同的数据。

微服务挑战

哪些挑战阻碍了微服务更广泛的采用？尽管解耦架构有许多好处，但为什么并非所有公司都在进行切换？

复杂性：最终，将每个可行的领域从单体架构分散到微服务中几乎总是会创建一个更复杂的系统。正如有人在我们5 个微服务误解帖子中评论的那样，“公司认为他们可以通过微服务消除复杂性。但你并没有真正消除复杂性，你只是将其移动到一个不同的抽象层。”

当功能被分散到数百甚至数千个隔离的领域时，团队自主权会在数据层引入大量不同的 SLA、工具和各种人员来解决问题并正确管理每个领域。

如何在不破坏隔离的情况下在一个分布式系统中解开所有这些不同的工具？答案在于有效地使用一个用于缓存的数据平台，该平台支持最佳数据模型并为服务间通信提供轻量级消息代理。这增强了开发人员的生产力，缩短了上市时间，并通常简化了应用程序的架构。

最终一致性：在分布式系统中维护强一致性极其困难。尽管微服务架构中的领域必须解耦，但团队需要维护最新的数据，即使这些数据分布在全球各地。

所有服务都必须保持与共享数据的最佳一致性，无论您是处理一个微服务中的系统记录写入优化数据库还是另一个服务中的读取优化缓存。您需要实现命令查询责任分离 (CQRS) 模式，以提高跨域数据访问，并以亚毫秒级的查询延迟。如果微服务实例分布在世界各地的多个数据中心，则需要对读取数据进行主动-主动地理复制以扩展并保持可用性。

延迟：延迟可能来自各个方面。每个新领域或组件都会增加性能失败的风险，因为随着服务之间 API 调用的数量不断增加，它们可能会升级并发展成不必要的延迟。

理想情况下，如果您遵循使用最佳数据库为每个微服务进行域驱动设计原则，延迟就不会成为问题。但是，由于技术债务限制或监管原因，在某些行业中，需要在特定微服务中使用遗留数据库。但是，这些应用程序无法满足性能 SLA。缓存可以提供这些查询响应时间，并且设置它只需要最少的开发时间。

一个微服务中数据流中的单个瓶颈会导致整个系统崩溃，尤其是在 API 网关处进行全局数据处理时。API 网关不能成为导致系统停机、用户恼怒和您真正不想看到的新闻头条的单点故障。

为了优化持久性、一致性和读取性能，您的应用程序需要一个强大的缓存和速率限制解决方案，用于 API 网关。