阅读全文

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

摘要: 原创出处 medium.com/@PurpleGreenLemon/was-microservices-a-bad-idea-5e52edee1cff 「网络」欢迎转载，保留摘要，谢谢！

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

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

曾几何时，我记得我的手指疯狂地敲打键盘，与庞大而杂乱的代码库搏斗。那是巨石的时代，代码就像古老的城堡一样，由一块块石头砌成一个令人印象深刻的庞然大物。

几年过去了，时代变了。开发人员口中的流行语变成了“微服务”。微服务革命——承诺成为我们的救世主。

我们被告知，通过将庞然大物分割成更小、自包含的独立服务，我们将获得无与伦比的可扩展性、敏捷性和可维护性。这听起来是如此完美。

❝

更快的部署？√

单独扩展？√

独立团队开发？√

❞

但是，当我把单体架构切换成微服务时，我不禁想知道：微服务的魅力真的像它所描述的那样吗?还是只存在于远景的海市蜃楼，只有当我们走近时才显露出它的挑战?

微服务的诱人承诺

还记得我们不得不与多个团队协调只是为了进行微小的调整吗？传统的单体架构是后勤方面的噩梦。

每次更改都需要理解代码库的大部分区域，与其他团队同步，并希望一个小的调整不会引发多米诺骨牌效应。

但微服务打开了新大门：突然之间，团队可以独立开发他们的服务了。

例如，用户管理团队可以实施新的身份验证策略，而无需等待库存管理团队更新其产品列表方法。这种解耦不仅仅是在代码层面，它还延伸到了团队动态。

O’Reilly 的一项调查发现，采用微服务的组织在团队协作方面提高了63%。每个开发人员都成为其领域的大师（从字面上看，考虑到领域驱动设计实践）。

在我们之前的一个项目中，我记得“黑色星期五”大促销活动时引发的混乱。我们的单体应用难以应对大量涌入的用户，导致所有功能的性能下降，而不仅仅是结帐流程。

微服务很好地解决了这种不平衡的需求。你只需简单地在负载下扩展服务，而无需为整个应用程序过度配置资源。

想结账的用户激增？没问题，扩大结帐服务规模。

宣传视频病毒式传播？没问题，提升媒体服务，不影响触及其他服务。

思科的一项案例研究显示，使用相同数量的资源的情况下，使用微服务架构设计的应用程序可以处理多达 20%的负载。

不那么迷人的现实

虽然许多人认为微服务是解决软件开发问题的灵丹妙药，但作为一名远程开发人员，我对这种架构风格的尝试经常感觉像打开了潘多拉的盒子。

在虚拟茶水间的闲聊和一行行代码之外，这个故事总是充斥着无数希望、频繁的正面交锋以及相当多的启示。

当我将我的第一个项目过渡到微服务时，我突然意识到，「将一个应用程序拆分为多个服务并不是简单的“分而治之”」。

随着拆分而来的是管理这些离散服务的责任。有一次，我部署了一个新的微服务，突然间，系统的其他部分失去了对它的跟踪——这是分布式系统中服务发现（Service Discovery）的臭名昭著的挑战。

此外，数据一致性也成为一场艰苦的战斗。

我再也不能依靠单个数据库事务来确保一切正常。因为每个服务都在管理自己的数据，我发现自己陷入了分布式事务的泥潭之中。

然后是失败。当一项服务失败时，连锁反应通常会导致其他服务发生级联故障。
理论上让服务进行通信，听起来很简单。

但问题是：分布式系统引入了延迟。

一天晚上，我正在调试一个异常缓慢的操作，却意识到罪魁祸首是服务之间的大量同步调用。等待下一个请求的次数增加了。

这需要改变战略。

虽然通过事件进行异步通信减轻了一些痛苦，但它也带来了挑战，例如确保事件的顺序。
被吹捧的模块化承诺往往与性能相悖。虽然微服务可以简化流程，但与传统的单体应用相比，它们也可能导致通信延迟。

噩梦循环：部署混乱

作为 CI/CD 的坚定倡导者，部署单个服务的承诺感觉就像一个梦。

但现实很不一样。最初的几天尤其混乱。

