【翻译】微服务和分布式对象第一法则

本文源自 Martin Fowler 的 Bliki 上 2014 年的文章Microservices and the First Law of Distributed Objects

当我写《企业应用架构模式》一书时,我提出了一个我称之为分布式对象设计第一法则:“不要分布你的对象”。最近几个月业界对微服务的热情增加,让一些朋友对在微服务场景下对这一法则产生疑问,并且如果法则仍然成立,为什么我还要赞同微服务。

非常重要的一点就是我在第一法则中用了“分布式对象”的说法。它反映了一个在 90 年代末 00 年代初相当流行但此后(正确地)失宠的想法。分布式对象的想法是你可以设计对象并在进程内或远程选择使用相同的对象,远程则指的是在同一台机器的另外一个进城里,或者不同的机器里。比较聪明的中间件,比如,DCOM 或者一个 CORBA 实现,将会处理进程内或者远程之间的差别。因此你可以把你的系统拆分成以多个独立的进程来设计。

我对分布式对象概念的反对意见是:尽管逆可以在对象边界内封装许多东西,但逆不能封装远程/进程内的区别。 进程内函数调用很快并且总是成功(因为任何异常都是由于应用程序造成的,而不仅仅是由于进行调用的事实)。 但是,远程调用速度要慢几个数量级,并且由于远程进程或连接失败,调用总是有失败的可能。

module-calls.png

这种差异的结果是 API 的设计方式不同。 进程调用可以是细粒度的,如果你想要 100 个产品价格和库存,你可以调用你的产品价格函数 100 次,另外 100 次调用库存。 但是,如果该功能是一个远程调用,你最好将所有这些批处理在到一个调用中实现,一次调用所有 100 个价格和库存。 这会导致产品对象的界面有很大差异。 因此,你不能采用相同的类(主要是和接口相关)并以进程内或远程方式透明地使用它。

与我交谈过的微服务倡导者非常清楚这种区别,而且我还没有听到他们谈论进程内/远程调用的透明性。 所以他们并没有试图做分布式对象试图做的事情,因此不违反第一定律。 相反,他们提倡通过 HTTP 或轻量级消息和文档进行粗粒度交互。

所以本质上,我对分布式对象的看法和微服务的倡导者们对微服务的看法并不矛盾。 尽管存在这种基本的非冲突,但现在还需要提出另一个问题。 微服务意味着小型分布式单元通过远程连接进行通信,这比单体应用要多得多。这不违反第一定律的精神,即使它符合它的字面意思吗?

虽然我承认有正当理由为许多系统进行分布式设计,但我确实认为分布式是复杂性的助推器。 粗粒度的 API 比细粒度的 API 更尴尬。 你需要决定如何处理远程调用失败以及一致性和可用性的后果。 即使你通过协议设计最小化远程调用,仍然需要更多地它们的性能问题。 在设计单体应用时,你必须担心模块之间的职责划分,而对于分布式系统,你必须担心模块之间的职责分配和分布因素。

虽然小型的微服务确实更加简单,但我担心这会将复杂性推向服务之间的通信,由于通信的不明确,因此更难发现问题。 当你必须跨越远程边界进行重构时,会更加困难。 微服务倡导者吹捧你会从异步通信中降低耦合,但异步是另一个复杂性助推器。千篇一律的扩展允许你在不增加分布式复杂性的情况下处理海量请求。

因此,我对分布式持谨慎态度,我是倾向整体设计。 鉴于此,为什么我要花费大量精力来描述微服务并支持倡导它的同事? 答案是因为我知道我的直觉并不总是正确。我不能否认许多团队已经采用了微服务方法并取得了成功,无论是像 Netflix 和(可能)亚马逊这样的知名公共案例,还是我在 Thoughtworks 内外都与之交谈过的各种团队。 我天生就是一个经验主义者,相信经验证据胜过理论,即使这个理论比我的直觉要好得多。

并不是说我认为这件事已经有定论了。在软件交付中,成功是一件很难定义的事情。尽管像 Netflix 和 Spotify 这样的组织已经大肆宣传他们早先在微服务上的成功,但也有像 Etsy 或 Facebook 这样的例子在单体架构上取得了成功。无论团队认为自己使用微服务多么成功,唯一真正的比较是违反事实的——如果他们使用单体的方式构建应用会更好吗?微服务方法只出现了相对较短的时间,所以我们没有太多证据来自十年前的遗留微服务架构。但可以将微服务与我们非常不喜欢的那些古老的单体应用进行比较。并且可能存在我们尚未确定的因素,这意味着在某些情况下单体应用更好,而其他情况则有利于微服务。鉴于在软件开发中收集证据的困难,即使在多年过去之后,也很可能不会做出有利于其中一个或另一个的令人信服的决定。

鉴于这种不确定性,像我这样的作家能做的最重要的事情就是尽可能清楚地传达我们认为我们已经学到的教训,即使它们是矛盾的。 读者将自己做出决定,而作为作家,我们的工作是确保这些决定是明智的,无论他们落在架构决策的哪一边。

(完)

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 144,247评论 1 305
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 61,830评论 1 258
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 95,531评论 0 214
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 41,345评论 0 183
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 49,160评论 1 260
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,936评论 1 178
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,538评论 2 275
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,291评论 0 168
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 29,162评论 6 237
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,654评论 0 214
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,401评论 2 217
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,747评论 1 232
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,297评论 1 33
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,206评论 2 213
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,670评论 3 213
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,661评论 0 9
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,089评论 0 169
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,677评论 2 233
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,819评论 2 237

推荐阅读更多精彩内容