拆分还是整合：单体和微服务的技术抉择( 二 ) _微服务

另一个可能的痛点是未能适当地将服务与领域对齐。我曾见过一些微服务应用程序与技术对齐但没有与业务需求对齐，导致存在过多的服务和一个不必要的难以管理的系统。将服务分得太小，不必要地增加了系统的复杂性和难度，这是一个问题。
如果你无法正确地将架构与领域对齐，那么无论使用单体还是微服务，都将遇到严重的问题 —— 随着服务数量的增加，这些问题将会被大幅放大。微服务既能带来性能方面的伸缩性，也会放大已经存在的问题。
这只是一个伸缩性问题吗？

"如果你无法应对单体的复杂性，凭什么认为微服务就是良方？"
—— Simon Brown (来源)

微服务的真正问题是它们只是放大了已经存在的问题吗？
一个糟糕的微服务实现比糟糕的单体架构糟糕 X 倍（X 是你的分布式应用程序中服务的数量）。随着分布式应用程序中通信路径的指数级增加，情况甚至更糟。
如果你没有合适的工具、技术、自动化、流程和组织来应对单体，那么你凭什么认为你可以处理好微服务？

文章插图
微服务不仅带来性能和开发方面的可伸缩性，也带来了困难程度的伸缩。如果你在构建和维护单体架构时感到困难，转向微服务也并不会给你带来任何好处。
微服务应用程序也是一种单体，只是服务的数量增加了、服务的大小变小了而已。如果疲于应对单体架构，却认为微服务是良方，那么请再三思。
我认为微服务不仅在性能和开发方面带来了可伸缩性，也带来了困难程度的伸缩。微服务有它的优点，但这些优点并不是完全免费的。
微服务的成本

【拆分还是整合：单体和微服务的技术抉择】"微服务并非免费午餐。"
—— Sam Newman (摘自“Building Microservices”)

微服务到底是什么？为什么我们要将应用程序划分为独立的服务？
微服务有许多众所周知的好处：

可伸缩性
- 性能
- 开发团队
容错性
独立（和较低风险）部署，支持快速开发
开发者赋权
可丢弃（Disposability）
管理复杂性

但这些好处并非微服务的全部，我们也需要为此付出成本：

更高水平的技术技能
更好的自动化、管理和可观察性系统
处理可伸缩性难题

对于任何一种工具、技术、架构或任何我们想要使用的东西，我们必须问自己一个问题：收益是否超过了成本？如果收益超过了成本，你将在使用这些技术时获得良好的体验。如果没有，你将在痛苦的时光中度过。
管理复杂性

"微服务支持大规模、复杂应用的持续部署。"
—— Chris Richardson (来源)

微服务有许多优势，但我们使用它们的真正理由是，它们可以帮助我们管理应用程序日益增长的复杂性。
没错，微服务不是复杂性的根源，而是解决复杂性的方法。
所有的应用程序都将变得复杂，即使是单体也无法避免。微服务为我们提供了将复杂性分解为更小、更简单、更易管理的构建块的工具。

文章插图
微服务通过将复杂性分解为简单而隔离的部分来帮助我们管理复杂性。我们也可以在单体架构中做到这一点，但你需要一个纪律严明和积极主动的团队来保持设计的完整性，不至于变得一团糟。
我们可以使用微服务来抽象和将软件组件化。当然，我们也可以在单体架构中做到这一点，但微服务还为我们提供了牢固的组件边界，更不用说其他优势了，如独立部署和故障隔离。
可能性频谱