我想明确指出我不是反微服务者，我将服务合并回到整体(单体/Monolith)中并不是为了摆脱微服务，目的是实现“大小正好”的整体。我正在做的事情是解决我团队的痛点。如果不能减少摩擦，我将不会花费太多时间（和机会成本）来提升，转移和重构旧代码。
每次这样做，我都会冒引入新错误并破坏用户体验的风险。将微服务合并回整体，有时会令人振奋，但总是令人恐惧；并且代表了计划，降低风险和测试方面的大师班。再说一次，如果这不值得做，我就不会做。
微服务解决技术和人员问题
为了了解为什么我要破坏一些微服务，重要的是要了解为什么首先要创建微服务。微服务解决了两种类型的问题：技术问题和人员问题。
- 技术问题是应用程序的一个方面给基础架构带来了不必要的负担。反过来，这很可能导致较差的用户体验（UX）。例如，图像处理需要大量的CPU。如果此CPU负载太大，则可能会开始耗尽应用程序的其余处理资源。这可能会影响系统延迟。而且，如果它变得足够糟糕，可能会开始影响系统可用性。
- 人的问题，而另一方面，有一点做与所有的应用程序和一切与你的团队是如何组织的。您在应用程序的任何给定部分中工作的人越多，开发和部署的速度就越慢且容易出错。例如，如果您有30位工程师都在争夺“连续部署”（CD）相同的服务，那么您将获得很多排队；这意味着，许多本来可以运送产品的工程师实际上正围坐在等待轮到他们部署的时候。
早期的InVision微服务通常解决了“人”问题
自8年前成立以来，InVision一直是一个整体系统，当时只有3位工程师在研究它。随着公司的发展并获得关注，系统的数量几乎没有增加，而工程团队的规模开始迅速增长。几年之内，我们有数十名工程师-后端和前端-都在同一代码库上工作，并且全部部署到同一服务队列。
正如我上面提到的，很多人都在同一个地方工作可能会变得非常棘手。不仅各个团队都在争夺相同的部署资源，这还意味着每次声明“事件”时，都必须回滚几个团队的代码。而且，在管理事件时，没有团队可以部署。可以想象，这在整个组织中引起了很大的摩擦，无论是工程团队还是产品团队。
因此，诞生了“微服务”来解决“人们问题”。一组选定的工程师开始在他们认为与团队边界相对应的应用程序各个部分周围绘制边界。这样做是为了使团队可以更独立地工作，独立部署并运送更多产品。早期的InVision微服务几乎与解决技术问题无关。
如果边界很好，康威定律就是好的
如果您使用微服务，那么您无疑会听说过Melvin Conway在1967年提出的“康韦定律”。它指出：
设计系统（广泛定义）的任何组织都将产生其结构是组织沟通结构的复制设计。
人们经常用“编译器”示例来说明该法则：
如果您有四个小组从事编译器工作，您将需要通过4次编译。
这里的想法是，解决方案是围绕团队结构（和团队通信开销）“优化”的，不一定设计为解决任何特定的技术或性能问题。
在微服务之前的世界中，对康威定律的讨论通常是负面的。与之类似，Conway法则表示您的应用程序规划和组织欠佳。但是，在后微服务世界中，康韦定律具有更大的自由度。因为，事实证明，如果您可以将系统分解为具有内聚边界的一组独立服务，则可以以更少的错误发布更多的产品，因为您已经创建了更加专注于处理涉及服务的服务的团队。职责范围更窄。
当然，康威定律的好处在很大程度上取决于您划定界限的位置。以及这些边界如何随着时间演变。这就是我和我的团队-Rainbow Team-出现的地方。
多年来，InVision必须从组织和基础架构的角度发展。这意味着，在后台，有一个较旧的“旧版”平台和一个不断发展的“现代”平台。随着我们更多的团队迁移到“现代”平台，这些团队负责的服务需要移交给其余的“传统”团队。
今天-2020年-我的团队将成为传统团队。我的团队已逐渐但稳定地负责越来越多的服务。这意味着：人员更少，但代码存储库更多，更多的编程语言，更多的数据库，更多的监控仪表板，更多的错误日志，以及更多的late-night页面。
简而言之，随着时间的推移，康威定律给组织带来的所有好处对我的“传统”团队来说已经成为负债。因此，我们一直在努力“确定”我们的职责范围，使平衡恢复到康韦定律。换句话说，我们正在尝试更改服务边界以匹配团队边界。这意味着将微服务合并回整体。
微服务不是“微小”的，而是“正确大小的”
微服务架构可能发生过的最糟糕的事情是“微”一词。微型是一个毫无意义但繁重的术语，几乎充满了历史内涵和人类偏见。一个更有用的术语是“正确大小”。微服务从来都不是“小型服务”，而是“合适大小的服务”。
“微型”一无所有。这不代表任何意思; 它什么也不需要。另一方面，“大小合适”意味着必须对服务进行适当的设计以满足其要求：它负责“适量”的功能。而且，“正确”不是一个静态的概念-它取决于团队，其技能，组织状态，计算出的投资回报率（ROI），拥有成本以及投入的时间该服务的运行时间。
对于我的团队来说，“大小合适”意味着更少的存储库，更少的部署队列，更少的语言以及更少的操作仪表板。对于我规模较小的团队，“合适的规模”更多地是关于“人”而不是“技术”。因此，与InVision最初引入微服务来解决“人问题”的方式一样，我的团队现在正在销毁那些相同的微服务以解决“人问题”。
结语：大多数技术不必“独立扩展”
支持创建独立服务的论点之一是，这些服务可以“独立扩展”。这意味着，您可以在如何配置服务器和数据库以满足服务需求方面更有针对性。因此，您可以创建一些较小的服务，而独立地扩展其他服务，而不必创建大规模的服务以仅扩展部分功能。
在为什么需要独立扩展的所有原因中，关键原因是服务经常被使用，但这在我（非常有限）看来通常是无关紧要的。除非某个功能受CPU或IO或内存的约束，否则独立可伸缩性可能不是您要担心的“灵活性”。在很多时候，您的服务器都在等待事情发生；向应用程序添加“更多HTTP路由处理程序”不会突然耗尽它的所有资源。
如果我可以返回并重做我们早期的微服务尝试，那么我将首先100％首先关注所有“ CPU绑定”功能：图像处理和调整大小，缩略图生成，PDF导出，PDF导入，文件版本控制rdiff，ZIP存档生成。我会沿这些边界分散团队，让他们创建“纯”服务，该服务只处理输入和输出（即，没有“集成数据库”，没有“共享文件系统”），以便其他所有服务都可以使用它们同时保持松散耦合。
我并不是说这可以解决我们所有的问题-毕竟，“人”的问题比“技术”的问题要多。但是，它本可以解决更多的“正确”问题，从长远来看，这可能会使生活变得更轻松。
黑客新闻讨论：
认识到微服务是解决人员和组织问题的技术工具。我们需要了解，许多“新”技术范式（尤其是那些来自FAANG或其他大型组织的技术范式）通常旨在解决大规模运营的组织问题，而不是提供我们都应该追求的某种技术灵丹妙药建立。
微服务是一种公司的组织管理工具，微服务是解决人员和组织问题的技术工具
微服务也可用于解决技术问题。例如，很难在python整体中运行一些python3.5和一些python3.9。整体必须选择一个python版本，并在某个时间点将其全部切掉。微服务允许更底层的技术变更（在生产中，而不仅仅是在测试套件中）逐步采用。
微服务的一个真正问题是您不能再将数据库系统用于事务完整性。（banq注：这是将微服务与事务完整性割裂的看法，微服务是位于业务事务完整性下的设计，当然这种业务事务完整性不是将边界扩展到无穷大，这是有边界的，是有界上下文的微服务。）
这是一篇很棒的文章-我一直试图保证的一件事是，您不需要对微服务进行“全力以赴”。一个主要的整体应用程序没有什么错，它的一些部分分成了微服务，这对于性能或团队管理是必不可少的。
技术解决方案是解决人员问题的糟糕解决方案，而架构模式可能是解决人类协作问题的更糟糕的解决方案。微服务通常是“ SOA”的一个好听的名字，但较小的名称却无济于事，SOA的显着地位主要是为了向您出售用于许多微服务的硬件主机。微服务占据了SOA（服务边界）中最困难，最重要的部分之一，并以更小...替代了它。
本文与微服务无关。这是关于在微服务之上构建的整体，然后将代码拉回到整体中。如果您使用自己的数据构建服务，并构建用于处理增量的转换层，则随着时间的流逝，您可能会脱离整体，为您的域和子域提供谨慎的服务。
微服务教会了我如何正确地将DDD应用到整体中。那可能是我去年获得的最有用的东西。
banq评：表面上看：微服务是解决人员和组织问题的技术工具，其实微服务是解决业务问题的技术工具，而对于管理者来说，人员和组织就是用来解决业务问题的，因此业务问题等同于人员与组织问题，但是这两者还是不同的，解决人员与组织问题的工具很多，比如敏捷与DevOps等；而解决业务问题的工具不多，如DDD，这里面有一个谁决定谁的问题，对于主张人员与组织问题的人来说，业务问题是盲盒，业务前瞻性设计是没有必要，只要驱动开发人员摸着石头过河，快速迭代反馈，在编码中学习接受教训，不断反复；而对于注重业务问题的人来说：如果我们从事该行业软件多年，我们对业务问题已经相当了解，那么通过划分有界上下文，切分业务边界，然后根据业务边界划分人员团队。这两种方法各有所长，敏捷迭代适合新项目，DDD适合老项目。