【译】Monolith first —— Martin Fowler 对于微服务架构的看法
转载文章，文章经 LiteCodes 授权，转载至本博客。
整体架构先行（Monolith first）
在我所听说的使用微服务架构（Microservices Architecture）的团队里，有这么一些共性：
- 绝大多数微服务的成功案例，都是从整体架构（Monolith）开始的。并且由于整体架构过于庞大，导致架构无法继续支撑。
- 绝大多数我所听说的系统，如果从一开始就使用微服务架构，最终都遇到了很严重的问题。
这个规律导致我的同僚们认为，并不应该从项目一开始就使用微服务架构，即便你能够保证你的应用足够大，以至于使用微服务架构是值得的。
微服务是一个很有用的系统架构，但是即便是它的支持者，也会承认这将导致一个巨额的微服务额外代价，这意味着，只在极为复杂的系统中微服务架构才能发挥作用。这巨额代价的本质实际上是对一系列服务进行管理的开销，对于简单的应用来说，整体架构反而更加有利。这成为了整体架构先行（monolith-first）策略的一个有力的论据——在创建一个新的应用的时候，即便你认为在将来它将更适合采用微服务架构，你在最初仍然应该先采用整体架构。
第一个原因是，这是一个典型的 YAGNI（You Aren’t Gonna Need It）。当你开始创建一个新应用的时候，你怎么知道他会对你的用户有用？你的应用可能设计的很难被扩展，却能出色的完成任务。但总比你得到一个能够轻易被扩展，却无法正常工作的系统强得多。就像我们所建议的，通常，检验一个想法是否有效的最好的方法，是构建一个最简单的版本，并且看他能做到多好。在项目建立初期，速度（以及反馈周期）应该是你最优先要考虑到的，所以微服务带来的代价是你应该极力避免的。
微服务的第二个问题是，只有当你提出一个良好的、服务边界稳定的设计，他才能良好的运行。这就意味着，你需要拟定一套正确的边界上下文。服务间的功能性重构相比整体架构而言都将变得更加复杂。但是，即便是经验丰富的架构师，在熟悉的领域，在一开始也很难制定出完全正确的系统边界。通过采用整体架构先行设计，在微服务架构前，能够先找出正确的系统边界。并且，先进行整体架构设计能够给你充足的时间，让你做好细粒度微服务的前提准备。
我听说过很多种方法去进行整体架构先行的架构策略。理论上的做法是，小心谨慎的进行整体架构设计，无论是 API 边界还是数据存储，都要注重模块化。专注于这些，相较于迁移至微服务架构，要简单的多。但是现在并没有足够的案例证明这种方法能够行之有效。[1]
更常见的方法是，开始采用整体架构，然后逐渐将边缘部分剥离为微服务。这种方法将会在微服务架构的核心处，留下一个独立的整体架构。但相较于大量出现的微服务而言，整体架构部分处于相对稳定状态。
我还见过一种方法，在项目开始初期只做一些粗粒度的服务，这些粗粒度服务要比期望的最终服务单元大一些，通过这些粗粒度的服务来习惯多服务合作的模式。这种方式降低了内部服务重构导致的代价。当服务边界稳定后，再将其拆分为更细粒度的服务。[2]
虽然我所接触的人大多倾向于整体架构先行的方式，但也并不是所有人都这么认为。这些人反对的理由是，从一开始就采用微服务架构，能够让你更快的适应微服务架构的开发节奏。如果要构建一个模块化的整体架构，并且需要让其在未来能够很容易的拆分为微服务，将会付出较大乃至极大的代价。如果从一开始就采用微服务架构，团队中的每个人从一开始就习惯于在一个个独立的小团队中进行开发，并且，当你需要扩张时，独立的服务边界将会让其变得更加简单。如果能够提前制定出足够稳定的系统边界，这将具有极强的可行性。虽然我没有足够的证据，但是我依然认为，如果你没有合理构建微服务系统的经验，不要一开始就采用微服务架构。
我还没有足够的案例来决定是否使用整体架构先行的策略。我们对微服务的认识尚属早期，我们针对微服务架构案例的学习也相对较少。所以任何人针对这个话题的建议都只是临时性的，大家的争论也只是出自自信而非经验。
扩展阅读
Sam Newman 在一个新项目中考虑使用微服务架构的案例。
注解
- 你无法假设你能将任意一个系统成功的迁移至微服务架构。大多数系统，其模块间都具有太多的依赖，以至于无法合理的进行分解。我见过很多案例，都是在试图分解一个整体架构时出现问题，以至于很快陷入一片混乱。我也见过一小部分案例，逐步设计微服务架构获得了成功——但是这些成功案例，都需要在一开始便有一个相对良好的模块化设计。
- 严格来讲，我认为这种方法应该成为“半整体架构”（duolith），但我认为这种方法和整体架构先行策略异曲同工：从粗粒度开始，当对其有充分的认知后再进行拆分。
鸣谢
在此我借鉴了许多我同僚们的想法，他们包括：James Lewis，Sam Newman，Thiyagu Palanisamy，以及 Evan Bottcher。Stefan Tilkov 在早期草稿中的评论，对我清楚地表达自己的想法起了至关重要的作用。Chad Currie 在上图中绘制了可爱的龙。Steven Lowe，Patrick Kua，Jean Robert D’amore，Chelsea Komlo，Ashok Subramanian，Dan Siwiec，Prasanna Pendse，Kief Morris，Chris Ford，和 Florian Sellmayr 在我们的内部邮件中对这篇文章提出了自己的见解。
最后，感谢 Martin Fowler 大师发表了这篇文章，为软件架构之路领航。（译者注）
