Monolith或Microservices：到底该选择哪一个？

【摘要】到底该选择Monolith还是Microservices呢？业界没有一个统一标准的答案，本文通过分析比较Monolith和Microservices的优缺点，给出了在哪些情况下，建议选择Monolith；哪些情况下，建议选择 Microservices。以下是译文。

对于初创企业来说，传统观点建议从monolith（单体应用）开始，但是在有些情况下，是否应该从微服务（microservices）开始呢？在决定到底以monolith或微服务中哪一个开始时，与数十位CTO面谈后，提出了关键的考量因素。

挑战传统的观点

我的好朋友Darby Frey最近在Gamut公司担任高级平台工程领导者的新角色后，开始了一个新建的项目。尽管在他以前的公司Belly是从monolith开始的，但是他发现，在适当的情况下，以monolith开始并不总是最好的选择。

Darby告诉我：“确实，受以前公司的影响，我的思想很大程度上停留在早期[在新公司的时候]。”

在Belly，Darby及其团队把monolith分解成了一个相当大的微服务架构，并设法使它达到了一个很好的境地，但是只有经过几个月的考验和磨难后，才迁移到微服务。

凭借这种新鲜的经验，他在Gamut的新项目中更加谨慎地使用微服务。

他说：“我坚定地成为Monolith团队的一员。只是构建一个单一的应用程序，如果开始感到痛苦的话，那就把东西拆开。”

尽管这是一个新建的项目，Darby的团队很小，而且完成时间很有挑战性，所以在表面上看来，monolith似乎是一个显而易见的选择。

“[但是通过这个新项目]，我急于不要重复过去的错误。”

于是，他发现自己面临着一个大家都在为之挣扎的决定，应该从monolith开始呢还是从微服务开始呢，何去何从？

评估Monolith的优缺点

Monolith不是应该被遗留在过去的过时的架构。在某些情况下，monolith是理想的。我和Scaylr的工程部门负责人，前Google员工Steven Czerwinski进行了交流，以便更好地理解这一点。

他解释说：“即使在Google使用微服务有一些积极的体验，我们（在Scaylr）走的是一条monolith的路线，因为拥有一个monolithic服务器意味着减少相当于两个工程师的工作量。”

Monolith的优点：

• 更少的横切关注点：monolithic架构的主要优点是大多数应用程序通常都有大量的横切关注点（关于横切关注点，可以看看这篇文章：http://blog.csdn.net/caterpillar_here/article/details/753473），如日志记录，速率限制以及审计跟踪和DOS保护等安全功能。当所有这些都在同一个应用程序运行时，很容易将组件连接到这些横切关注点。
• 较少的运营开销：拥有一个[大]应用程序意味着只有一个应用程序需要设置日志记录，监控和测试。部署通常也不那么复杂。
• 性能：由于共享内存访问比进程间通信（IPC）要快的多，因此也可能具有性能优势。

Monolith的缺点：

• 紧密耦合：随着应用程序的发展，Monolithic应用程序服务往往会紧密耦合和纠缠在一起，因此很难将一些服务分离开来，例如独立扩展或代码可维护性的服务。
• 更难理解：Monolithic架构也更难理解，因为可能有依赖性，副作用，以及魔力，当查看一个特定的服务或控制器时，这些并不明显。

拥抱微服务

有时，微服务是团队的最佳选择。Algolia的首席技术官Julien Lemoine就此指出：

“我们总是始于一种微服务的方法。主要目标是能够使用不同的技术来构建服务，原因有两个：

1）想为每项服务使用最好的工具。搜索API在最底层进行了高度优化，C++是用于优化的完美语言。也就是说，使用C++开发所有的程序代码是浪费生产力，尤其是构建仪表盘，C++只需要用于写底层的代码！

2）想要最好的人才，只使用一种技术将会限制我们的选择。这就是为什么我们在公司里有不同语言的原因，当想要毫秒级地优化所有东西的时候，Go没有C++完美，但是当性能仍然是关键时，Go是完美的语言（每天处理几百万兆字节的日志，使用Ruby或python会浪费CPU资源）”

如果团队已经准备好了，从微服务开始是明智的，因为它使你能够从一开始就适应在微服务环境中开发的节奏。

微服务的优点

• 更好的组织：微服务体系架构通常组织得更好，因为每一个微服务都有一个非常具体的工作，而不关心其它组件的工作。
• 解耦：解耦服务也更容易重构和重新配置，以服务于不同应用程序的目的（例如，为Web客户端和公共API提供服务）。它们还允许在较大的集成系统内快速，独立地交付各个部件。
• 性能：在适当的情况下，微服务也可以具有性能优势，这取决于它们的组织方式，因为它可以分离热门服务，并可以独立于应用程序的其它部分进行扩展。
• 更少的错误：微服务通过在系统的不同部分之间建立一个难以跨越的边界来支持并行开发。通过这样做，你很难—或者至少比较难—做错误的事情： 亦即连接不应该连接的部分，那些需要连接的部分连接的太紧。

