Twitter下架部分微服务，是微服务错了？

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

• 微服务在IT架构中处于什么位置？
• 微服务跟清晰分层、井井有条的传统IT架构来比较，孰优孰劣？
• 那有没有人呼吁简化微服务，尝试解决这方面的难题？
• 是否存在最适合的微服务应用场景？与之对应，有没有明确不适用微服务架构的场景？
• 但如果一家企业深度拥抱微服务，但突然被迫放弃这条路，结果会怎么样？

  
  

就在Twitter的部分微服务被新任CEO马斯克勒令下架之际，部分用户很快报告称自己无法正常登录软件。此前，马斯克曾将这些被关闭的微服务称为“膨胀软件”，但粗暴剔除使得一些用户的双因素身份验证出了问题。Twitter最终解决了问题，可微服务在IT架构中的作用因此受到了质疑。

在此次Twitter事件中，砍掉部分微服务就像是用力抽出缠结线团中的一个线头，意外解开了几个重要的结。但借此机会，其他组织也想思考自己能不能不用微服务，还是说微服务架构已经与自身运营体系紧密绑定、一损俱损。

Pulumi公司CEO Joe Duffy就微服务融入IT架构的态势、带来的助益，以及如何在IT管理者的疏忽下成为新的遗留技术债务发表了观点。

微服务在IT架构中处于什么位置？

在我的脑海里有这样一道光谱，两端分别是单体式架构和完全分布式架构。微服务就处于这道光谱中更偏向完全分布式架构的位置。云计算的普及让我们能够以全新方式思考事物。想想真正的分布式应用程序架构，我们就是从“双虚拟机加单数据库”的时代步步前行，通过托管服务、容器再到无服务器架构最终来到了完全分布式的彼岸。而微服务无疑在其中扮演了重要角色。

现代云确实加速了向这些架构的转变，但不同架构其实各有利弊，绝不是越新越好。微服务虽然活动组件更多、复杂性更高，但也提供了一种将服务置于API边界，借此将复杂度控制在合理范围内的办法。

亚马逊在这方面的早期探索最为典型，因为Bezos要求各团队必须通过API进行通信。这就产生了一种观念，即各个团队分别运行不同的服务，而服务间由软件连通——靠的是API，而不再是人。这有助于不同团队分别独立行动，但又能协同达成约定的功能。不过可以想见，这样的体系也往往会过度膨胀，而且底层的复杂性只是被掩盖住了、并没被真正消除。

一旦把这些麻烦藏在API背后，人们就很容易往那一丢、再也不管。现实情况就是，很多企业实际可能只需要5项微服务，但实际微服务数量却成千上万。这就是所谓过度膨胀，但我认为还算是发展历程中的正常阶段。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 视频教程：https://doc.iocoder.cn/video/

微服务跟清晰分层、井井有条的传统IT架构来比较，孰优孰劣？

微服务当然有自己的优势，它能大大降低系统运行的门槛。它提供API，所以一次API调用就能获得所需功能。其实把功能抽象成微服务是件好事，意味着我们不再需要频繁思考怎么操作这些功能。只需要启动、运行、调用，就这么简单。

微服务也可能成为遗留系统、成为不再增值的系统，但这同样不是坏事——毕竟任何人的脑容量都是有限的，如果把这些已经固化的部分都塞进庞大的单一系统，那就根本没法管理了。借助微服务，我们可以对平台的不同功能做明确划分，然后分别放在API和微服务后面。当然，这种遗产或者说债务也确实会随时间推移而不断累积。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud
• 视频教程：https://doc.iocoder.cn/video/

那有没有人呼吁简化微服务，尝试解决这方面的难题？

其实跟任何事物一样，微服务也有自己的Gartner炒作周期——先是期望过高的峰值，然后走向幻想破灭的低谷。微服务的低谷期应该已经过了，但整个发展历程仍然值得一说。坦率地讲，很多人其实是在不适合的场景中使用微服务，甚至是为了微服务而微服务。

Kubernetes那边也有类似的状况：每个人都想用一把Kubernetes，却没有考虑到自己的需求规模到底有没有必要。微服务在炒作周期中比Kubernetes中走得更远，所以使用方式也更合理一点了。

要解答这个问题，我们可能需要退回一步，想想自己到底要让这套系统实现什么功能。比如说当我们手头有上千项微服务，那就很容易迷失方向，搞不清当初到底想用它们实现什么功能、系统构建的最优方法是什么。另外，微服务在正常使用下也会保持有机增长。刚开始，我们创建服务、发布服务、部署API；接下来就是调用API，再据此构建新的服务。这就创造出了一个相互依存、彼此关联的微服务网络。

如果单体式架构能够满足需求，那不妨优先采用。但随着团队规模的扩大，单体式架构往往开始成为瓶颈。所以正确的答案在于权衡，不存在银弹式的终极真理。

是否存在最适合的微服务应用场景？与之对应，有没有明确不适用微服务架构的场景？

亚马逊云科技就是典型的微服务应用案例。看看他们的产品组合，400多种不同且彼此独立的服务堆叠起来，而且每项服务都有自己的API。因此亚马逊拥有独特的内部组织方式，各团队就是自己产品和服务的所有者。这种架构跟业务组织是高度统一的，如果不选择这种运营方式，我很难想象他们能够建立起如何庞大的云服务平台。

而相对比较复杂的是那种“灰色”区域，比如说Stripe。Stripe也属于服务集合和产品集合。我敢肯定，其中的身份验证服务跟信用卡计费和其他计量服务肯定彼此独立，而报告跟分析服务又是额外的部分。作为一家物流配送企业，Stripe关注的是产品运输中的实施细节，所以我估计他们肯定是找到了单体跟分布之间的理想平衡。

总之，产品越简单、本质越单一，就越没必要把它拆分成多个彼此独立的服务。

但如果一家企业深度拥抱微服务，但突然被迫放弃这条路，结果会怎么样？

其实这类架构决策不存在“突然被迫放弃”这种情况，它们反映的可是非常深刻的问题。微服务的优势在于不同事物之间在物理上相互独立，甚至各自运行在不同服务器上并由API连通。这些API肯定会影响性能。

所以要想放弃这样的架构设计，肯定需要审慎考量，比如“既然我们不需要这些服务，能不能直接关掉？”但这并不是微服务特有的问题，只是在微服务架构中容易被忽略的问题。只要运行软件，这样的问题就总会存在。为什么你会有那么多根本不需要的服务？要想保留并整合这么多服务，本身就是会是个重大的架构变化，微不微服务都一样。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）