曾几何时，我记得我的手指疯狂地敲打键盘，与庞大而杂乱的代码库搏斗。那是巨石的时代，代码就像古老的城堡一样，由一块块石头砌成一个令人印象深刻的庞然大物。
几年过去了，时代变了。开发人员口中的流行语变成了“微服务”。微服务革命——承诺成为我们的救世主。
我们被告知，通过将庞然大物分割成更小、自包含的独立服务，我们将获得无与伦比的可扩展性、敏捷性和可维护性。这听起来是如此完美。
❝
更快的部署？√
单独扩展？√
独立团队开发？√
❞
但是，当我把单体架构切换成微服务时，我不禁想知道：微服务的魅力真的像它所描述的那样吗?还是只存在于远景的海市蜃楼，只有当我们走近时才显露出它的挑战?
还记得我们不得不与多个团队协调只是为了进行微小的调整吗？传统的单体架构是后勤方面的噩梦。
每次更改都需要理解代码库的大部分区域，与其他团队同步，并希望一个小的调整不会引发多米诺骨牌效应。
但微服务打开了新大门：突然之间，团队可以独立开发他们的服务了。
例如，用户管理团队可以实施新的身份验证策略，而无需等待库存管理团队更新其产品列表方法。这种解耦不仅仅是在代码层面，它还延伸到了团队动态。
O'Reilly 的一项调查发现，采用微服务的组织在团队协作方面提高了63%。每个开发人员都成为其领域的大师（从字面上看，考虑到领域驱动设计实践）。
在我们之前的一个项目中，我记得“黑色星期五”大促销活动时引发的混乱。我们的单体应用难以应对大量涌入的用户，导致所有功能的性能下降，而不仅仅是结帐流程。
微服务很好地解决了这种不平衡的需求。你只需简单地在负载下扩展服务，而无需为整个应用程序过度配置资源。
想结账的用户激增？没问题，扩大结帐服务规模。
宣传视频病毒式传播？没问题，提升媒体服务，不影响触及其他服务。
思科的一项案例研究显示，使用相同数量的资源的情况下，使用微服务架构设计的应用程序可以处理多达 20%的负载。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
-
视频教程：https://doc.iocoder.cn/video/
虽然许多人认为微服务是解决软件开发问题的灵丹妙药，但作为一名远程开发人员，我对这种架构风格的尝试经常感觉像打开了潘多拉的盒子。
在虚拟茶水间的闲聊和一行行代码之外，这个故事总是充斥着无数希望、频繁的正面交锋以及相当多的启示。
当我将我的第一个项目过渡到微服务时，我突然意识到，
「将一个应用程序拆分为多个服务并不是简单的“分而治之”」
。
随着拆分而来的是管理这些离散服务的责任。有一次，我部署了一个新的微服务，突然间，系统的其他部分失去了对它的跟踪——这是分布式系统中服务发现（Service Discovery）的臭名昭著的挑战。
此外，数据一致性也成为一场艰苦的战斗。
我再也不能依靠单个数据库事务来确保一切正常。因为每个服务都在管理自己的数据，我发现自己陷入了分布式事务的泥潭之中。
然后是失败。当一项服务失败时，连锁反应通常会导致其他服务发生级联故障。
理论上让服务进行通信，听起来很简单。
但问题是：分布式系统引入了延迟。
一天晚上，我正在调试一个异常缓慢的操作，却意识到罪魁祸首是服务之间的大量同步调用。等待下一个请求的次数增加了。
这需要改变战略。
虽然通过事件进行异步通信减轻了一些痛苦，但它也带来了挑战，例如确保事件的顺序。
被吹捧的模块化承诺往往与性能相悖。虽然微服务可以简化流程，但与传统的单体应用相比，它们也可能导致通信延迟。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/yudao-cloud
-
视频教程：https://doc.iocoder.cn/video/
作为 CI/CD 的坚定倡导者，部署单个服务的承诺感觉就像一个梦。
但现实很不一样。最初的几天尤其混乱。
使用多个管道时，一个服务中的更改有时需要与其他服务进行协调。还记得你每天都为之头疼的版本兼容性问题吗?有了微服务，跟踪哪个版本的服务A与服务B兼容成为了一种日常仪式。
带有一系列服务和数据库阵列的微服务，常常感觉就像一块不断移动的拼图。有很多个晚上，我发现自己由于无法预见的集成问题而恢复代码，或者梳理日志试图找到哪个服务是薄弱环节。
与巨石时代形成鲜明对比的是，在铁板一块时，变化尽管规模较大，但具有一定的可预测性。
工作流程是线性的，那么部署呢？好吧，他们感觉更受控制了。
如果你曾经尝试通过一串 Slack 消息来传达一个复杂的想法，你就会欣赏直接沟通的益处。与此类似的，在单体架构中，模块之间的进程内通信的简单性是直接、无缝的，并且通常被认为是理所当然的。没有网络调用，没有延迟，没有丢失请求。一切都在应用程序的范围内正常工作。
使用微服务，服务间通信感觉就像试图与分布在各大洲的团队成员进行 Discord 语音聊天，每个人都在与自己的互联网困境作斗争。
当然，这是可行的，但这些小问题会让你怀念一切都在一个屋檐下的时光。当公司要求他们的开发人员回办公室坐班时，我理解了：它确实有它的好处，尤其是在即时沟通方面。
微服务的主要优势之一是能够专注于特定的功能。我记得我被分配到一个专门负责用户身份验证的团队。解耦的特性使我们能够完善机器中的一个齿轮。
不久前，我们的单体应用中的一个小模块故障导致了严重的中断。对于微服务，每个服务都充当其隔离的故障点。我见过一些特定微服务出现宕机的实例，但多亏了架构，整个应用程序得以继续运行，用户对此几乎没有感知。
管理微服务感觉就像同时处理十几个Slack频道。每个服务都有自己的日志记录、监视和部署过程。相比之下，单体架构有一个固定的流程。
微服务通常意味着多个数据库。虽然这看起来很棒，但确保数据一致性却是一场噩梦。在单体架构时代，一个数据库意味着一致性。这就像在 Discord 中有一个线程，每个人都在更新。我经常发现自己怀念这种统一性提供的便利。
