这不是泥浆。只是沙子。图片来自个人收藏
如今微服务如此流行，难免被用在不该用的地方。
微服务是一种模式，它有2个主要驱动力：优化团队规模和系统负载。然而，它们的使用往往是出于对单片机的恐惧。这个想法是，避免大泥球的唯一方法是从一开始就把系统分割成微服务。
从一开始它就有意义。如果我知道在某些时候我需要拆分我的系统，那么为什么不跳过单片机阶段而直接跳到微服务呢？想象一下，我可以节省多少时间和金钱。
不幸的是，这是很有问题的。主要问题是，在开始构建产品时，我通常很少对产品有足够的了解。在这一点上，我需要能够快速改变它。当我有一个小团队时，这正是微服务无法实现的。是的，对于大的组织来说，微服务可以实现自主团队的扩展，但是当我只有一个团队的时候，这不是我所需要的。
微服务是最昂贵的管理架构的方式。
在一个单一的服务/代码库中简单的事情，如移动东西，在微服务世界中变成了多步骤的微项目。当然，微服务对于执行边界是非常强大的。然而，当组织只有一个产品团队的时候，我真的不需要/不希望这样。
有效地使用微服务需要投入大量的资金来建立必要的运营成熟度。组织越大，就越容易进行这种投资。我希望在适当的时候进行这种投资，不要太早（也不要太晚）。
变成大泥球的主要原因是，当产品正在经历快速迭代时，投资于技术可扩展性并没有什么意义。然而，随着产品的成熟，工程组织应该在某些方面进行调整，为系统的长期健康发展做出更大的努力。注意到这一点可能是相当具有挑战性的，因为它需要改变整个产品组织的思维方式。
在下面的文章中，我列出了4个备选方案，从最轻的、需要相对较少的前期投资的方案到更重的方案。随着组织的发展，我希望从较轻的替代方案到较重的替代方案，然后最终转换为全面的微服务。
A - 模块化设计
一个稳定的小团队应该能够就如何构建东西达成一致。如果一个5-7人的团队不能建立一些关于他们的架构的基本准则，那么它无论如何都不可能成功地做任何事情。
在一个单一的代码库中，完全可以隐藏每个模块的内部结构，并尽量减少它们之间的公共API。通常情况下，模块化设计之所以如此困难，并不是因为每个团队都有一些邪恶的工程师，有意识地将代码添加到错误的模块中。而是因为他/她无法找到应该实现新逻辑的适当位置。微服务没有以任何方式解决这个难题。
假设我有模块A、B、C，我的挑战是添加不适合任何模块的新代码。我为什么要相信拥有服务A、B、C会使它变得更容易？最有可能发生的是，我仍然会在服务A中添加一些根本就不应该存在的东西。因此，随着时间的推移，服务A变成了一个大泥球，甚至更糟糕的是，我将有一个分布式的单体在我手中。有了模块，做正确的事情和重构现有结构的障碍就小多了。
另外，我还可以将数据存储分成多个模式或逻辑数据库。当时间到了，我可以在多个数据库服务器之间拆分它。这并没有增加多少成本。然而，它为我准备了未来可能出现的情况，即数据库需要被分解成小块。
B - 架构测试
如果只是一个协议或决策记录是不够的，我可以引入一些工具来验证没有人意外地做一些他们不应该做的事情。
像ArchUnit或JDepend这样的工具可以用来验证模块/子系统之间是否存在不需要的依赖关系。Neal Ford称这些为架构适配函数。
C - 多模块设置（使用Gradle/Maven等工具
这是更重的解决方案，但也允许更严格地执行边界。同时，仍然没有管理微服务的操作开销。我仍然将所有模块工件组成一个可部署的单元。
D - 带有微服务的团队单机版
这在技术上已经是微服务了，但想在这里把它作为微服务的典型实现方式的一个轻量级版本。
与其将每个微服务推送到自己的代码库中，一个团队所拥有的所有服务都可以驻留在一个单一的代码库中。虽然这给我带来了严格隔离的所有好处，但我仍然可以比多库更容易地移动东西。
重要的一点是，这不是整个组织的单库，而只是一个团队的单库。一旦有多个团队在一个代码库上工作，事情就会变得更加复杂。各个团队开始重复使用不应该跨边界共享的东西，因此变得更加相互耦合。同样，在有意识的努力下，这种方法甚至可以在多个团队中发挥作用，但在3个团队中，这种方法的好处变得更加值得怀疑。
最后的想法
微服务是非常强大的，但也是非常昂贵的。组织越大，微服务提供的价值越大。当团队规模较小，产品仍在经历大量的变化时，它不可能是最好的选择。在工程组织大到足以从微服务中获益之前，有几个更便宜的方案可以评估，而不是去选择最重的解决方案。
单片机并不是什么可怕的东西。关键是要认识到它开始拖累组织的时间点。将单一代码库分割成小块并不是一件容易的事情，但它也有一些好处。它有助于避免有太多的知识停留在遗留系统中，也是一个更新团队对系统知识的机会。
其他伟大的资源。
www.thoughtworks.com/insights/bl…
创办机构的微服务替代方案最初发表于Nerd For Techon Medium，在那里人们通过强调和回应这个故事继续进行对话。
