这个怎么运作？

选项 1. 单体架构（monolith）

单体架构就像一个雪球。你开始一个项目，你有一个小雪球。它是如此之小，以至于可以由一个小团队开发和滚动。几年过去了，现在你的雪球已经变得如此巨大，以至于 20 位开发人员已经在推动它。再过几年，数百 名开发人员将用大量代码滚雪球，但新功能的推出将变得非常缓慢。

因此，业主开始更换技术总监、团队成员，但只会变得更糟。新的团队成员不知道历史细节，为什么雪球是这样的，而不是另一个。产品文档很快就会过时。

为什么不从一开始就做呢？首先，在创业之初，总是资源有限，没有足够的开发人员、专业知识和时间。手册在催，程序员们急着用最快的方式去做。

其次，技术工程师认为：“好吧，暂时让它成为一个单体架构，但是当业务增长时，我们将重做所有事情”。不幸的是，实际上，将现有的单体项目转移到微服务架构将比从头开始编写所有内容要困难几十倍。

方案2.微服务架构

我们将立即基于微服务架构为您打造金融平台。

微服务架构可以类比为人行道上的铺路板。随着您的项目的发展，更多的瓷砖被添加到您的人行道上。如果某个组件已过时，只需将此图块替换为新图块即可。

这种架构有很多优点，但我会说出最重要的一些：

现实生活中的例子

第一个例子。 一个拥有大量用户的 P2P 借贷平台的管理层决定进入不同货币国家的市场。该平台采用单一架构，仅包含一种货币——欧元，要进入瑞典（瑞典克朗）、波兰（波兰兹罗提）、捷克共和国（捷克克朗）的市场，就必须引入多种货币。

整个团队花了几个月的时间来实现这个功能，新功能的开发速度进一步放缓。在微服务架构的情况下，一切都会变得更容易和更快。

第二个例子。 最初，网站构建器以母语推出，管理层不打算扩展到其他市场。该项目采用单体架构，功能快速增长。该平台的方案是一个复杂的网络，其中一切都连接到一切。有一天，该公司决定以其他语言发布该平台的一个版本。起初，似乎只添加语言文件就足够了，现在我们将翻译整个界面。

实际上，整个项目都必须重做。例如，数据库中的公司和产品名称现在不仅应该以一种语言存储，而且应该以每种语言存储。由于业务逻辑，无法复制信息，必须一次存储所有语言的名称。因此，这导致了机柜和后台接口的变化。界面变更需要更改验证传入数据的规则、由于不同语言的结尾原则不同而导致的字母模板、更改测试等。

由于一切都与一切相连，因此决定在推出新语言的同时转向微服务架构。从单体架构到微服务架构的转变过程耗时一年多。

第三个例子。 金融科技平台是在旧版本的 PHP 和 Laravel 上制作的。升级到新版本以及将数据库从 MariaDB 更改为 PostgreSQL 几乎是不可能的，因为整个团队只需要处理几个月的迁移过程。

当时新版本的 PHP 和 Laravel 可以加速项目和进一步的开发，但是单体架构不允许更新技术栈