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

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

我们 原告知，通过将巨大无朋分割成更小、自包括的独立服务，我们将 获得 无可 比较的可 扩充性、 麻利性和可 保护性 。这听起来是如此 圆满 。

更快的部署？√

独自 扩充？√

独立团队开发？√

然而，当我把单体架构切换成微服务时，我不禁想晓得：微服务的魅力真的像它所 形容的那样吗?还是只存在于 蓝图的 子虚乌有，惟独当我们走近时才 露出出它的 挑战?

1、微服务的 迷人承诺

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

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

但微服务 打开了新大门：蓦地中间，团队 能够独立开发他们的服务了 。

例如，消费者治理团队 能够 施行新的身份验证策略，而无需期待库存治理团队更新其产品列表 步骤 。这种解耦不只仅是在代码层面，它还蔓延到了团队动态 。

OReilly 的一项 考查发现，采纳微服务的组织在团队 合作方面 遍及了63% 。每个开发人员都成为其领域的 大师(从字面上看，考量到领域驱动设计 实际) 。

在我们之前的一个 名目中，我记得“黑色礼拜五”大促销 运动时激发的 混乱 。我们的单体 利用难以 应答大量涌入的消费者，招致全部 性能的性能 降落，而不只仅是结帐流程 。

微服务很好地解决了这种不 均衡的需求 。你 只有 容易地在负载下 扩充服务，而无需为整个 利用程序 适度配置资源 。

想结账的消费者激增？没问题， 扩充结帐服务规模 。

宣传视频病毒式 流传？没问题， 晋升媒体服务，不影响 波及 其余服务 。

思科的一项案例探究显示， 使用 雷同数量的资源的状况下， 使用微服务架构设计的 利用程序 能够 解决多达 20%的负载 。

2、不那么迷人的 事实

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

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

当我将我的第一个 名目过渡到微服务时，我蓦地意识到，将一个 利用程序拆分为多个服务并不是 容易的“分而治之” 。

随着拆分而来的是治理这些离散服务的责任 。有一次，我部署了一个新的微服务，蓦地间，系统的 其余 部分失去了对它的跟踪——这是 分布式系统中服务发现(Service Discovery)的 臭名远扬的 挑战 。

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

我再也不能 依附单个数据库事务来确保 所有 畸形 。因为每个服务都在治理自己的数据，我发现自己陷入了 分布式事务的泥潭之中 。

而后是失败 。当一项服务失败时，连锁 反响通常会招致 其余服务 产生级联故障 。

实际上让服务进行通讯，听起来很 容易 。

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

一天晚上，我正在调试一个 异样 迟缓的操作，却意识到罪魁祸首是服务中间的大量同步调用 。期待下一个 申请的次数添加了 。

这需求转变 策略 。

固然通过事件进行异步通讯减轻了一些 苦楚，但它也带来了 挑战，例如确保事件的顺序 。

被吹捧的模块化承诺一般与性能相悖 。 固然微服务 能够简化流程，但与传统的单体 利用相比，它们也可能招致通讯延迟 。

3、噩梦循环：部署 混乱

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

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

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

4、我开始 思念单体架构了

带有一系列服务和数据库阵列的微服务， 往往觉得就像一块不停移动的拼图 。有众多个晚上，我发现自己因为 无奈 预感的集成问题而 复原代码，或者梳理日志试图找到哪个服务是 薄弱环节 。

与巨石时代 构成鲜亮对照的是，在铁板一块时， 变迁 只管规模较大，但 存在 定然的可预测性 。

工作流程是线性的，那么部署呢？好吧，他们觉得更受操纵了 。

假如你曾经尝试通过一串 Slack 信息来 转达一个复杂的想法，你就会观赏直接沟通的 好处 。与此 类似的，在单体架构中，模块中间的 历程内通讯的 容易性是直接、无缝的，并且通常被认为是理所固然的 。没有网络调用，没有延迟，没有 迷失 申请 。 所有都在 利用程序的 规模内 畸形工作 。

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

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

5、 衡量：我们得到了什么，失去了什么

微服务的重要优势之一是 能够 专一于特定的 性能 。我记得我被 调配到一个专门负责消费者身份验证的团队 。解耦的 特点使我们 能够完善机器中的一个齿轮 。

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

6、当单体更好时

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

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

而后是整体调试 。

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

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

当我回忆自己在微服务领域的尝试时，我发现这条 路径 充斥了 挑战、得失和 能够从中学习 收成的宝藏 。以下是我在微服务之旅中 获得的3个重要 收成 。

1) 理智地 承受复杂性

深刻微服务不只仅是一个技术决策——这是对复杂性的承诺 。有时，我们会觉得自己只不过为了 适应潮流而 攻破了一个体系 。并非每个 利用程序都需求由 彼此衔接的服务构成的网络 。正如Sam Newman在《构建微服务》中提到的那样，架构需求 定然的先决条件，假如没有这些先决条件，它可能会矫枉过正 。

2)灵便性是有代价的

是的，微服务承诺了灵便性，但要实现这丝毫，也需求付出 沉重的代价——不只在 根底设施方面，并且在认知负荷方面 。每项服务都有自己的领域，需求专门的关注 。

3)没有放之四海而皆准的 步骤

架构决策不能脱离业务需求 。灵便的初创公司的需求与传统的企业 利用程序截然不同 。 固然经典案例探究(例如 Netflix 驰名的微服务转型)很有启发性，但必须 意识到， 实用于一个人的 步骤不 定然 实用于全部人 。

变身为技术弄潮儿可能很 迷人 。成为科技领域重大 改造的构成 部分有 定然的吸引力 。但作为代码的守门人，我们需求抵御盲目 承受趋向的 引诱 。批评性评估、 了解趋向背后的“缘由”，并 衡量其与我们的特定背景的 有关性至关重要 。

Slack 信息、GitHub 存储库和 Discord 探讨已成为我们许多远程开发人员的新饮水机 。在各种噪声中，让我们记住定期聚焦，反思我们的 取舍，并确保我们不只不过 追赶趋向，而是有 目标地 制订经得起 工夫考验的解决 方案 。

参考链接：https://medium.com/@PurpleGreenLemon/was-microservices-a-bad-idea-5e52edee1cff

免责声明：凡标注转载/编译字样内容并非本站原创，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。