微服务群体、服务集团和人群

我在大企业打工已经快6年了。大约18个月来，我一直致力于大规模微服务架构(大约150个微服务)，并不断发展壮大。

在某种程度上，微服务使大型企业能够利用孤立的代码库将大量工作分配给不同的团队。如果这些微服务的已发布API没有更改，则该服务的生产者或消费者都不会关心添加到该服务的维护或功能。

然而，产品作为一个整体的工作需要将所有的微服务以兼容的版本部署到部署环境中。

从高层次的角度来看，这些服务是否通过HTTPS、协议、定制的TCP协议或消息总线(如Kafka或MQ风格)进行通信并不重要。微服务A仍然作用于本应由微服务B创建的数据，如果它不在那里，用户将会感到疑惑。

如果用户在社交网络类型的产品上发布了一张照片，但几秒钟后没有显示出来，那么用户就会担心。如果它没有出现-因为微服务A将照片发布到某个消息队列，但是微服务B没有被部署来读取和响应该消息-那实际上是一个错误。就像用户脸上的一个对话框一样多。

这种依赖关系：微服务A需要微服务B，而微服务B需要微服务C，所有这些都是为了让产品和客户的用户旅程协同工作而部署的，这就是为什么它被称为微服务的“羊群”。(或者是一系列微服务，但羊群是更常见的行业名称)。

企业软件工程与初创企业有很大的不同。在我进入BigCo公司之前，我花了很多时间在“小项目和初创公司”领域。

我在这里列举了本文的一些假设，假设它们几乎是通用的。我的样本量很小，但我不认为我只是在我的经历中运气不好：

团队拥有的代码库。(因为在BigCos中，只有一个人拥有的东西会让人坐立不安，至少在我参加过的BigCos中是这样。而且只有一组人很容易寻呼他们)。

统一发现或明显相似的路线(“哦，看看/Search API！”也许在幕后是5个团队，提供20项微服务或Lambdas-无论是什么，打电话的人都不知道或不关心)。

微服务可以根据它们调用或依赖的下游或对等服务进行分组。(下一节将讨论这种集群或“集团”效应)。

注：微服务有可能没有所有者，但也有例外。也许拥有这一切的团队被解雇了，或者所有人都在招聘到接班人之前辞职了。从企业的角度来看，这很糟糕--一两年后，当微服务崩溃时，你将面临一场烫手山芋的游戏，谁需要修复它？…。因为有一些面向客户的漏洞，所以要加倍努力。这也很可能会让依赖这些微服务的团队感到紧张，因为，“嗯，谁在维护我们与之交互的广告数据存储库(Ad Data Repository)？”嗯，…“。

同样，一项微服务有两个所有者也是可能的--但应该是例外的。根据我的经验，这意味着要么开始重建一个整体，要么引入团队A不想部署但团队B想要部署的情况。

颠覆微服务群体：这是一群人(团队)。

如果我们把一个或多个产品所需的所有微服务看作是一群微服务，你就会注意到一些东西。你会注意到，这些群形成了微服务集团--例如，登录服务只与auth数据库和电子邮件服务对话，而从不与文件上传服务对话。

此外(因为这是企业)团队，而不是个人，拥有自己的服务。一个团队可能拥有一个小团体或几个小团体中的大多数服务。如果企业是明智的，那么可能会有一些领域驱动设计建模来更好地对这些集团进行分类。

我怀疑有三种、也许四种方式可以将企业拆分为一个产品(或多个产品)提供服务。

我所看到的企业组织团队、产品、微服务(以及你的牛群和集团)的方式。

请注意，这些图片中的星星可能是微服务，但也可能是前端库组件。

该组织拥有与用户关系密切的团队，以及创建与任何一个产品分离的服务的团队。想象一下，开发我们的社交媒体应用程序的团队，以及处理硬数据存储、供应商数据导入或与真实记录源接口的“数据平台”团队。

