阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 分布式实验室 「李斌」欢迎转载，保留摘要，谢谢！

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

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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