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+全球软件研发行业创新峰会，特设“微服务与领域驱动设计”专题，该专题从微服务的编排与监控治理，以及如何使用领域驱动设计进行更好的服务化，给参会者带来一些经验总结与实践分享。

感兴趣的小伙伴，扫描下方二维码，解锁更多新信息！

现在报名，还享早鸟优惠哦！