现代微服务目录

运营微服务/面向服务体系结构的组织面临各种与技术和人员相关的问题。在过去的几年里，公司一直在将大规模的单一应用程序迁移到较小的微服务(想想做一件事的服务，比如归档PDF)，甚至是面向服务的架构(例如，按域服务、支付、计费、身份验证)。

毫无疑问，整体式架构带来了许多问题：容易将域和数据紧密耦合、部署过程较慢，以及长时间的测试运行，仅举几例。打破铁板一块似乎是解决这些问题的灵丹妙药。SOA可以提供对域及其系统的团队级别所有权，数据是分离的，功能/修复可以单独部署。不幸的是，SOA伴随着它自己的一组问题。

巨石已经存在一段时间了。有很多关于驯服巨石的文章已经写过了。当我们开始构建Cortex时，我们一直在与工程师谈论他们处理微服务架构的经验。以下是我们在驯服你的微服务方面学到的一些东西。

一块巨石，尽管有很多缺点，但很容易推论。没有网络呼叫。在代码库中的其他地方调用函数不会产生任何开销。如果您使用的是类型化语言，则可以在编译时捕获API更改。所有的代码都在一个地方--如果你这么喜欢，你可以很容易地窥探引擎盖下的情况。

SOA带来了一系列技术挑战，包括操作复杂性和性能问题。您现在必须考虑：

API版本控制-如果支付团队在没有通知我的情况下对其API进行了重大更改怎么办？

网络问题-如果我没有收到付款已通过的确认，会发生什么情况？

虽然认为文化和人员问题是架构选择带来的重大挑战听起来可能有些奇怪，但请记住，大多数组织转向SOA是为了扩展他们的团队，而不是为了扩展他们的软件。

跨服务和团队分配域、数据和发布节奏的所有权可以提高工程组织的速度。

不幸的是，分配所有权恰恰做到了这一点--团队在操作程序、文档实践等方面开始出现分歧。随着组织规模的扩大，这可能会严重影响工作效率，并最终将您的速度带回原点。

增加工程师的成本变得很高-每个团队都维护着自己的流程。在不同团队之间跳槽的工程师可能要学到和新员工一样多的东西。

运营分类需要更长的时间-随着组织的发展，部落知识会逐渐消失，这使得回答以下问题变得更加困难：现有哪些服务，这些服务做什么，以及谁拥有这些服务。

团队之间的通信开销-过度共享信息很嘈杂，共享不足(例如，更改API时)在最坏的情况下可能会导致停机或功能问题，并直接影响底线。

希望扩大您的团队规模吗？现在是开始思考这些挑战以及如何应对它们的时候了。

没有解决这些问题的灵丹妙药。任何工具或流程的组合都不能保护您。然而，预防真的比治疗好。

把它想象成一针流感疫苗--你知道它是流感季节，得流感很糟糕，即使你可能仍然得了流感，你也永远不会后悔为成功做好准备。

要推广的一个很好的习惯是在进入实现之前考虑API和数据模型。

防止这种情况的一种方法是遵循亚马逊的模式-API是团队通信的唯一方式。这意味着服务所有者应该：

当与工具(如OpenAPI或GRPC)结合使用时，此工作流可提供额外的好处。如果提前设计了模式和API，您可以使用：

在更改发布之前，使用您的代码评审过程循环引入合适的涉众。

Atlassian是成功使用规范优先API设计来改进其开发生命周期的一个示例。我发现https://www.atlassian.com/blog/technology/spec-first-api-development是使用OpenAPI作为支持规范优先开发的工具的一个很好的概述。

当多个团队开始跨域依赖相同的数据模型时，这是一个整体的转折点。这减慢了整个组织的开发节奏，由此产生的意大利面数据模型使得对代码库进行推理变得更加困难。

在SOA中也很容易沿着相同的路线走下去。有一些习惯可以帮助防止这种噩梦：

减少服务之间在数据级别的依赖性-例如，将引用ID存储到不同服务中的资源，并通过其API获取数据

确保利益相关者(业务、开发人员、服务消费者)不会直接在您的数据上构建工具。这会锁定您的数据模型，并阻止您作为服务所有者进行迭代。取而代之的是，通过API或分析数据流公开数据(具有其自己的约定)。

对于每个团队都以自己的方式做事，有一个显而易见的解决方案--让团队以标准化的方式轻松做事。

例如，Atlassian已经建立了一个内部PaaS，本质上是对AWS的薄薄包装。通过这样做，开发人员可以获得他们想要的资源，但是平台会自动增加标准监控、日志记录等功能。

设计良好的工具提供了一种标准的工作方式，加快了开发人员的速度，并确保团队以一致的方式工作。

这甚至延伸到了文档。Spotify和Atlassian已经构建了内部工具，可以标准化围绕其微服务的信息发现。Spotify的System-Z和Atlassian的显微镜提供了有关每项服务的详细信息的真实来源，例如系统所有权、文档/Runbook的链接以及最近的部署。使它们变得更加强大的是，它们是进入有关服务待命轮换、监控仪表板链接、日志记录等进一步信息的入口点。

这种信息标准化提高了工程上马时间和运营效率-所有服务都以相同的方式运行，开发人员有一个单一的来源来查找有关其服务的关键信息。

在问题失控之后，许多组织最终为人类构建了内部服务注册表-太多的服务、不断增长的团队和人员流动、远程开发人员等等。

Corpe提供了一种标准的、自以为是的方式来组织有关所有服务的信息，并支持以下功能：

用于回答诸如存在哪些服务？谁拥有此服务？此服务的Runbook在哪里？"；，"；等问题的仪表盘。

向您显示服务健康状况的审计报告：是否每个服务都有所有者、OnCall轮换等。

与第三方工具集成-例如，当PagerDuty触发警报时，Cortex可以发送一条松弛消息，其中包含有关服务的信息，如所有权、来自GitHub的最新提交、最新部署等。

在我们的主页上联系我们请求演示，我们很乐意向您展示我们已经构建了什么，并帮助您避免一些令人头疼的面向服务的体系结构带来的问题。即刻登上现代微服务目录！