醒醒！你不是真的需要微服务
2023-08-13
本文摘要：2020 年，许多技术人可能都已经迷醉在了微服务的乐成故事中，但现实很骨感，微服务也不是“灵丹妙药”。本文想给现阶段“狂热”的微服务泼泼冷水、降降温，也许你就会发现，你并不是真的需要微服务。本文最初公布于 Linkedin 官方博客，经原作者授权由 InfoQ 中文站翻译并分享。2020 年，如果再讲什么是微服务，已经落伍了，究竟微服务的乐成故事已经开始在业界广为流传了。 可是你真的需要微服务吗？“真的需要微服务吗？
本文关键词：开云手机版官方下载,醒醒,你,不是,真的,需要,微,服务,2020,年,许多
2020 年，许多技术人可能都已经迷醉在了微服务的乐成故事中，但现实很骨感，微服务也不是“灵丹妙药”。本文想给现阶段“狂热”的微服务泼泼冷水、降降温，也许你就会发现，你并不是真的需要微服务。本文最初公布于 Linkedin 官方博客，经原作者授权由 InfoQ 中文站翻译并分享。2020 年，如果再讲什么是微服务，已经落伍了，究竟微服务的乐成故事已经开始在业界广为流传了。
可是你真的需要微服务吗？“真的需要微服务吗？”这个想法已经困扰我很长一段时间了，最近我与多位技术人举行了相同，也许我们可以从解决一个有趣的问题，开始入手。“什么是微服务？我们的解决方案应该遵循这种架构吗？”问题的第一部门很容易回覆，而第二部门则需要高屋建瓴、审慎看待。在相同之后，我发现有个事情是大家都告竣共识的：受益者会把微服务架构应用到他们即将推出的产物中，因为他们需要连忙出效果来背书。
到场讨论的人里有大量的非技术人员。当谈话越来越“技术化”，与决议也就越不相关了。长时间的中断以及提不出问题，这也就意味着不熟悉 Web 服务，更不用说微服务了。
我不会因为他们不知道 Web 服务是做什么，或者微服务如何对他们有利或有害而谴责他们。究竟，他们在我不擅长的事情上要精彩得多。他们计划加入微服务的行列，虽然还不甚相识其影响!我第一次听到“微服务”这个词是在 2013 年，其时是在 YouTube 上一个解释 Netflix 服务架构的视频中。
其时我以为这让人无法明白，所以绝不犹豫地跳过了。究竟，这对于其时想方设法要进入设计原理领域的人来说太难了。
可是，当新的项目提案宣布接纳微服务时，它很快就让我着迷了。这个项目的设计很吸引人，它仍然是我接触过的最好的代码库之一。说实话，模块化设计的广泛可能性可以淘汰肩负。
而我只是一个无知的开发人员，对 DevOps 避之唯恐不及，它带来了分外的庞大性。如果快进 5 年，我可能正在和一群全新的人开发一个全新的产物。我的日子里充斥着由设计糟糕的微服务和业余的 DevOps 战术所引发的问题。虽然问题很快就解决了，但我看到了微服务的懦弱性。
这也让我凭据自己的履历来审视整个架构。虽然已经太晚了，但晚做总比不做好！看到了微服务的正反两面影响，我开始申饬自己要多看看反面影响，在实践微服务之前，先问自己以下几个问题。你的应用法式已经大足够拆分为微服务吗？必须认可，并不是所有的应用法式都大到可以剖析成更小的服务。顾名思义，微服务是一组更小的、具有特定用途的服务。
在理想的情况下，我们希望每个服务自己都是一个完整的应用法式。这是微服务和单体服务之间“每行代码成本”的一个比力。由于微服务在人力和盘算成本方面的最小资源限制，纵然在比力轻量化的形式下，也会发生较高的成本。
成本是每小我私家都体贴的问题，如果不是，你可能基础就不应做决议。固然，你的代码库未来会增长，它也可能会增加一个新的领域。
但你应该永远记着：一个设计良好的代码库随时都可以切换到微服务，所以在靠近阈值时实践微服务，是性价比最高的。你真的需要扩展应用法式的各个组件吗？假设你的产物卖力人带着一个 HRMS 应用法式的想法来找你，想要通过它治理一个上万人规模的组织。
你可能立马就有相识决方案：微服务架构。固然，这是一个极端的例子，可是你明确我的意思!!使用微服务架构的一个主要优点是单个组件很是容易扩展。我们可能会发现大量的应用法式需要组件可以单独扩展，可是你的应用法式真的需要这样做吗？你是否有跨服务的事务？现在，这可能是最难题的战略选择之一。跨多个服务的事务是整个架构的肩负。
解决跨服务的事务意味着，服务之间的互锁、一系列难以跟踪的死锁以及可能破坏服务康健的竞争条件；有时甚至是工程师的康健。凭据界说，REST 服务是无状态的。它们不应该到场超出单个服务的事务。
在高性能的世界里，两段提交 [ 2PC ] 是一个不须要的贫苦。而 SAGA 模式只会增加另一层意料之外的庞大性。
微服务引入了最终一致性问题，因为它们坚持漫衍式的数据治理。在单体架构中，你可以在单个事务中一次更新一堆工具。
微服务需要多个资源来更新，不赞成接纳漫衍式事务（理由很充实）。所以现在，开发人员需要注意一致性问题，并在写任何代码之前，弄清楚如何检测差别步。—— Martin Fowler有可能跨服务举行事务处置惩罚吗？是的，固然。
可是，是否值得在整个无状态的服务中实现一系列操作呢？恐怕不行! !服务之间是否需要频繁通信？在传统的单体服务中，每个微服务实例体现为系统内的模块。模块之间的通信在内存中，延迟靠近于零。微服务的引入意味着，通信已经从内存事务酿成了网络指令。
有许多可靠的解决方案可供我们选择，但它们都以延迟为价格。从内存事务转变为基于网络的通信将把延迟单元从纳秒变为微秒。假设有三个差别的服务通过网络相互通信。
假设每个服务挪用需要 100 毫秒 [在有负载的情况下这不行能]，那么仅在网络上就需要花费 300 毫秒。有些应用法式生来就与组件和服务精密集成。
在处置惩罚实时数据的应用法式中，增加的通信层可能会导致灾难性的效果。想象一下，当你穿着外科手术服或者在控制航空交通时，通讯泛起了延迟！其他值得思考的问题增加的庞大性——固然，庞大性无法量化，只能相对地举行比力。虽然微服务最初的设计目的是通过将应用法式拆分成更小的块来降低庞大性，可是架构自己在部署和维护方面很庞大。
漫衍式的成本——微服务是具有分子特性的漫衍式系统。但漫衍式也有价格。
单体服务将部署在大型 VM 或首选容器上。可是，对。
本文关键词：开云手机版官方下载,醒醒,你,不是,真的,需要,微,服务,2020,年,许多
本文来源：开云手机版官方下载-www.jxhtzy.com