如何调整团队对微服务的统一认识

原文：Aligning Your Team Around Microservices When There’s No Precise Definition

作者：Roger Jin

翻译：lloog

译者注：作者介绍微服务定义不明确，团队要统一对微服务的认识。

这是Roger Jin写一篇文章，他是ButterCMS的软件架构师，也是初创企业微服务的作者之一。

对于微服务不明确的定义，我们感到失望。问题在于，微服务器本身就没有什么“微观”的标准。微服务大小是相对的，并且在组织之间没有标准的测量单位。一家公司的“小”服务可能具有一百万行代码，而另一个公司的代码可能要少得多。

有些人认为微服务根本不是什么新的概念，而是对面向服务的体系结构的重新命名，而另一些人则主张将微服务视为SOA的实现，类似于Scrum是如何实现敏捷的。

在没有精确定义微服务的情况下，如何调整团队统一对微服务的认识?在团队中谈论微服务时，最重要的是确保以一个共同的起点为基础。

模棱两可的定义对使用微服务是毫无帮助。这就好比在不清楚要达到的目标的情况下，就把敏捷应用在实际开发中。

寻找共同点

在我工作的团队中，我们从未停止探索微服务的定义，我们首先着重于确定通过采用微服务获得的好处：

传递软件更快

我们的主要应用是由几个开发人员维护的，努力为不同目的构建功能的代码库。这要求代码库的每一个变化都要尽量满足不同的群体。例如，仅仅服务于某一个开发组的数据库更改必须由其他人来审查和接受，这会降低开发的效率。

让不同组的开发人员共享相同的代码库，这意味着代码在不经意的情况下会持续地变得更加复杂。当代码库变得更庞大时，团队中没有人能够独立拥有它，并确保所有的部件都是有组织的，并以最佳的方式组合在一起。这给我们带来了很大的考验。当我们需要让修改的代码生效时，例如仅仅修改了一行代码也需要我们重新发布整个程序。 而部署大型应用程序是高风险的，这会导致代码质量保证流程增长，部署应用的数量也会相应减少。

借助微服务架构，我们希望能够将代码根据不同的开发团队进行拆分，从而每个开发团队独立不会相互影响。 这将使开发团队能够更快地进行创新，而不需要需冗长乏味的设计，审查和部署流程。 我们也希望由较少的开发人员处理尽量小的代码库，这样我们的代码库将更容易开发，测试和组织。

灵活的技术选择

我们的主要大型应用是使用Ruby on Rails以及具有复杂构建过程的自定义JavaScript框架构建的。

但在开发过程中我们的应用的几个模块都遇到了一些性能问题，这些问题很难修复，并导致应用程序的其余部分的性能降低。现在可以用更好的方法来重写我们的应用程序的这些部分，但是我们的代码库与受影响的区域相互纠缠，代价太大，成本太昂贵了。

同时，我们的前端团队想要摆脱自定义的JavaScript框架，而是用React等更新的框架构建产品功能。但是将React混合到我们现有的应用程序，前端构建过程将变得复杂，其配置成本将会增加。

随着时间的推移，团队感觉被困在体积庞大复杂，修复替换成本昂贵的代码库中，团队对此越来越沮丧。

因此我们希望通过采用微服务体系结构保持单个服务的规模更小，用更好的实现来替换它们并更容易管理。我们还希望能够为每一项任务选择合适的工具，而不是必须采用一刀切的方法。我们可以灵活地在不同的应用程序中使用多种技术。如果一个团队想要使用Ruby以外的其他东西来获得更好的性能，或者切换我们定制的JavaScript框架，他们可以这样做。

微服务不是免费的午餐

除了上述我们希望获得的好处之外，我们还要确定构建和管理微服务的成本和面临的挑战等现实情况。

开发，托管和管理大量服务需要大量的开销。 在少量服务中，运行在几个进程上的单个monolith可以轻松地转换为几十个进程，并需要负载平衡器，消息传递层和集群来实现弹性。 而管理所有这些需要大量的技能和工具。

此外，微服务还涉及分布式系统，分布式系统带来了大量的问题，如网络延迟、容错、事务、不可靠的网络和异步性。

设定自己的道路

一旦我们确定了微服务的好处和成本，我们就开始讨论架构，并且也不会陷入关于谁做的微服务是正确或错误的争论中。我们不需要通过别人的描述或微服务的例子来努力寻找适合我们的方法，而是专注于我们要解决的核心问题。

• 在接下来的6-12个月，如何利用更多的服务让软件传输更快？
• 在系统的某些部分中使用特定工具是否能带来技术优势？
• 要更换一个更适合的系统吗？
• 当团队人数增加时，该如何组织团队？

综上所述，这里有一些建议，可以让您的团队更好地加入到微服务中:

1. 同意没有“正确”的定义，并深入了解学习微服务。
2. 确定采用微服务的预期效益和成本。
3. 基于你以前确定的好处和成本，讨论如何更好地构建您的系统。

专注于确保团队拥有详细定义的一套共同目标。讨论和确定微服务实现的功能比确定微服务实际是什么更有价值。