微服务的缺点

• 跨各个服务的横切关注点：在构建新的微服务架构时，可能会发现许多在设计时并未预料到的横切关注点。可能需要为每个横切关注点（即测试）产生单独模块的开销，或者将横切关注点封装在所有流量都被路由通过的另一个服务层。最终，即便是monolithic体系结构也倾向于通过外部服务层来传输流量，以实现横切关注点，但是通过monolithic体系结构，可以将工作成本推迟到项目更成熟为止。
• 更高的运营开销：微服务频繁地部署在它们自己的虚拟机或容器上，导致虚拟机扯皮工作的激增。这些任务通常使用容器小组管理工具自动化完成。

在启动时应用利弊

当在monolith和微服务之间做出选择时，首席技术官的决策经验提供了一个很好的思路：

是在你熟悉的领域吗？

Darby及其在Gamut的团队能够直接钻研微服务，因为他本人具有电子商务平台的经验，公司也对客户的需求有着丰富的理解。另一方面，如果他行走在一条陌生的道路上，那么monolith实际上可能是更安全的选择。

同样地，初创公司往往是从以前的公司所经历的痛苦中诞生的。在这些情况下，有时很明显，扩展将成为主要需求，尤其是在基于基础设施的服务中，比如云日志管理。

团队准备好了吗？

团队是否有微服务的经验？如果在下一年内将团队规模翻两番，那么微服务的理念是否适合这种情况呢？评估团队的这些维度对于项目的成功至关重要。

如果团队已经准备好了，从微服务开始是明智的，因为它使你能够从一开始就适应在微服务环境中开发的节奏。

基础设施如何？

实际上，需要基于云的基础架构，使微服务为你的项目工作。

“[以前]，会想从一个monolith开始，因为想部署一个数据库服务器。不得不为每一个微服务建立一个数据库服务器，然后向外扩展是一项艰巨的任务。只有一个技术精湛的庞大组织才能做到这一点，” Pantheon首席技术官David Strauss向我解释道。

“虽然今天有诸如谷歌云和亚马逊AWS之类的服务，但可以有许多部署微小服务的选择，而不必让每个项目都拥有持久层。”

评估业务风险

你可能会认为微服务是一个心怀大志的高科技公司启动的“正确”方式。但微服务会带来业务风险。David Strauss解释说：

“很多团队在最初的时候过度建设项目，每个人都希望自己的创业将成为下一个独角兽，因此应该用微服务或其它一些超级可扩展的基础架构来构建一切。但那通常是错误的，几乎所有的时候都是错误的，“他说。

一个例子来自于早期在Pantheon的时候，一个仅限于一个虚拟机的系统。他们认为这将是一两个月可以完成的项目，直到被迫扩大规模。最终结束历经一年多的时间，以一种完全不同于预期的方式扩展了它。

他接着说，在这些情况下，你认为需要扩展的领域可能不是首先需要扩展的部分，即使是需要扩展的系统也会导致错误的努力。

调查你的愿景

从首席技术官的访谈中可以清晰地看出，在某些情况下，最好的方式是使用monolith或微服务。

什么时候从Monolith开始

以下的一些情况，表明应该使用monolithic架构开始下一个项目。

• 团队是在创始阶段：团队很小，2-5成员之间，因而无法应对更广泛和高开销的微服务架构。
• 正在构建一个未经证实的产品或概念证明：构建一个在市场上未经证实的产品？如果这是一个新的想法，它可能会随着时间的推移而发生转变和演变，所以monolith是允许快速迭代产品的理想选择。同样的情况也适用于概念证明，目标只是尽可能快地学习，即使最终把它抛弃。
• 没有微服务经验：如果团队以前没有使用微服务的经验，除非能够在早期阶段冒险学习“即学即用”，否则这可能是另一个信号：应该坚持从monolith开始。

什么时候从微服务开始

以下的一些情况，表明应该使用微服务架构开始下一个项目：

• 需要快速，独立的服务交付：微服务允许在一个更大的集成系统内快速，独立地交付各个部分。请注意，根据团队规模，可能需要一些时间才能看到服务交付收益，而不是从Monolith开始。
• 平台需要极为高效：如果业务正在进行大量的PB级日志量处理，那么可能希望以非常高效的语言（即C++）构建该服务，同时可以在Ruby on Rails上构建用户仪表盘。
• 计划扩大团队规模：从微服务开始，可以从一开始就将团队用于单独的小型服务开发，并通过服务边界分离团队，这样可以在不需要引入指数级复杂性的情况下轻松扩展团队。

对于Monolith与微服务的辩论没有一个一刀切的答案。但是，通过应用上述考量，大家应该能够做出最适合自己的决定。