微服务很受欢迎。他们有一个有趣的价值主张，即在与多个软件开发团队共同开发的同时，快速将软件推向市场。因此，微服务是为了扩大您的开发力量，同时保持高灵活性和快速的开发速度。
简而言之，您将系统分解为微服务。分解并不新鲜，但通过微服务，您可以为团队提供尽可能多的自主权。
比如专用团队完全有这个服务，可以随时部署或者重新部署。它们通常被使用devops控制整个服务。他们可以做出相当独立的技术决策，并运行自己的基础设施数据库。被迫操作软件通常限制有线技术选择的数量，因为当人们知道他们必须在未来操作它时，他们会更频繁地选择无聊的技术。
Microservices are about decomposition, but giving each component a high degree of autonomy and isolation (微服务是关于分解的，但为每个组件提供高度的自治和隔离)
微服务架构的一个基本结果是，每个微服务都是与其他微服务远程通信的独立应用程序。这使得微服务环境成为一个高度分散的系统。分布式系统有自己的挑战。在本文中，我将向您介绍我在最近的项目中看到的三个最常见的陷阱。
1.沟通很复杂
远程通信不可避免地要尊重分布式编程的八个谬误。隐藏复杂性是不可能的，而且很多努力(比如Corba或RMI）失败了。一个重要的原因是你必须在服务中设计失败，这样你才能在失败的新常态环境中取得成功。但是有一些共同的模式和框架可以帮助你。让我们从一个例子开始 - 我经常遇到的真实情况。
我想飞往伦敦。当我收到登机手续的邀请时，我去了航空公司的网站，选择了我的座位，然后按下按钮取回登机牌。它给了我以下回应：
假设航空公司使用微服务(可能不是这样，但我知道还有其他航空公司这样做)。
我注意到的第一件事：错误返回得很快，网站的其他部分也很正常。因此，它们采用了重要的快速失败模式。条形码生成中的错误不会影响整个网站。我可以做其他事情；我拿不到登机牌。快速失败非常重要，因为它可以防止整个系统因本地错误而崩溃。断路器、隔板和维修网是该领域著名的模式。这些模式对分布式系统的生存至关重要。
快速失败是不够的
但快速失败是不够的。它将故障卸载到客户端。在这种情况下，我个人不得不再次尝试。在上述情况下，我甚至要等到第二天，直到问题解决，我才能拿到登机牌！对我来说，这意味着我必须使用我自己的工具来重新测试（我的日历），以确保我没有忘记。
为什么航空公司不自行重试？他们知道我的联系数据，并且可以在准备好时异步发送登机牌。更好的反应是：
由于需要检查故障的组件数量会减少，这不仅会更方便，而且会降低整体复杂性：
您可以将相同的原则转移到服务通信。每当服务本身能够解决故障时，它就会包装重要的行为。这使得所有客户的生活更容易，API更干净。解决故障可能是有状态的(有人称之为长期运行)。我认为状态处理是微服务中故障处理的关键问题。
当然，上述行为并不总是你想要的。将故障移交给客户端。但这应该是根据业务需要做出的有意识的决定。
我观察到大多数情况下，另一个原因导致人们避免有状态重试：它伴随着状态处理的复杂性。该服务必须重试几分钟，几小时或几天。它必须可靠地执行此操作（请记住：即使系统重新启动，我也希望登机牌），这涉及处理持久状态。
如何管理持久状态？
我看到了两种典型的处理持久状态的方法：
存储在数据库中的实体等持久性事物。
虽然这一开始很简单，但它通常会导致许多意想不到的复杂性。您不仅需要数据库表，还需要一些调度程序组件进行重试。您可能需要一些监控组件来查看或编辑等待操作。如果整体业务逻辑发生变化，您仍然需要控制版本，您仍然想重试。
这种想法导致许多开发人员跳过正确的故障处理，导致整个架构的复杂性增加 - 以及糟糕的客户体验。
相反，我建议使用轻量级工作流引擎或状态机。
构建这些引擎是为了保持持久状态，处理流语言、监控和操作的后续要求，扩展以处理高容量等。
市场上有几个轻量级工作流引擎。他们中的许多人使用它ISO标准BPMN来定义流，很多都是开源的。我将在这里使用它Camunda开源工作流引擎解释基本原则（快速免责声明：作为项目背后公司的共同创始人，我显然更喜欢我的工具选择，但这是我最熟悉的工作流引擎）。可以使用上述简单用例Java DSL轻松创建工作流：
另一种选择是在BPMN以图形形式建模工作流程：
这些工作流引擎在结构上非常灵活。许多开发人员认为工作流引擎是一个集中组件，但事实并非如此。没有必要引入集中组件！如果不同的服务需要工作流引擎，每个服务都可以运行自己的引擎来维护服务的自主性和隔离性。本博将详细讨论更多关于结构选项的细节。
另一个误解是，工作流迫使开发人员切换到异步处理。这不是真的。在上述示例中，当一切顺利运行时，登记组件可以同步返回登机牌。只有在出现错误时才会退回异步处理。这很容易反映为HTTP返回码，200说一切正常，这是你的结果，202说得到它，我会给你回电话。有一些具体的示例代码来处理这个，它使用了一个简单的信号。
我认为工作流引擎是工具箱的重要组成部分，用于正确的故障处理，通常涉及长期运行，如状态重试。
2.需要注意异步性
这导致了我们的异步通信，这通常意味着信息传输。异步通常被认为是分布式系统中最好的默认值，因为它提供了解耦，特别是时间解耦，因为任何消息都可以独立于接收器的可用性传输。一旦服务提供商可用，消息将在没有额外魔力的情况下立即发送。
因此，重新测试的问题已经过时，但也会出现类似的问题：你必须担心加班。假设航空公司在注册计划中使用异步通信。注册组件将消息发送到条形码生成服务，然后等待响应。您不需要关心条形码生成器的可用性，因为消息总线将在适当的时间传输。
但是，如果请求或响应因任何原因丢失怎么办？您在办理登机手续时是否会遇到困难，未能在未注意到的情况下将登机牌发送给客户？我打赌很多公司都这样做，这再次导致客户监控响应并采取行动。如果没有登机牌，他们将在加班时间内到达。同样，我必须使用我的个人调度基础设施（日历）。
更好的方法是让服务监控超时本身，并在条形码未能及时到达时执行回退。可能的后备是重新发送消息，这实质上是重试。
您还可以使用工作流自动化技术来处理此用例。BPMN工作流可如下所示：
作为奖励，您可以免费报告重试次数、典型响应时间和无法及时处理的工作流程数量。操作员可以通过提供大量的上下文来轻松检查和修复失败的工作流实例，如信息中包含的数据和发送信息的时间。纯基于信息的解决方案通常忽略了这一级别的可见性和操作控制。
我甚至看到公司在微服务之间使用工作流引擎而不是新闻传输中间件来分配工作。如果工作流引擎不主动调用服务或发送信息(称为推送原则)，但依赖于工作者要求的工作(称为拉取原则)，这是可能的。现在，工作流引擎中的工作队列就像一个新闻队列。当我问他们为什么喜欢工作流引擎时，他们说信息传输解决方案缺乏相同的可见性和工具质量，他们想避免建立自己的操作工具。
3.分布式交易很难
事务是一系列以全有或全无的方式执行的操作。我们都从数据库中知道这一点。你开始一项事务，做一些事情，然后提交或回滚。这些事务被称为ACID：原子，一致，隔离和持久。
你不能指望在分布式系统中ACID事务。是的，有像XA这种协议实现了所谓的两阶段提交。或WS-AtomicTransaction。或像Google Spanner如此复杂的实施。但目前的共识是，这些协议太贵、太复杂或根本无法扩展。Pat Helland超越分布式交易的生活：Apostate意见是一个很好的背景阅读。
但当然，商业交易的要求并没有消失。ACID在这种情况下，解决业务交易的常见技能是使用补偿。这意味着您可以撤销过去所有不正确实施的活动。BPMN它具有内置功能，因此您可以定义这些取消活动，工作流引擎负责以正确的顺序可靠地执行它们。这次我将使用预订机票的例子：
这通常也叫Saga最近，模式变得非常流行。Saga：如何在没有两阶段提交的情况下实现复杂的业务交易”中写到了这一点，其中我还链接了其他来源和一些代码。
请注意，这种方法和ACID事务不同，因为你可以有不一致的中间状态。因此，我可以保留一个座位，但还没有预订有效的机票。或者我可以在没有付款的情况下买票。实际情况是，只要最终清理干净，使系统恢复到一致状态，这些暂时的不一致通常是可以容忍的。这被称为最终一致性，是分布式系统中的一个重要概念。“在SoA拥抱网络中的最终一致性指出它很好：
最终的一致性通常会产生更好的性能、更简单的操作和更好的可伸缩性，并要求程序员理解更复杂的数据模型。
好消息是工作流程自动化简化了补偿处理。这是因为工作流引擎可以可靠地调用所有必要的补偿活动。
服务提供商 - 做好功课！
到目前为止，我已经提出了三种简单的补救措施来应对分布式系
重试
超时
赔偿金
所有这些都可以通过轻量级工作流自动化技术来实现。但为了使用这些配方，每个服务提供商都必须做好家庭作业。这意味着
提供补偿活动和
实现幂等性。
虽然第一个要求应该很明显(如果有取消票证的服务，我只能消票证），第二个 - 幂等性 - 需要更多解释。
幂等
我谈了很多关于重试的事情。一个常见的问题是，如果我通过重试两次调用服务怎么办？这个问题问得好！
首先要确保您了解每种形式的远程通信都会遇到此问题！无论何时通过网络进行通信，都无法区分三种故障情形：
该请求尚未到达提供商
请求已到达提供商，但在处理期间它已爆炸
提供程序处理了请求，但响应丢失了
一种可能性是询问服务提供商是否已经看到此请求。但更常见的方法是使用重试并以允许重复调用的方式实现服务提供程序。这更容易设置。
我看到两种简单的方法来掌握幂等性：
自然的幂等性。有些方法可以随意执行，因为它们只是翻转一些状态。示例：confirmCustomer（）
商业幂等。有时，您拥有允许您检测重复呼叫的业务标识符。示例：createCustomer（email）
如果这些方法不起作用，您需要添加自己的幂等性处理：
唯一身份。您可以生成唯一标识符并将其添加到呼叫中。这样，如果您在服务提供商端存储该ID，则可以轻松发现重复呼叫。如果您利用工作流引擎，您可能会让它完成繁重的工作（例如，当Camunda允许在启动期间对密钥进行重复检查时）。示例：charge（transactionId，amount）
请求哈希。如果您使用消息传递，则可以通过存储消息的哈希值来执行相同的操作。您可以再次利用工作流引擎，或者您可以使用具有内置租赁功能的数据库（如Redis）。
长话短说：在您的服务中注意幂等性。这将带来巨大的回报。
给我看一下代码
您可以使用BPMN和开源Camunda引擎找到实现我在此描述的模式的源代码
Java或C＃。(需要的后台发消息)
摘要
在本文中，我介绍了三个常见的陷阱，我看到客户在整合微服务时踩到了：低估了远程通信的复杂性，忽略了异步性的挑战，忘记了商业交易。
通过重试，超时和补偿活动的状态模式引入处理这些情况的功能可以降低微服务基础架构的整体复杂性并增强其弹性。它还有助于：
将重要的故障处理和事务行为封装在它所属的位置：在服务本身的上下文中。
将故障或超时处理的工作量减少到更小的范围，从而降低整体复杂性。
简化服务API，只发布对客户真正重要的故障。
改善客户体验，客户可能是其他服务，内部员工，甚至是客户。
使用轻量级工作流引擎，您可以通过应用自行开发的解决方案来处理有状态模式，而无需投入大量精力或冒着意外复杂性的风险。随附的源代码提供了具体示例。
你们公司采用微服务架构了吗？
| 本文 | ||
| 讨论：请加入知识星球【首席架构师圈】或者加微信小号【jiagoushi_pro】或者加QQ群【11107777】 | ||
| 公众号 | 【jiagoushipro】【超级架构师】精彩图文详解架构方法论，架构实践，技术原理，技术趋势。我们在等你，赶快扫描关注吧。 | |
| 微信小号 | 【cea_csa_cto】50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化. | |
| QQ群 | 【792862318】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。加QQ群，有珍贵的报告和干货资料分享。 | |
| 视频号 | 【超级架构师】1分钟快速了解架构相关的基本概念，模型，方法，经验。每天1分钟，架构心中熟。 | |
| 知识星球 | 向大咖提问，近距离接触，或者获得私密资料分享。 | 知识星球【首席架构师圈】 |
| 微信圈子 | 志趣相投的同好交流。 | 微信圈子【首席架构师圈】 |
| 喜马拉雅 | 路上或者车上了解最新黑科技资讯，架构心得。 | 【智能时刻，架构君和你聊黑科技】 |
| 知识星球 | 认识更多朋友，职场和技术闲聊。 | 知识星球【职场和技术】 |
| 微博 | 【智能时刻】 | 智能时刻 |
| 哔哩哔哩 | 【超级架构师】 | |
| 抖音 | 【cea_csa_cto】超级架构师 | |
| 快手 | 【cea_csa_cto】超级架构师 | |
| 小红书 | 【cea_csa_cto】超级架构师 | 首席架构师智库 |
谢谢大家关注，转发，点赞和点在看。