作者 | Gustavo

编译 | 言征

出品 | 51CTO技术栈（微信号：blog51cto）

创业工程团队不仅必须考虑技术方面，还必须考虑微服务与整体服务的选择如何与其业务目标相一致。毫无疑问，关于这两种方法的评论和分析有很多，本文中，我们将探讨真实的案例，以便诸位做出自己的决定。

在创业公司的现实中，工程团队在为其软件应用程序选择基础架构时往往处于十字路口。这个看似技术性的决定实际上远远超出了编码领域，直接进入了可以决定创业公司早期阶段的战略规划。

这个决定的核心取决于一个关键问题：团队应该为去中心化的微服务架构奠定基础，还是应该选择单体设计，让整个应用程序是统一且相互依赖的？

构建一个系统，其设计本质上是随着创业公司的发展而不断增长和适应，这样看，微服务相当适配，其中的每个服务运行其独特的进程并通过定义良好、轻量级的机制进行通信。这种方法提供了许多优势，尤其是在团队能够更新和部署单个组件而不中断整个系统的情况下。

然而过早地采用微服务，并不十分明智。尤其是在时间至关重要且创业公司需要迅速建立自己作为可靠和可行的业务的情况下。设计、部署和维护微服务网络的复杂性是一项重大任务，经常被许多人低估。这种复杂性可能会带来意外的延迟、增加停机风险，并要求初创公司可能仍然需要具备一定水平的运营成熟度。

相比之下，单体架构（通常被视为传统或过时）可堪一用，尤其是对于处于初级阶段的创业公司。单体应用程序中，所有组件都是相互连接和相互依赖的，为开发提供了一个简单直接、统一的模型。这种方法可以大大简化开发过程，缩短上市时间，并允许快速原型制作和迭代——这对于需要迅速证明其业务模式的可行性的创业公司来说是至关重要的因素。

路径对比鲜明，创业公司的工程团队必须仔细权衡他们的选择，不仅要考虑技术方面，还要考虑他们的选择如何与他们的业务目标、团队能力和市场进入的紧迫性相一致。

单体架构的特点是应用程序只有一个统一的代码库，由于其简单性和高效性，对于创业公司而言非常有吸引力。这种架构风格中，所有组件都是相互连接和相互依赖的，简化了开发和部署过程。

Stack Overflow选择单体架构无疑说明了这种方法的强大之处。尽管它每秒处理超过6000个请求，每月页面浏览量达到20亿次，但Stack Overflow仍然通过一个运行在IIS上的单一应用程序进行操作，为200个网站提供服务，并表现出卓越的效率。这种设置由一个单一的SQL Server组成，该服务器由广泛的缓存和精简的技术堆栈支持，由一个只有50名工程师的团队进行管理。他们能够快速部署更新，每天多次部署，这展示了结构良好的单体系统可以提供的运营灵活性。

Shopify是科技行业的另一巨头，它采用了模块化单体的方法，所有代码都放在一个代码库中，但进行了模块化以更好地管理。这种方法允许清晰地划分业务领域，如订单、运输和结算，每个领域都有自己的专用接口和数据所有权。维护一个单一的存储库和部署管道使得Shopify能够获得流线化维护和跨所有团队的合作的好处。

根据我在一家共享单车和滑板车初创公司的个人经验，采用单体架构的决定导致了惊人的快速推出，仅用了四个月的时间。这种单体方法促进了从简单原型到完整应用程序的开发，包括信用卡支付、物联网集成和必要的运营工具。其简单性使我们能够快速建立基础设施，并保持对整个代码库的清晰理解。

这种简化的架构使我们在发布时能够部署5000多辆自行车上路。此外，事实证明，它非常有效地扩大了服务规模以满足我们经历的快速增长的用户需求，在运营的前六个月内容纳了超过100万用户。单体设计固有的灵活性和简单性对于高效、迅速地管理这些大规模和变化至关重要。

现在你可能会想：Shopify、Stack Overflow等巨头，甚至作者个人的成功经验……如果单体架构那么好，还有必要继续使用微服务吗？当然。别担心，我有其他例子来丰富各位的视野，我们继续。

向微服务架构的转变代表着许多初创公司的战略性转变，尤其是在它们扩大规模和发展的过程中。微服务的特点是分布式运行，每个服务独立运行，这在可扩展性、灵活性和适应不断变化的需求的能力方面具有显著优势。

一个典型的例子是Nubank，这家公司从2013年成立之初就开始采用微服务架构。这一决定违背了传统的观点，通常建议以单体架构开始，以提高速度和简化初始开发过程。Nubank选择从微服务开始是基于对其商业模式和市场的战略评估。虽然这种方法最初减缓了他们的开发过程，但它允许他们投资于坚实的基础架构，随着他们开始扩大规模和扩展功能，这带来了回报。

这个过程并非没有挑战。随着对领域的深入了解，Nubank必须不断调整和完善其服务边界。这种持续的评价和调整过程比任何东西都更能说明微服务的动态性质，它允许持续改进和优化。

据本人在一家健康科技初创公司的经验，采用了一种更有趣的方式：准微服务架构，这种架构需要在高安全性、可扩展性系统与小型团队的实用性之间取得平衡。这种方法与传统微服务不同，将应用程序划分为可管理的层和部分，每个部分由一个专门的团队负责，以促进问责制和专注性。

我们在一个单体数据访问层上实施了这种架构，集中了健康科技领域至关重要的高标准隐私和安全要求。这种设置允许团队独立工作，而不需要单独处理这些关键的合规方面。此外，我们使用单个单体存储库作为所有服务的存储库，并结合统一的部署管道。此外，为了应对典型的微服务挑战，我们开发了一种标准化、用户友好的跨服务通信机制。该系统有效地缓解了低开发生产力、数据一致性等问题。

因此，准微服务架构的灵活性对于快速适应不断变化的需求和按需扩展特定系统组件至关重要。

当初创公司面临选择微服务还是单体架构的关键决策时，有几个关键因素需要考虑。

首先，工程团队的规模至关重要。较小的团队可能更容易在单体架构中进行管理和开发，而较大的团队可以利用微服务的分布式性质同时处理不同的组件。

项目复杂性也起着重要作用：具有清晰且稳定范围的单体架构可能更适合简单的项目，而复杂的、不断发展的项目可能更适合微服务。

可扩展性需求是另一个关键因素。如果需要快速扩展，微服务提供了必要的灵活性和可扩展性来适应增长。然而，如果可扩展性不是立即需要考虑的问题，单体的简单性可能更有优势。

当前工具和技术趋势的影响也不能忽视。支持微服务或单体架构的工具和框架的可用性可以显著影响开发和维护的便利性。

所有这些示例和推理背后的主要思想是鼓励初创公司仔细评估其独特的情况，并做出与业务目标、团队动态和竞争格局相一致的选择。

也许准微服务架构是更适合的方案？或者可能更倾向于尝试其他方法？再次强调，微服务和单体架构之间的选择不仅仅是技术选择，对所有因素的评估才是实现完美匹配的关键。

来源： 51CTO技术栈