使用多个管道时，一个服务中的更改有时需要与其他服务进行协调。还记得你每天都为之头疼的版本兼容性问题吗?有了微服务，跟踪哪个版本的服务A与服务B兼容成为了一种日常仪式。

我开始怀念单体架构了

带有一系列服务和数据库阵列的微服务，常常感觉就像一块不断移动的拼图。有很多个晚上，我发现自己由于无法预见的集成问题而恢复代码，或者梳理日志试图找到哪个服务是薄弱环节。

与巨石时代形成鲜明对比的是，在铁板一块时，变化尽管规模较大，但具有一定的可预测性。
工作流程是线性的，那么部署呢？好吧，他们感觉更受控制了。

如果你曾经尝试通过一串 Slack 消息来传达一个复杂的想法，你就会欣赏直接沟通的益处。与此类似的，在单体架构中，模块之间的进程内通信的简单性是直接、无缝的，并且通常被认为是理所当然的。没有网络调用，没有延迟，没有丢失请求。一切都在应用程序的范围内正常工作。

使用微服务，服务间通信感觉就像试图与分布在各大洲的团队成员进行 Discord 语音聊天，每个人都在与自己的互联网困境作斗争。

当然，这是可行的，但这些小问题会让你怀念一切都在一个屋檐下的时光。当公司要求他们的开发人员回办公室坐班时，我理解了：它确实有它的好处，尤其是在即时沟通方面。

权衡：我们得到了什么，失去了什么

微服务的主要优势之一是能够专注于特定的功能。我记得我被分配到一个专门负责用户身份验证的团队。解耦的特性使我们能够完善机器中的一个齿轮。

不久前，我们的单体应用中的一个小模块故障导致了严重的中断。对于微服务，每个服务都充当其隔离的故障点。我见过一些特定微服务出现宕机的实例，但多亏了架构，整个应用程序得以继续运行，用户对此几乎没有感知。

当单体更好时

管理微服务感觉就像同时处理十几个Slack频道。每个服务都有自己的日志记录、监视和部署过程。相比之下，单体架构有一个固定的流程。

微服务通常意味着多个数据库。虽然这看起来很棒，但确保数据一致性却是一场噩梦。在单体架构时代，一个数据库意味着一致性。这就像在 Discord 中有一个线程，每个人都在更新。我经常发现自己怀念这种统一性提供的便利。

然后是整体调试。

还记得尝试通过相互连接的微服务跟踪bug吗？这就像追溯无数的 Discord 对话来找到一条消息。但在单体架构的设置中，错误日志是集中的，因果关系更加清晰。

总结：微服务之旅中的反思

当我回顾自己在微服务领域的尝试时，我发现这条道路充满了挑战、得失和可以从中学习收获的宝藏。以下是我在微服务之旅中获得的3个主要收获。

「1. 明智地接受复杂性」深入微服务不仅仅是一个技术决策——这是对复杂性的承诺。有时，我们会觉得自己只是为了顺应潮流而打破了一个体系。并非每个应用程序都需要由相互连接的服务组成的网络。正如Sam Newman在《构建微服务》中提到的那样，架构需要一定的先决条件，如果没有这些先决条件，它可能会矫枉过正。

「2. 灵活性是有代价的」是的，微服务承诺了灵活性，但要实现这一点，也需要付出沉重的代价——不仅在基础设施方面，而且在认知负荷方面。每项服务都有自己的领域，需要专门的关注。

「3. 没有放之四海而皆准的方法」架构决策不能脱离业务需求。灵活的初创公司的需求与传统的企业应用程序截然不同。虽然经典案例研究（例如 Netflix 著名的微服务转型）很有启发性，但必须认识到，适用于一个人的方法不一定适用于所有人。

变身为技术弄潮儿可能很诱人。成为科技领域重大变革的组成部分有一定的吸引力。但作为代码的守门人，我们需要抵制盲目接受趋势的诱惑。批判性评估、理解趋势背后的“原因”，并权衡其与我们的特定背景的相关性至关重要。

Slack 消息、GitHub 存储库和 Discord 讨论已成为我们许多远程开发人员的新饮水机。在各种噪声中，让我们记住定期聚焦，反思我们的选择，并确保我们不只是追逐趋势，而是有目的地制定经得起时间考验的解决方案。

芋道源码 —— 纯源码解析博客

微服务是个坏主意吗？