这很可能是康威定律在起作用：数据库团队维护大型数据库，并且(因为企业)当前的一切都流经大型数据库。这个大型数据库是记录的来源。

扩展团队将这些团队视为潜在的平台的一部分。用最普通的词来形容平台：“iOS团队”、“网络团队”、“Android团队”。“API”是由“后台团队”的工作人员提供的。

然而，这个图表仍然适用于这种团队结构。扩展团队的第7章也涉及到了这篇博客文章中的几个主题。

我们这里有多种产品。请注意，有些产品与其他产品没有联系。产品B多少有些关联：想想Instagram是如何利用Facebook进行授权的，但仅此而已。

跨职能团队并不是什么新鲜事--我在大学里上全面质量管理课的时候就听说过。

但这里的想法是，“两个披萨团队”应该被授权改变从用户界面到堆栈的所有功能。因为--这是一个经常被引用的定义--敏捷特性直到用户看到才会发布。

我还假设，这些跨职能团队并没有违反康威定律，但可能会在现有的组织结构之上嫁接一个跨职能层。

同样，我怀疑这种方法意味着您也有一个隐式分层模型。也许您有使用后端for前端设计模式创建的服务。我们的示例社交媒体企业可能有一个为移动应用程序提供数据的BFF微服务，以及一个“数据层”服务…。Alexa应用程序的BFF微服务使用的。事实上，我试图在图表中说明这一点。

我也不相信GraphQL能解决这个问题--你可能也有其他团队经常使用的查询和突变。

无论您的组织结构图看起来是什么样子，如果团队耦合到微服务，那么您可以让系统设计看起来像您的组织结构图，或者在该组织结构图上做外观。无论哪种方式，你都可以在微服务所有者周围画一个方框(希望如此！)。查找您的业务域的某些部分的边缘。或者，如果这样做不起作用，找到这些小团体，在他们周围画上方框。

让我们回顾一下这些图表。请注意不同结构的不同数据库组织。分层组织可能只有一个或两个由产品团队控制的数据库(为了“数据的封闭性”或“我们只关心数据的这一特定部分”)，而下游团队是“记录源”。

在一个完全跨职能的例子中，没有“下游”。然而，该组织仍有数据需要存储、维护和保护。团队可能会创建一个或两个数据库，或者每个微服务创建一个数据库来存储这些数据。然而，我认为“数据标准”是整个企业都关心的问题。数据是否在传输和REST中得到保护，可能使用经过批准的数据存储技术，并具有适当的访问权限？没有一家企业想要像Target或Equifax那样的隐私泄露和诉讼。

那么，一个企业或一组在企业内部从事单一产品工作的团队如何建立数据标准呢？

同样，“技术债务”--也许是“哦，是的，我们应该保护这个数据库，这是我们需要清理的一些技术债务”--对一个小集团的“技术债务”有何影响？还是产品？还是生意？

事实上，我开始不喜欢技术债务的类比，并开始倾向于系统功能能力的想法。

在美国，往往既有糟糕的道路，又有大量的道路建设，所以一个系统的功能容量模型就是一条运送客户旅程的道路，这对我来说是很自然的。

如果我们的旅程是为了给客户提供功能，那么我们想要铺设好的道路，这样我们就可以快速行驶，而不是你只能走35英里每小时的土路。我们还想要一些特定的、内置的道路性能：平稳的行驶，专家随叫随到，以防我们爆胎(或数据库！)，可能还需要某种指导，以确保我们的汽车在道路上使用是安全的，不会伤害他人或环境(比如到处喷洒客户数据)。

这是未来一篇博客文章的主题：微型服务牛群的道路和特征容量。现在我们了解了微服务、集团、羊群、产品、团队，以及企业如何以不同的方式将这些概念融合在一起，这将是一个更容易进行的对话。

作者：Ryan Wilcox，Wilcox Development Solutions首席开发员。你应该在推特上关注他的其他事情