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

之前小编曾在公众号文章《从Twitter裁员事件看IT专业人士的阶级分析》中提过，伊隆·马斯克

收购Twitter以后，大量裁员，还批评Twitter技术团队不仅人员过剩，且技术能力不足。马斯克

入主Twitter后，先后推出付费蓝V认证、考虑出售用户名、引入支付功能等方式，创造新的收入

来源后，现在又准备效仿微博打击第三方客户端了。日前，推特方面通过其开发者账户宣布，自

2023年2月9日起将不再提供对Twitter API的免费访问，无论v1.1、还是v2版本的Twitter API都

将全部由免费转变为付费使用。

马斯克此番操作下架Twitter部分微服务，真的是微服务错了吗？请听下文解析。

▼

就在Twitter的部分微服务被新任CEO马斯克勒令下架之际，部分用户很快报告称自己无法正常登

录软件。此前，马斯克曾将这些被关闭的微服务称为“膨胀软件”，但粗暴剔除使得一些用户的

双因素身份验证出了问题。Twitter最终解决了问题，可微服务在IT架构中的作用因此受到了质疑

。

在此次Twitter事件中，砍掉部分微服务就像是用力抽出缠结线团中的一个线头，意外解开了几个

重要的结。但借此机会，其他组织也想思考自己能不能不用微服务，还是说微服务架构已经与自

身运营体系紧密绑定、一损俱损。

Pulumi公司CEO Joe Duffy就微服务融入IT架构的态势、带来的助益，以及如何在IT管理者的疏

忽下成为新的遗留技术债务发表了观点。

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

在我的脑海里有这样一道光谱，两端分别是单体式架构和完全分布式架构。微服务就处于这道光

谱中更偏向完全分布式架构的位置。云计算的普及让我们能够以全新方式思考事物。想想真正的

分布式应用程序架构，我们就是从“双虚拟机加单数据库”的时代步步前行，通过托管服务、容

器再到无服务器架构最终来到了完全分布式的彼岸。而微服务无疑在其中扮演了重要角色。

现代云确实加速了向这些架构的转变，但不同架构其实各有利弊，绝不是越新越好。微服务虽然

活动组件更多、复杂性更高，但也提供了一种将服务置于API边界，借此将复杂度控制在合理范

围内的办法。

亚马逊在这方面的早期探索最为典型，因为Bezos要求各团队必须通过API进行通信。这就产生了

一种观念，即各个团队分别运行不同的服务，而服务间由软件连通——靠的是API，而不再是人

。这有助于不同团队分别独立行动，但又能协同达成约定的功能。不过可以想见，这样的体系也

往往会过度膨胀，而且底层的复杂性只是被掩盖住了、并没被真正消除。

一旦把这些麻烦藏在API背后，人们就很容易往那一丢、再也不管。现实情况就是，很多企业实

际可能只需要5项微服务，但实际微服务数量却成千上万。这就是所谓过度膨胀，但我认为还算

是发展历程中的正常阶段。

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

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

微服务当然有自己的优势，它能大大降低系统运行的门槛。它提供API，所以一次API调用就能获

得所需功能。其实把功能抽象成微服务是件好事，意味着我们不再需要频繁思考怎么操作这些功

能。只需要启动、运行、调用，就这么简单。

微服务也可能成为遗留系统、成为不再增值的系统，但这同样不是坏事——毕竟任何人的脑容量

都是有限的，如果把这些已经固化的部分都塞进庞大的单一系统，那就根本没法管理了。借助微

服务，我们可以对平台的不同功能做明确划分，然后分别放在API和微服务后面。当然，这种遗

产或者说债务也确实会随时间推移而不断累积。

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

其实跟任何事物一样，微服务也有自己的Gartner炒作周期——先是期望过高的峰值，然后走向

幻想破灭的低谷。微服务的低谷期应该已经过了，但整个发展历程仍然值得一说。坦率地讲，很

多人其实是在不适合的场景中使用微服务，甚至是为了微服务而微服务。

Kubernetes那边也有类似的状况：每个人都想用一把Kubernetes，却没有考虑到自己的需求规

模到底有没有必要。微服务在炒作周期中比Kubernetes中走得更远，所以使用方式也更合理一

点了。

要解答这个问题，我们可能需要退回一步，想想自己到底要让这套系统实现什么功能。比如说当

我们手头有上千项微服务，那就很容易迷失方向，搞不清当初到底想用它们实现什么功能、系统

构建的最优方法是什么。另外，微服务在正常使用下也会保持有机增长。刚开始，我们创建服务

、发布服务、部署API；接下来就是调用API，再据此构建新的服务。这就创造出了一个相互依存

、彼此关联的微服务网络。

如果单体式架构能够满足需求，那不妨优先采用。但随着团队规模的扩大，单体式架构往往开始

成为瓶颈。所以正确的答案在于权衡，不存在银弹式的终极真理。

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

亚马逊云科技就是典型的微服务应用案例。看看他们的产品组合，400多种不同且彼此独立的服

务堆叠起来，而且每项服务都有自己的API。因此亚马逊拥有独特的内部组织方式，各团队就是

自己产品和服务的所有者。这种架构跟业务组织是高度统一的，如果不选择这种运营方式，我很

难想象他们能够建立起如何庞大的云服务平台。

而相对比较复杂的是那种“灰色”区域，比如说Stripe。Stripe也属于服务集合和产品集合。我

敢肯定，其中的身份验证服务跟信用卡计费和其他计量服务肯定彼此独立，而报告跟分析服务又

是额外的部分。作为一家物流配送企业，Stripe关注的是产品运输中的实施细节，所以我估计他

们肯定是找到了单体跟分布之间的理想平衡。

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

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

其实这类架构决策不存在“突然被迫放弃”这种情况，它们反映的可是非常深刻的问题。微服务

的优势在于不同事物之间在物理上相互独立，甚至各自运行在不同服务器上并由API连通。这些

API肯定会影响性能。

所以要想放弃这样的架构设计，肯定需要审慎考量，比如“既然我们不需要这些服务，能不能直

接关掉？”但这并不是微服务特有的问题，只是在微服务架构中容易被忽略的问题。只要运行软

件，这样的问题就总会存在。为什么你会有那么多根本不需要的服务？要想保留并整合这么多服

务，本身就是会是个重大的架构变化，微不微服务都一样。

作者：李斌

来源：分布式实验室

版权申明：内容来源网络，仅供分享学习，版权归原创者所有

那么对于以上问题，您有怎样的见解呢？欢迎在下方留言。

                                                                           END

即将在上海举办的K+全球软件研发行业创新峰会，特设“微服务与领域驱动设计”专题，该专题

从微服务的编排与监控治理，以及如何使用领域驱动设计进行更好的服务化，给参会者带来一些

经验总结与实践分享。