为什么我一直在InVision上将微服务合并回Monolith

如果您在Twitter上关注我，您可能会注意到，现在（1）和（2）然后（3），我都会发表庆祝推文，内容涉及将我们的一种微服务合并回InVision的整体中。我的推文通常都附有Thanos GIF，其中Thanos将最后一块Infinity Stone返回Infinity Gauntlet。我发现这个GIF非常合适，因为石头的重聚赋予了Thanos巨大的力量。重组微服务的方式与我和我的团队一样。我多次被问到为什么我要终止我的微服务。因此，我想就Web应用程序开发领域中的这一特定旅程分享更多见解。

非常清楚，我想明确指出我不是反微服务，以此来开始这篇文章。我将服务合并回到整体中并不是为了摆脱微服务而付出的努力。此任务的目的是“正确大小”。巨石。我正在做的事情是解决我团队的痛点。如果不减少摩擦，我将不会花那么多时间（和机会成本）来提升，转移和重构旧代码。

每次这样做，我都会冒引入新错误并破坏用户体验的风险。将微服务合并回整体，有时会令人振奋，但总是令人恐惧；并且代表了计划，降低风险和测试方面的大师班。再说一次，如果这不值得做，我就不会做。

为了了解为什么我要破坏一些微服务，重要的是要了解为什么首先要创建微服务。微服务解决了两种类型的问题：技术问题和人员问题。

一个技术问题是应用程序的一个方面给基础架构带来了不必要的负担。反过来，这很可能导致较差的用户体验（UX）。例如，图像处理需要大量的CPU。如果此CPU负载太大，则可能会开始耗尽应用程序的其余处理资源。这可能会影响系统延迟。而且，如果情况变得很糟，它可能会开始影响系统可用性。

另一方面，人员问题根本与应用程序无关，而与团队的组织方式无关。您在应用程序的任何给定部分中工作的人越多，开发和部署的速度就越慢且容易出错。例如，如果您有30位工程师都在争夺＆＃34; Continuous Deploy＆＃34; （CD）相同的服务，您将获得很多排队；这意味着，许多本来可以运送产品的工程师实际上正围坐在等待轮到他们部署的时候。

自8年前成立以来，InVision一直是一个整体系统，当时只有3位工程师在研究它。随着公司的发展并获得关注，系统的数量几乎没有增加，而工程团队的规模开始迅速增长。几年之内，我们有数十名工程师-后端和前端-都在同一代码库上工作，并且全部部署到同一服务队列。

正如我上面提到的，很多人都在同一个地方工作可能会变得非常棘手。不仅各个团队都在争夺相同的部署资源，这还意味着每次“事件”都是被宣布，有几支球队代码必须回滚；而且，在管理事件时，没有团队可以部署。可以想象，这在整个组织中引起了很大的摩擦，无论是工程团队还是产品团队。

因此，＆＃34;微服务＆＃34;出生是为了解决人们的问题。一组选定的工程师开始在他们认为与团队边界相对应的部分应用程序周围绘制边界。这样做是为了使团队可以更独立地工作，独立部署并运送更多产品。早期的InVision微服务几乎与解决技术问题无关。

如果您使用微服务，那么您无疑会听说Melvin Conway于1967年提出的Conway法则。

设计系统（广泛定义）的任何组织都将产生其结构是组织通信结构的副本的设计。

这里的想法是解决方案是＆＃34; optimized＆＃34;围绕团队结构（和团队沟通开销），并且不一定旨在解决任何特定的技术或性能问题。

在微服务之前的世界中，人们普遍以负面的眼光来讨论康韦定律。与之类似，Conway法则表示您的应用程序规划和组织欠佳。但是，在后微服务世界中，康韦定律具有更大的自由度。因为事实证明，如果您可以将系统分解为具有凝聚力边界的一组独立服务，则可以以更少的错误发布更多的产品，因为您已经创建了更加专注于服务集的团队这意味着责任范围会缩小。

当然，康威定律的好处在很大程度上取决于您划定界限的位置。以及这些边界如何随着时间演变。这就是我和我的团队-Rainbow Team-出现的地方。

多年来，InVision必须从组织和基础架构的角度发展。这意味着在引擎盖下有一个较旧的＆＃34; legacy＆＃34 ;；平台和不断发展的＆＃34;平台。随着我们更多的团队迁移到＆＃34; modern＆＃34;平台，这些团队负责的服务需要移交给其余的“旧版”。团队。

今天-2020年-我的团队是传统团队。我的团队已逐渐但稳定地负责越来越多的服务。这意味着：人员更少，但存储库更多，更多的编程语言，更多的数据库，更多的监控仪表板，更多的错误日志，以及更多的深夜页面。

简而言之，随着时间的流逝，康威法对组织的所有好处已成为我的遗产的责任。球队。因此，我们一直在尝试调整尺寸。我们的责任范围，使平衡归结于Conway法。或者，换句话说，我们正在尝试更改服务边界以匹配团队边界。这意味着将微服务合并回整体。

微服务架构曾经发生过的最糟糕的事情可能是术语“微”。微型是一个毫无意义但繁重的术语，几乎充满了历史内涵和人类偏见。一个更有用的术语是“正确大小”。微服务从来都不是小型服务，而是大小合适的服务。

＆＃34; Micro＆＃34;毫无意义这不代表任何意思;它什么也不需要。另一方面，“正确大小”意味着必须对服务进行适当的设计以满足其要求：对正确的金额负责。功能。而且，什么是正确的这不是一个静态的概念-它取决于团队，其技能，组织的状态，计算出的投资回报率（ROI），拥有成本以及提供该服务的时间点操作。

