克服微服务采用挑战

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

微服务架构可能是一个颠覆性的改变，它可以帮助组织减少应用现代化和云迁移过程中的障碍，并让他们在竞争中抢占先机。一个微服务架构根据用例或功能将业务领域解耦为各自独立的服务，同时通过 API 保持所有服务之间的通信畅通。每个领域通常都有自己独立的开发团队，负责创建、管理、测试和部署服务，独立于所有其他领域。由于每个服务都有自己的发布周期，这可以加快产品上市时间。

这里有一个实际世界的例子

考虑航空业，各种业务领域通过众多应用交换实时数据。这些业务领域（你可以将其视为部门）可能包括预订系统、行李处理和乘客值机系统。如果 Joe Smith 购买了一张从亚特兰大到迈阿密的机票，该信息会进入预订系统。当 Joe Smith 在航班当天在机场自助值机亭办理值机时，该数据可以随时检索。当 Joe 将行李交给航空公司时，另一个完全独立的部门（独立于预订和值机服务）会确保 Joe 的行李在他抵达迈阿密时也随之抵达。

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

微服务挑战

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

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

当功能被分解成数百或数千个独立的领域时，团队自治可能会引入大量的不同 SLA、工具和各种人力资源，用于在数据层对每个领域进行故障排除和妥善管理。

如何在一个分布式系统中理清所有这些不同的工具，而又不破坏隔离性？答案在于有效利用一个数据平台进行缓存，该平台支持最佳数据模型，并提供轻量级的消息代理用于服务间通信。这可以提高开发人员的工作效率，加快产品上市时间，并总体上简化应用程序的架构。

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

对于所有服务来说，与共享数据保持最佳一致性至关重要，无论你是在一个微服务中使用写优化的记录系统数据库，还是在另一个服务中使用读优化的缓存。你需要实现命令查询职责分离 (CQRS) 模式，以实现亚毫秒级查询延迟的跨领域数据访问。如果微服务实例分布在全球多个数据中心，则需要对读取数据进行 Active-Active 地理复制才能扩展和维护可用性。

延迟：延迟可能来自各个方面。每个新的领域或组件都可能增加性能故障的风险，因为服务之间不断增长的 API 调用数量会不断升级并导致不希望出现的延迟。

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

一个微服务中数据流的单个瓶颈可能会导致系统范围的崩溃，特别是如果它是 API 网关上的全局数据。API 网关不能成为导致系统停机、用户不满和你绝不想看到的头条新闻的单点故障。

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