江苏龙网

  1. 主页 > 生活百科 > >

微服务全做错了！谷歌提出新方法，成本直接降为1/9！( 二 )

微服务


踩了微服务的“坑”之后 ， Uber 团队对新服务进行了更加深思熟虑的规划：不再只是完成一件事，而是使其服务于一项业务功能，由 5-10 个工程师负责维护 ， 还总结出了血泪教训：要在正确的时间选择正确的解决方案来构建产品 。
办公管理软件公司 Managed by Q 的应用程序是一个部署在 ECS 上的 Django 单体 。为了赶上现代化开发实践的步伐，他们转向微服务架构 。但他们很快发现 ， 每多一个新服务，就会增加一些基础设施，而且开发一个跨多个服务的功能需要做更多的工作 。
结果，在转向微服务两年之后，他们开始合并微服务 。一些微服务被合到了单体中，其他的则合并成较大的服务 。他们也在实践中得出经验：不能理所当然地认为微服务就是正确的选择 。
本来想把微服务当银弹 ， 结果工程开销太大，得不偿失 。以上提到的企业最大的问题是在只有20位工程师的环境中实现了几十个微服务，有种杀鸡焉用牛刀的错位感 。
04微服务的虚假繁荣：从单体变成“分布式单体”随着越来越多“逃离微服务”的案例发生，人们对于2005年就提出的“微服务”再度审视，甚至批评 。
比如开头提到的谷歌工程师们 ， 就在他们的论文中列出了目前微服务方法的缺陷，包括：
性能：通过网络将数据序列化并发送到远程服务会损害性能 ， 如果应用程序变得足够复杂 ， 甚至可能导致瓶颈 。
理解追踪：众所周知，在分布式系统中 ， 考虑到微服务之间的许多交互，很难追踪Bug 。
管理问题：应用程序的不同部分可以按照自己的时间表进行更新，这被认为是一个优势 。但这导致开发人员不得不管理大量的二进制文件，每个二进制文件都有自己的发布时间表 。祝您好运 ， 使用本地运行的服务运行端到端测试 。
API变得脆弱：微服务互操作性的关键是，一旦建立了微服务 ， API就不能改变，让它们破坏任何其他依赖API的微服务 。因此，API只能用更多的API进行扩展，从而产生膨胀 。
看起来跟之前提到的“过度设计”的概念不谋而合 。
事实上有些团队在将集中式单体应用拆分为微服务时，首先进行的往往不是建立领域模型，而只是按照业务功能将原来单体应用的一个软件包拆分成多个所谓的“微服务”软件包，而这些“微服务”内的代码高度耦合，逻辑边界不清晰 ， 本质上还是单体架构模式，所以只是实现了“表面繁荣” ， 并没有实现想要的结果 。
正如Sam Newman在《构建微服务》一书中提到的那样，架构需要满足一定的前提条件，否则就可能过度设计 。
05谷歌提出了一种新的微服务业内有这样一种依旧支持微服务架构的观点：微服务需要与之匹配的规模 。“如果你知道最终会以一定的规模来做这件事，在开始时可能会以不同的方式来构建它 。但问题就在于，你知道如何做这件事情吗？你知道你将以多大的规模来运营它吗？”
事实上在许多应用程序中，尤其是内部应用程序，开发成本往往会超过了运行时成本 。
谷歌的论文恰恰解决了这个问题，编程模式和部署模式的分开，可以让开发人员更加轻松 ， 同时让运行时基础设施的“赌注”找到运行这些应用程序的最具成本效益的方法 。
正如谷歌研究人员所写道的：“通过将所有执行责任委托给运行时，我们的解决方案能够提供与微服务相同的好处，但性能更高，成本更低 。”
06基础架构重新思考的一年今年进行了许多基础架构的重新思考，微服务并不是唯一被质疑的泡沫 。例如 ， 云计算也受到了审查 。
6月，同时运行Basecamp和Hey电子邮件应用程序的37signals公司采购了一批戴尔服务器 ， 并离开了云计算，打破了几十年来大家抛弃老旧拥抱新故事的传统 。
David Heinemeier Hansson在一篇博客文章中解释道：“这是云营销的常用话术：它会变得容易得多，几乎不需要任何人来操作 。”“（但事实是）我从来没有见过 。37signals没有，来自大型互联网公司的人也没有见过 。云有一些优势，但它通常不会减少运维人员 。”
当然，DHH是一名赛车手 ， 有可能更喜欢裸机 。但也有不少拥趸愿意支持这一赌注 。今年晚些时候 ， Oxide Computers推出了他们的新系统，希望能为其他人提供类似的服务：运行云计算工作负载，但在自己的数据中心更具成本效益 。


推荐阅读


上一篇：杭州破获重大勒索病毒案：犯罪团伙用ChatGPT优化程序

下一篇：python 爬虫常用第三方库推荐