对于我的团队来说，“尺寸合适”意味着更少的存储库，更少的部署队列，更少的语言以及更少的操作仪表板。对于我规模较小的团队，“规模合适”更多关于＆＃34; People＆＃34;比有关技术的知识要多。因此，与InVision最初引入微服务来解决“人问题”的方式一样，我的团队现在正在销毁那些相同的微服务以解决“人问题”。

我为自己的团队以及我们在旧平台上的努力而感到自豪。我们是一小群勇士；但是我们所拥有的成就很多。我将这次成功归功于我们对旧平台的深刻了解；我们积极进取的实用主义；并且，我们将继续努力设计一种能够与我们的能力相称的系统，而不是试图根据我们的系统需求来扩展我们的能力。这听起来可能心胸狭窄。但是，这是目前我们团队及其资源唯一可行的方法。

支持创建独立服务的论点之一是这些服务可以“独立扩展”的想法。这意味着，您可以在如何配置服务器和数据库以满足服务需求方面更有针对性。因此，您可以创建一些较小的服务，而独立地扩展其他服务，而不必创建大规模的服务以仅扩展部分功能。

在为什么独立服务是一件好事的所有原因中，这一服务的使用频率很高，但是，根据我的观点（非常有限），通常是无关紧要的。除非某项功能是受CPU限制或IO限制或受内存限制的，否则独立的可伸缩性可能不是＆＃34; ility＆＃34;。你要担心在很多时候，您的服务器都在等待事情的到来。添加＆＃34;更多的HTTP路由处理程序＆＃34;应用程序不会突然耗尽其所有资源。

如果我可以返回并重做我们早期的微服务尝试，那么我将100％从关注所有＆＃34; CPU约束＆＃34;开始。功能优先：图像处理和调整大小，缩略图生成，PDF导出，PDF导入，带有rdiff的文件版本控制，ZIP存档生成。我会沿这些边界划分团队，并让他们创建＆p34; pure＆＃34;服务只处理输入和输出（即，没有“集成数据库”，没有“共享文件系统”），以便其他每个服务都可以在保持松散耦合的同时使用它们。

我并不是说这可以解决我们所有的问题-毕竟，我们有更多的人。比我们技术上存在的问题问题;但是，它可以解决更多的＆＃34; right＆＃34;问题，从长远来看，这可能会使生活变得更轻松。

服务不是抽象运行的：它们在服务器上运行，与数据库对话并报告指标并生成日志条目。所有这些都有非常真实的美元和美分成本。因此，虽然您的＆lambda函数＆＃34;当您不使用它时，您的＆microservices＆＃34;当然可以。尤其是当您考虑要创建＆＃34;高可用性＆＃34;所需的冗余时。系统。

我的团队将微服务合并回整体，对业务的底线产生了实际的影响（很好的方式）。它不是庞大的-我们只是在谈论一些小型服务；但是也不是零。因此，除了所有的＆＃34; People＆＃34;通过将系统合并在一起而获得的收益，我们也获得了美分收益。

我们经常在会议上或网络上听到“新的开发方式正在将您的整体细分为微服务”。不用谈论潜在的弊端，我们将不得不这样做。

这与重构代码以使自己保持忙碌无关，而在于正确的工具和方法来完成正确的工作。您在这篇文章中非常优雅地捕捉到了这一点，并通过分享您在InVision中所做的事情来使现实成为现实。

谢谢你的客气话。对于新的闪亮事物总是很艰难！开发人员通常希望使用这些炫酷的新工具。而且，考虑到该行业的平均工作时间只有2年，我们并没有从选择中生存，并随着时间的流逝看到了什么影响，我们并没有从中受益。我认为自己很幸运能够在同一个应用程序上工作8年以上，因为它给了我一个观点，即并非每个人都能拥有。

@ben这是一篇很棒的文章，您已经学到了一些只有在现实世界中才能获得的深刻见解！

首先，康韦定律的广泛应用。实际上，我只是在几周前就想起了该法律的名称，为了挽救生命，我想不起来了。您的帖子立刻使我想起了，这也是一个非常真实的观察。

其次，我总是不喜欢将团队命名为“旧版”。球队。我认为它对那些人有点士气低落，并暗示代码对组织不那么好或没有用。如果您正在使用最佳做法，源代码控制，在可能的情况下进行测试，CI / CD，请考虑将其称为“核心团队”。或＆＃34; Foundation团队＆＃34; ;）

最后，您已经很好地观察到，将应用程序的各个部分放在一起以减少存储库，构建和测试的占用空间是很有价值的。无耻的ColdBox MVC插头传入。这就是模块化体系结构发挥作用的地方。将大型应用程序分解为模块化设置非常好，在这里，您可以将M，V和C很好地分离为一口大小的块，职责明确同时仍位于相同的回购协议中，并且属于同一基本应用程序的一部分。我们经常构建的应用程序具有5-10个核心模块，在其中我们分解了功能以保持良好的组织状态，并始终保持开放的可能性，将来可以将其分解为一个单独的应用程序，而无需完全独立的微服务。我认为这是一个很好的＆＃34;中间地带＆＃34;如您所展示的。

新：一些基本的降价格式 现在支持：粗体，斜体，块引用，列表，带围栏的代码块。 阅读更多有关markdown语法的信息»

订阅评论。 评论礼节：请不要发布垃圾邮件。 请保持评论主题。 请不要发布无关的问题或大量代码。 以上 所有人，请彼此友好-我们正在努力与大家进行良好的对话。