大兴黄村网站建设公司,wordpress 关注插件,html设计网站,北京搜索引擎优化seo微服务很重要。它们可以为我们的架构和团队带来一些相当大的胜利#xff0c;但微服务也有很多成本。随着微服务、无服务器和其他分布式系统架构在行业中变得更加普遍#xff0c;我们将它们的问题和解决它们的策略内化是至关重要的。在本文中#xff0c;我们将研究网络边界可… 微服务很重要。它们可以为我们的架构和团队带来一些相当大的胜利但微服务也有很多成本。随着微服务、无服务器和其他分布式系统架构在行业中变得更加普遍我们将它们的问题和解决它们的策略内化是至关重要的。在本文中我们将研究网络边界可能引入的许多棘手问题的一个示例超时。 在你害怕“分布式系统”这个词之前请记住即使是一个带有 Node 后端的小型 React 应用程序或者一个与 AWS Lambda 对话的简单 iOS 客户端也代表一个分布式系统。当您阅读这篇博文时您已经参与了一个分布式系统其中包括您的 Web 浏览器、内容交付网络和文件存储系统。 在背景方面我将假设您了解如何使用您选择的语言进行 API 调用并处理它们的成功和失败但这些 API 调用是同步还是异步、HTTP 或不是。如果您遇到不熟悉的术语或想法请不要担心我很高兴在 Twitter 或其他地方进行更多讨论并且我还尝试在适当的地方添加链接。 我们将要探讨的问题是如果我们遇到一个非常非常慢的 API 调用最终超时并且我们假设 (a) 它成功或 (b) 它失败我们就会遇到错误。超时或更糟糕的是无限长的等待是分布式系统的一个基本事实我们需要知道如何处理它们。 问题 让我们从一个思想实验开始你有没有给同事发邮件向他们要东西 [星期二上午 9:58] 你“嘿你能把我加到我们公司的潜在导师名单中吗” 同事“……” [星期五下午 2:30] 你[?] 你该怎么办 如果您希望您的请求得到满足您最终需要确定没有回复。你会等更长的时间吗你想等多久 那么一旦你决定等待多长时间你会采取什么行动您是否再次尝试发送电子邮件你尝试不同的传播媒介吗你认为他们不会这样做吗 好的现在这里到底发生了什么我们希望看到这种请求-响应行为 但是出了点问题。有几种可能性 他们从来没有得到消息。 他们收到了邮件成功处理了邮件然后给您发回了一个从未收到您的回复或转到您的垃圾邮件文件夹。 他们得到了信息但他们仍在思考或者他们失去了它或者[喘气]他们忘记了。 最终我们只是不知道 正是这个问题出现在分布式系统上的任何通信中。 我们可能会延迟我们的请求、处理或响应而这些延迟可能是任意长的。因此与电子邮件示例一样我们需要确保“我们要等多久”问题有答案我们称该持续时间为超时。 如果您只从本文中学到一个教训那就这样吧使用超时。否则您将面临永远等待永远不会完成的操作的风险。 但是一旦我们达到了超时等待的上限我们该怎么办 方法 当人们在远程系统调用中遇到超时时有几种常见的方法。我并不声称这份清单是详尽无遗的但它确实涵盖了我见过的许多最常见的场景。 方法#1 当您遇到超时时假设它成功并继续前进。 请不要这样做。[1]不幸的是我不得不说这是一个常见的无意识选择即使在生产应用程序中也会有一些非常糟糕的用户体验结果。如果我们假设手术成功了我们可怜的消费者就会合理地假设事情进展顺利——只是后来当他们发现结果时会感到失望和困惑。 任何时候你有一个网络呼叫寻找成功和失败的案例。例如如果你在 JavaScript 中通过 Promise.then(...) 使用异步 API请问问自己对应的 .catch(...) 在哪里。如果它丢失了你几乎肯定有一个错误。 在一些非常特殊的情况下您可能理所当然地不在乎请求是成功还是失败。UDP 是具有此属性的非常成功的协议。另外很多软件坏了继续赚钱就好了但请不要让这成为您的默认设置——先用尽您的其他选项。 方法#2 对于读取请求请使用缓存或默认值。 如果您的请求是读取请求并且不打算对远程端产生任何影响那么这可能是一个不错的选择。在这种情况下您可以使用先前成功请求中的缓存值。或者如果还没有成功的请求或者缓存在您的情况下没有意义您可以使用默认值。这种方法相对简单它不会增加太多的性能开销或实现复杂性。但请记住如果您使用的是通过网络访问的进程外缓存例如memcached、Redis 等那么您将回到类似的情况即您的请求对缓存本身可能会超时。 方法#3 当您遇到超时时假设远程操作失败然后自动重试。 这提出了更多的问题 如果重试不安全怎么办网络连接另一端的服务获取重复项只是烦人吗或者你是双重收取信用卡 您应该同步重试还是异步重试 如果您同步重试从消费者的角度来看这些重试会减慢您的速度——您是否有可能无法满足他们的期望这在服务中尤其重要而不是最终用户应用程序。 如果你异步重试你告诉你的消费者关于操作成功的什么您是一次尝试一个还是在一段时间内分批重试 您应该重试多少次一次两次10次直到成功 您应该如何在重试之间延迟指数退避[例如1s、2s、4s、8s、16s...] 以最大等待时间为界使用抖动 如果远程服务器由于过载而出现性能问题重试是否会使他们的情况变得更糟 如果远程 API 可以安全地重试我们称之为幂等。如果没有幂等属性您可能会创建重复数据如信用卡费用的情况或导致竞争条件即如果您尝试更改您的电子邮件地址两次并且第一个在第二个完成后重试。 在许多情况下使自动重试安全可能需要大量的架构工作。但是如果您可以安全地重试例如通过发送请求 UUID并让远程端跟踪这些事情就会变得非常非常简单。查看 Stripe API 以了解实际情况的一个很好的示例。 方法#4 检查请求是否成功如果安全再试一次。 这里的想法是在某些情况下我们可以在超时请求之后跟上另一个请求询问我们原始请求的状态。这种方法显然需要存在一个端点可以为我们提供我们想要的信息。给定这样一个端点如果端点说我们的请求成功我们可以明确地说我们不需要重试。 但是这里有一个严重的问题我们无法真正知道重试是否安全。因为通常我们的远程服务可以接收到请求但仍在处理中因此我们正在检查的查询端点将无法确认成功。当然检查本身可能会超时远程服务器可能由于与初始故障相同的原因而完全无法访问但即使这是真的我们仍然无法知道问题是在处理初始请求之前还是之后发生的。 方法#5 放弃并让用户弄清楚。 这需要最少的努力并且可以说可以防止我们做出错误的决定因此在许多情况下这可能是最佳选择。我们还需要问自己我们的用户能找出正确的做法吗他们是否有足够的信息和对其他系统的洞察力来确定如何前进 在某些情况下让我们的消费者知道这个问题可能是最好的选择。对于任何涉及重试的方法如果我们不想允许无限次数的重试我们最终可能仍会退回到这条路径 结论 所以在这一点上事情可能看起来很黯淡。分布式系统很难看来我们不能只选择其中一种解决方案作为灵丹妙药。如果您感到失败请振作起来不要让完美成为美好的敌人。 使用超时。 即使超时时间很长比如 5 秒、10 秒或 [gulp!] 甚至更多每个网络请求都应该有一些超时时间。选择超时可能很棘手——当请求最终成功时您不希望有太多失败误报也不希望浪费太多时间并冒着不健康的应用程序的风险。您可以通过查看历史请求的分布和趋势以及您的应用程序自身的性能保证或风险概况来确定好的值。 在任何情况下我们都不希望我们的应用服务器的队列、连接池、环形缓冲区或任何瓶颈被将永远等待的东西堵塞。您绝对可以根据您的生产需求研究并添加更高级的东西例如断路器和隔板但是超时很便宜并且库很好地支持。使用它们 默认使重试安全。 除了让你的代码更简单、更安全之外你还会说“幂等性”这很有趣。 考虑以不同的方式委派工作。 异步消息传递在这里有一些吸引人的特性因为您的远程服务不再需要保持快速和可用只有您的消息代理可以。但是消息传递/异步性并不是灵丹妙药——您仍然需要确保代理收到消息。不幸的是这可能很难消息代理也有权衡。您的用户对于何时需要重试会有自己的想法。例如如果消息处理延迟他们可能会决定重新提交因为他们的订单尚未显示在订单历史记录中。分布式日志/流媒体平台也可能出现类似问题。如果您正在考虑消息传递路线实际上即使没有请仔细查看 Enterprise Integration Patterns — 尽管它年代久远但其中的模式与当今的架构极为相关。 并且冒着成为派对大便的风险不要忘记您可能能够完全移动或删除该网络边界把一个难题变成一个简单的问题并没有什么可耻的。因此也许您可以使用一个网络请求而不是五个或者您可以将两个服务内联在一起。或者也许您采用上述方法之一以可靠和安全的方式处理超时。无论您选择哪种方式请记住您的用户并不关心您是否使用微服务——他们只是想让事情正常工作。 本文 :https://architect.pub/microservices-arent-magic-handling-timeouts讨论知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】公众号 【jiagoushipro】 【超级架构师】 精彩图文详解架构方法论架构实践技术原理技术趋势。 我们在等你赶快扫描关注吧。微信小号 【ca_cea】 50000人社区讨论企业架构云计算大数据数据科学物联网人工智能安全全栈开发DevOps数字化. QQ群 【285069459】深度交流企业架构业务架构应用架构数据架构技术架构集成架构安全架构。以及大数据云计算物联网人工智能等各种新兴技术。 加QQ群有珍贵的报告和干货资料分享。 视频号【超级架构师】 1分钟快速了解架构相关的基本概念模型方法经验。 每天1分钟架构心中熟。 知识星球【首席架构师圈】向大咖提问近距离接触或者获得私密资料分享。 喜马拉雅【超级架构师】路上或者车上了解最新黑科技资讯架构心得。【智能时刻架构君和你聊黑科技】知识星球认识更多朋友职场和技术闲聊。知识星球【职场和技术】领英Harryhttps://www.linkedin.com/in/architect-harry/领英群组领英架构群组https://www.linkedin.com/groups/14209750/微博【超级架构师】智能时刻哔哩哔哩【超级架构师】 抖音【cea_cio】超级架构师 快手【cea_cio_cto】超级架构师 小红书【cea_csa_cto】超级架构师 网站CIO(首席信息官)https://cio.ceo网站CIO,CTO和CDOhttps://cioctocdo.com网站架构师实战分享https://architect.pub 网站程序员云开发分享https://pgmr.cloud网站首席架构师社区https://jiagoushi.pro网站应用开发和开发平台https://apaas.dev网站开发信息网https://xinxi.dev网站超级架构师https://jiagou.dev网站企业技术培训https://peixun.dev网站程序员宝典https://pgmr.pub 网站开发者闲谈https://blog.developer.chat网站CPO宝典https://cpo.work 谢谢大家关注转发点赞和点在看。
