微服务不是技术，是组织边界
What Even Are Microservices?
微服务常被当作架构好坏的代名词，但几乎没人能说清它到底是什么。文章指出，微服务的核心并非技术细节，而是解决组织协作问题。当团队规模扩大，独立开发、快速发布的需求催生了微服务，它让技术边界匹配组织边界。然而，这种架构也带来了分布式系统的代价：网络延迟、版本协调、决策分散。作者强调，微服务不是万能药，若问题纯属技术层面，盲目拆分只会让系统更复杂。真正的价值在于理解其本质：它是组织工具，附带技术后果。
微服务并非主要是一种技术抽象，而是组织边界的映射。
HN 评论区
72- turnersauce
这基本上就是康威定律（Conway's Law）的实践体现：微服务并非因为技术边界而被创造，而是因为组织需要团队边界而自然涌现。
- kgeist
据我的经验，微服务宣称能解决的几乎所有问题，其实也可以用模块化单体（modular monolith）加上一些强制规则的工具来解决（比如，规定一个模块不能窥探另一个模块的内部实现，必须绕过约定的“干净”公共接口；仅这一点就能解决大部分意大利面代码的问题）。
单体架构难以轻松提供的有两点：
* 使用不同的框架、语言等。但据我观察，一个团队同时使用多种编程语言的情况其实很少见。通常只有少数对性能极其敏感的服务需要用另一种语言编写（比如用 Rust 写一个代理，其余部分用 Python）。对于这种情况，我更喜欢一种架构：一个主单体加上几个高性能的卫星服务。这完全没问题。
* 在某些场景下更优化的扩展性。假设我有一个处理文件的模块，它可以占用所有可用的 CPU。我可能希望把它放在另一个节点的独立容器里，以免处理过程 destabilize 核心 Web 服务器。从技术上讲，单体架构也支持这一点，只需让单体以不同模式运行（比如通过类似 `--image-process` 的标记），然后以同样的方式将其调度到另一个节点上。唯一的缺点是，它可能会为那些不会用到的额外二进制文件或脚本占用比必要更多的 RAM。
我还漏掉了什么吗？
- mrkeen
> 在单体中，很容易回答诸如“我们交付了哪些依赖？”或“这段代码是否还在使用？”之类的问题。静态分析通常就能告诉你。一旦代码分散到几十个独立的服务中，获取这些答案就变得困难得多。
我得出了相反的结论。在单体中，别人可能希望代码保留在代码库中。我不想问每个人。责任分散等于无人负责，代码也就原封不动地留在那里。
在微服务中，我发布一个接口，只要它按承诺完成工作，我就自由地推翻其背后的所有实现。当然，知道公共路由是否仍在使用仍然是一个问题，因此你需要最低限度的指标或日志记录，然后才能退役某个端点。
- eloisant
我觉得“单体”与“微服务”之间的讨论是一种虚假的二元对立。
对于一家大型软件公司来说，你不必交付一个巨大的单体 behemoth，但也不必把微服务划分得如此之小，以至于一个 3 人的团队要管理 10 个服务。
你可以有“大小适中”的服务。我不喜欢称它们为“微”服务，因为它们可以相当大并做很多事情，只要将它们放在单个服务中是合理的即可。
- dspillett
人们常在还没获得前 100 个用户时，就用来架构自己成为下一个 Amazon 的尝试。这也常用于简历镀金（CV padding）。
对于那些真正需要其所提供能力的团队和项目来说，这确实是一种有用的抽象、关注点/依赖分离、扩展等方法。