单体与微服务。为什么不兼得？
单体与微服务。为什么不兼得？
你什么时候有这样的决定？
通常，当您加入团队时，他们已经有了您必须遵守的工作流程和堆栈。
如此现实——只有当你为一个新项目加注星标时，你才会做出这个决定。
我认为有两种新项目：
- 你为自己做的那个
- 您作为高级开发人员（或唯一的开发人员）为公司（作为员工）所做的工作
为自己建造
很可能是某种爱好项目，或者您有兴趣尝试新技术或工程方法，或者只是创建一些东西来扩展您的投资组合。由你决定。
我会这样处理它，具体取决于您的感知水平：
- Junior——只有单体、后端和前端来自同一个 repo。同步做所有事情。不要过度设计，你可能会以一种你甚至无法理解的方式犯错。
- 中间——从单体（v1）开始，完成后——进行高级概述并尝试思考潜在的瓶颈。使用负载测试工具进行模拟。然后尝试解决你遇到的问题（v2）——你可以异步做一些事情，但保持单体应用；您可以尝试拆分微服务，看看这是否解决了瓶颈。将队列和异步消息添加到重构部分——Redis、Amazon SQS、RabbitMQ、Kafka。使用 Docker。如果您可以将其部署为使用 HTTPS 等在 Internet 中运行，则可以加分。添加 CI/CD 管道。
- 高级——这真的取决于你。您应该考虑时间努力成本与结果。考虑这个项目的最终目标，您预计负载在一个月、一年内如何增长？然后，您将选择更适合您项目的方法。
- 技术主管——此时代码不是你最关心的问题，但架构才是。您最感兴趣的是测试新技术并找到它们的限制，将您的发现可能应用于实际工作中的用例。
为公司建设
假设您负责为新项目选择堆栈和架构。
您可以选择如何组织它：
- 开始一个单体应用——易于部署，大量代码集中在一个地方，紧耦合是一个（可能的）问题
- 从微服务开始——很难真正独立开发，最初很难部署，多个 CI/CD 管道，很难让初级开发人员入职，在试图看到全局时开销更大
- 做任何一种混合方法
我的想法
Monolith 几乎总是一个最佳选择。
您作为主管或高级工程师，负责代码结构并使其尽可能模块化。
你应该设计它，因为它是由一堆微服务组成的。
- 代码应该尽可能地模块化——你扩展你的应用程序，使新功能在后期作为微服务相对容易实现。
- 建设时 v1/MVP 设置一些 全部 或者 技术债务 在目前同步做事的地方买票，但是 c 一个潜在的改进 通过引入异步队列和工作人员。不要马上做，你会浪费时间和精力，在不久的将来可能不需要它。对于经验不足的同事来说，任何同步代码都更容易理解和使用。
- 编写测试——它们是你最好的朋友。稍后将模块拆分为微服务变得更容易——您只需复制测试覆盖率并使其通过即可。
- 不要在早期担心优化（ N+1 查询除外 )，对于大多数应用程序来说，最终的瓶颈将是数据库存储。实际上，您很可能不会很快达到上限，因为这些天您可以相对容易地扩展数据库。
- 不要过度设计。对于任何新项目，您的首要目标是获得 MVP。添加一些自动代码样式和 linter，然后保持简单。我有 PHP/Laravel 开发者的一篇文章 这里。为了 巢穴 ，例如，您已经被框架团队的 eslint/prettier 设置所覆盖。
- 探索混合应用程序的可能性，一些现代堆栈允许您保持单一代码库并逐渐将某些部分切换到类似微服务的模块。
- 示例 Laravel 堆栈的混合应用程序
- 示例 NestJS 堆栈的混合应用程序
希望这会有所帮助。祝你好运，工程快乐！
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
