微服务 英文原文：Microservices and the First Law of Distributed Objects

当我写 企业应用程序架构的模式 时，我创造了我所谓的分布式对象设计第一定律：“不分发你的对象”。近几个月来，微服务引起了很多人的兴趣，导致一些人质疑微服务是否违反了这项定律，如果是，我为什么赞成他们？

在第一个定律声明中，我使用短语“分布式对象”。这折射出一种观点，这种观点在90年代末00年代初期相当流行，但从那以后便（理所当然）失去了青睐，即你可以设计对象，并选择在进程或远程使用这些相同的对象，其中远程可能意味着同一机器中的另一进程，或在不同的机器上。聪明的(Clever)中间件（如 DCOM 或 CORBA 实现）将处理内部/远程区分，因此你的系统可以被编写，并且你可以将其分解为进程，而这与应用程序的设计无关。

我反对分布式对象的概念，因为，尽管你可以在对象内部进行封装，但你无法封装远程和进程内调用的差异。进程内的函数调用很快速，成功率高（因为任何异常都是由应用程序而不仅仅是由调用引起的）。 然而，远程调用的速度慢了几个数量级，并且由于远程进程或连接中的故障，远程调用总是有失败的可能。

这种差异会导致 API 使用准则的不同。在进程内调用可以是细粒度的，如果你想获得 100 个产品的价格和存货量，你可能会分别调用 100 次产品价格功能，再调用 100 次获得其存货量。但是，如果该功能是远程调用，你最好将所有这一切批处理为一个调用，一次请求所有产品的价格和存货量。因为这样会产生与产品对象迥异的接口。因此，你不能使用相同的类（主要是关于接口层的），还要以透明方式在进程内或远程方式之前切换。

微服务倡导者非常清楚这种区别，我从未听他们谈论过进程内/远程的透明度。因此他们没有重蹈分布式对象的覆辙，也就没有违反第一定律。相反，他们倡导通过 HTTP 或轻量级消息来传递与文档进行的粗粒度交互。

因此，从本质上来说，我发表的对于分布式对象和微服务倡导者的观点并不相矛盾。尽管如此，此处还有另一个问题有待商榷。微服务意味着使用通过远程连接进行通信的小型分布式单元的数目远远超过单片机。即使它满足第一定律的字面意义，但符合第一定律的核心价值吗？

我认为分布式是一个复杂性的助推器。粗粒度的 API 比细粒度的 API 更难以使用。远程调用的失败时，你需要想出处理方法，并找出其对一致性和可用性的影响。即使通过协议设计将远程调用的影响降至最低，你仍然需要考虑与之相关的性能问题。当设计一个单片机架构时，你必须考虑模块之间的责任分配问题；使用分布式系统时，你必须考虑模块和分布式因子之间的责任分配问题。

虽然小型微服务更容易理解，但可能是将复杂性传递到服务之间的互连上，因此更难以弄清楚什么时候出错。当你必须跨越远程边界做重构时，会变得更加困难。微服务倡导者降低对异步通信的耦合度，但异步是另一个复杂度的助推器。 Cookie-cutter scaling 允许你在不增加分布式复杂度的前提下处理大流量数据。

因此，比起分布式我更倾心单片式设计。那为什么我要耗费精力来描述微服务并给予支持它的同事以支持呢？因为直觉也会出错。许多团队已经采用了微服务的方法，并已取得成功，如 Netflix，亚马逊，以及 ThoughtWorks 内外的各个团队。我本质上是一个经验主义者，即使理论很具说服力，但依然相信经验胜过理论。

并不是说我认为问题已经解决了。在软件交付中，是否成功（交付）难以识别。虽然像 Netflix 和 Spotify 这样的组织已经使用微服务获得了早期的成功，但也有像 Etsy 或 Facebook 这样的例子，它们取得了诸多基于单片机架构的成功。无成功使用微服务的团队，有时也会想是否使用单片机能取得更好的效果？微服务方法出现时间相对较短，所以我们缺乏充足的例证将传统微服务架构与单片机架构做对比。并且在某些未知的情况下，单片机架构可能更适用。鉴于在软件开发中收集证据的困难性，即使很多年过去了，也很可能不会有一个令人信服的判断来支持微服务或单片机。

答案不是固定的。作为作者，最重要的就是将我们所学的知识清晰地传达给读者，即使观点相互矛盾，我们也要将逻辑理清。读者会做出自己的选择，作者的任务是不管读者做出何种决定，都要确保他们的观点是经文章启发的。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务