远程通信|「微服务架构」微服务集成中的3个常见缺陷-以及如何避免它们微服务风靡一时。他们有一个

文章插图
微服务风靡一时。他们有一个有趣的价值主张，即在与多个软件开发团队共同开发的同时，将软件快速推向市场。因此，微服务是在扩展您的开发力量的同时保持高敏捷性和快速的开发速度。
简而言之，您将系统分解为微服务。分解并不是什么新鲜事，但是通过微服务，您可以为团队提供尽可能多的自主权。
【远程通信|「微服务架构」微服务集成中的3个常见缺陷-以及如何避免它们】例如，专用团队完全拥有该服务，可以随时部署或重新部署。他们通常也会使用devops来控制整个服务。他们可以做出相当自主的技术决策并运行他们自己的基础设施数据库。被迫操作软件通常会限制有线技术选择的数量，因为当人们知道他们将来必须操作它时，往往会更频繁地选择无聊技术。
文章插图
Microservices are about decomposition, but giving each component a high degree of autonomy and isolation (微服务是关于分解，但为每个组件提供高度自治和隔离)
微服务架构的一个基本结果是每个微服务都是与其他微服务远程通信的独立应用程序。这使得微服务环境成为高度分散的系统。分布式系统有其自身的挑战。在本文中，我将向您介绍我在最近的项目中看到的三个最常见的陷阱。
1.沟通很复杂远程通信不可避免地要尊重分布式编程的8个谬误。隐藏复杂性是不可能的，并且许多努力（例如Corba或RMI）已经失败了。一个重要原因是您必须在服务中设计失败，以便在失败是新常态的环境中取得成功。但是有一些共同的模式和框架可以帮助你。让我们从一个例子开始 - 我经常遇到的真实情况。
我想飞往伦敦。当我收到办理登机手续的邀请时，我去了航空公司的网站，选择了我的座位，然后按下按钮取回我的登机牌。它给了我以下回应：
文章插图
让我们假设航空公司使用微服务（可能不是这种情况，但我知道有其他航空公司这样做）。
文章插图
我注意到的第一件事：错误返回得相当快，网站的其他部分表现正常。所以他们使用了重要的失败快速模式。条形码生成中的错误不会影响整个网站。我可以做其他一切;我无法获得登机牌。快速失败非常重要，因为它可以防止本地错误导致整个系统崩溃。该领域众所周知的模式是断路器，隔板和维修网。这些模式对分布式系统的生存至关重要。
快速失败是不够的
但快速失败是不够的。它将故障处理卸载到客户端。在这种情况下，我个人不得不重试。在上述情况下，我甚至要等到第二天，直到问题得到解决，我才能拿到登机牌！对我而言，这意味着我必须使用自己的工具来坚持重试（我的日历），以确保我没有忘记。
文章插图
为什么航空公司不自行重试？他们知道我的联系数据，并且可以在准备好时异步发送登机牌。更好的反应是：
文章插图
这不仅会更方便，而且还会降低总体复杂性，因为需要查看故障的组件数量会减少：
文章插图
您可以将相同的原则转移到服务到服务通信。每当服务本身可以解决故障时，它就会封装重要的行为。这使得所有客户的生活更加轻松， API更加清洁。解决故障可能是有状态的（有些人称之为长时间运行）。我认为状态处理是微服务中故障处理的关键问题。
当然，上面描述的行为并不总是你想要的，将故障移交给客户端就可以了。但这应该是根据业务需求做出的有意识的决定。
我观察到大多数情况下，另一个原因导致人们避免有状态重试：它伴随着状态处理的复杂性。该服务必须重试几分钟，几小时或几天。它必须可靠地执行此操作（请记住：即使系统重新启动，我也希望登机牌），这涉及处理持久状态。
如何管理持久状态？
我看到两种处理持久状态的典型方法：
存储在数据库中的实体等持久性事物。