大家好 我会告诉您有关微服务的信息，但是从与Vadim Madison稍有不同的角度来看，这篇文章“我们对微服务有什么了解” 。 通常，我认为自己是数据库开发人员。 微服务与它有什么关系？ Avito使用：Vertica，PostgreSQL，Redis，MongoDB，Tarantool，VoltDB，SQLite ...总共，我们有456+个数据库，可提供849+个服务。 而您需要以某种方式忍受它。

在本文中，我将向您介绍我们如何在微服务架构中实现数据发现。 这篇文章是我的Highload ++ 2018报告的免费抄本，可以在这里查看视频。

每个人都应该知道如何根据基础来构建微服务架构。 这是每个人通常开始的模式。 服务之间有一个共同的基础。 在幻灯片上，橙色矩形是服务，它们之间有共同的基础。

您不能那样生活，因为当服务之间（除了它们之间的直接通信）还通过数据库进行通信时，您不能孤立地测试服务。 一个服务请求可能会减慢另一服务的速度。 不好

从使用微服务体系结构的数据库的角度来看，应该使用“每个服务的数据库”模式-每个服务都有自己的数据库。 如果数据库中有很多分片，则应该共享基础，以便它们同步。 这是一个理论，但实际上并非如此。

在实际的公司中，他们不仅使用微服务，而且还使用整体服务。 有正确编写的服务。 并且有些旧服务仍使用通用的基本模式。

瓦迪姆·麦迪逊（Vadim Madison）在演讲中展示了这张具有关联性的照片。 只有他展示了它没有一个组成部分，并且其中的网络是统一的。 在中心的这个网络中，有一个点连接到许多点（微服务）。 这是一个整体。 在图中很小。 但实际上，整体是巨大的。 当我们谈论一家真正的公司时，您需要了解微服务共存的细微差别，包括先天和后天的微服务，但仍然是重要的整体架构。

整体如何在计划级别重写为微服务架构？ 当然，这是领域建模。 它到处都表明您需要进行域建模。 但是，例如，我们在Avito中创建了几年没有域建模的微服务。 然后我开始使用它和数据库开发人员。 我们知道完整的数据流。 这些知识有助于设计领域模型。

数据发现有一个经典的解释-这是如何处理分散在不同存储中的数据的方法，以便得出合计的结论并做出正确的结论。 这实际上是所有营销废话。 这些定义是关于如何将所有数据从微服务下载到存储的。 关于我几年前的报道，我们将不再赘述。

我将告诉您另一个过程，该过程与切换到微服务的过程更接近。 我想展示一种方法，您可以从微服务的角度来理解不断发展的系统的复杂性。 在哪里可以看到数百个服务，基地，团队和人员的整体情况？ 实际上，这个问题是报告的主要思想。

为了不死于这种微服务架构，您需要一个数字孪生兄弟。 您的公司就是提供技术基础架构的所有事物的总和。 您需要为所有这些困难创建足够的图像，并在此基础上快速解决问题。 这不是一个分析库。

我们可以为这样的数字双胞胎设定哪些任务？ 毕竟，这一切都始于最简单的数据发现。

问题：

• 哪些服务存储重要数据？
• 哪些个人数据没有存储？
• 您有数百个基地。 那里有什么个人资料？ 而在哪呢？
• 重要数据如何在服务之间流动？
• 例如，该服务没有个人数据，然后他开始收听公共汽车，并且出现了。 删除数据时，数据将复制到哪里？
• 谁可以处理哪些数据？
• 谁可以直接通过服务访问，有些可以通过数据库访问，有些可以通过总线访问？
• 谁可以通过其他服务来拉API句柄（请求）并下载某些内容？

这些问题的答案几乎总是元素图，关系图。 该图需要用新数据填充，更新和维护。 我们决定将此图称为“持久性结构”（翻译为“记住结构”）。 这是他的可视化。

让我们来看看这种记忆结构。

接口点 。 这些是用户与图形界面交互的元素。 一页上可以有多个UI点。 相对而言，这些是自定义关键操作。

端点 。 UI点混响端点。 在俄罗斯传统中，这称为笔。 服务句柄。 端点拉服务。

服务项目 数以百计的服务。 服务彼此连接。 我们了解哪种服务可以提供服务。 我们了解哪个对UI点的调用可以调用链中的哪些服务。

基地（在逻辑上） 。 作为存储术语的基础听起来很糟糕，因为该术语是指分析性的东西。 现在我们将数据库视为存储。 例如，Redis，PostgreSQL，Tarantool。 如果服务使用数据库，则通常使用多个数据库。

• 对于长期数据存储，例如PostgreSQL。
• Redis用作缓存。
• Tarantool，它可以快速计算数据流中的内容。

主持人 该数据库已部署到主机。 一个基地，一个Redis实际上可以生活在16台机器（主环）上，另外16个生活在奴隶上。 这样可以了解您需要限制访问哪些服务器，以便某些重要数据不会泄漏。

实体 。 实体存储在数据库中。 实体示例：用户，公告，付款。 实体可以存储在多个数据库中。 在这里重要的不仅是要知道这个实体在那儿。 重要的是要知道此实体有一个存储是Golden Source。 Golden Source是创建和编辑实体的基础。 所有其他基础都是功能缓存。 重要的一点。 如果上帝禁止，一个实体有两个黄金来源，那么必须对分离的来源进行费力的协调。 如果我们想用新功能丰富该服务，则必须授予数据库中的实体访问服务的权限。

团队 。 拥有服务的团队。 不属于团队的服务是差的服务。 他很难找到负责的人。

现在，我将与瓦迪姆·麦迪逊（Vadim Madison）的报告密切相关，因为他提到，最后提交该文件的人反映在服务中。 这是一个很好的起点。 但是从长远来看，这是不好的，因为最后一次在那里承诺的人可以退出。

因此，您需要了解团队，团队中的成员及其角色。 我们得到了一个简单的图形，其中每层上都有数百个元素。 您知道一个可以存储所有内容的系统吗？

关键点。 为了使此持久性结构有效，它不能只填充一次。 创建服务，消亡，分配存储，在服务器中移动服务，创建团队，破坏团队，切换人员到其他团队。 实体是新的，已添加到新服务中，已删除。 还重做了从GUI角度创建，注册，用户轨迹的端点。 最重要的不是在技术上需要存储的地方。 最重要的是使每个持久性面料层保持新鲜和最新。 它已更新。

我建议遍历各个层次。 我将说明我们如何做到的。 我将展示如何在各个层上完成此操作。

有关团队的信息可以从1C的组织结构中获取。 在这里，我想说明持久性结构不需要填充整个巨型图形即可填充。 每层都需要正确填充。

可以从LDAP获取有关人员的信息。 一个人可以在不同的团队中扮演不同的角色。 这是绝对正常的。 现在，我们已经建立了Avito人员系统，并从中将人员绑定到团队及其角色。 最重要的是，这样的简单数据就可以使它们至少保持链接到链接的末尾，从而使团队名称与1C组织结构中的团队相对应。

服务项目 对于服务，您需要获得名称和拥有它的团队。 来源是服务发现。 这是瓦迪姆·麦迪逊（Vadim Madison）在Atlas名称下提到的系统。 Atlas是服务的一般注册表。

有必要了解的是，几乎所有此类系统（例如Atlas）都存储了约95％的服务信息。 此类系统中缺少5％的服务，因为 无需注册就可以创建旧服务。 当您开始使用此方案时，您会感到自己丢失了什么。

存储是通用存储库。 它可以是PostgreSQL，MongoDB，Memcache，Vertica。 我们有几种用于存储发现的资源。 NoSQL数据库使用自己的一半地图集。 有关PostgreSQL数据库的信息，请使用yaml解析。 但是他们想使他们的存储发现更加正确。

因此，存储以及有关服务使用，使用或拥有（这些是不同类型）存储的信息。 瞧，我所描述的一切原则上都非常简单，即使在Google表格中也可以填写。

该怎么办？ 假设这是一个图形。 如何使用图表？ 将其添加到图形库。 例如，在Neo4j中。 这些已经是实际查询的示例以及这些查询的结果的示例。

第一种情况。 我们需要向基地发布权利。 该基地应严格服役。 它应仅包括此服务，并且应仅包括拥有该服务的团队成员。 但是我们生活在现实世界中。 通常，其他团队发现转到其他服务基地很有用。 问题：谁问权利授予？ 真正的大问题是数百个基地要了解谁负责。 尽管创建者是谁，但是很久以前就退出了，或者转移到了另一个职位，或者根本不记得是谁在使用它。

这是最简单的图形查询（Neo4j）。 您需要访问存储空间。 您从存储转到拥有它的服务。 转到拥有服务的团队。 为了获得进一步的服务，您将找到TechLead团队的成员。 在Avito中，产品团队有一名技术经理和一名产品经理，他们无法为基地提供帮助。 实际上只有一半的请求显示在幻灯片上。 访问存储不是原子操作。 要访问存储，您需要访问安装了该存储的服务器。 这是一个非常有趣的单独任务。

为了解决这个问题，我们添加了一个新实体。 这是一个安装。 这是术语问题。 有存储空间，例如Redis base（redis：地址）。 有一个主机-它可以是一台物理机，一个lxc容器，kubernetes。 在我们称为实例的主机上安装存储。

如上面的示例所示，它可以在三台主机上进行四个安装。 明智的做法是将生产用存储安装在单独的物理计算机上以提高性能。 对于开发环境，您要做的就是安装在一台主机上，并为Redis分配不同的端口。

向基地发出权利的第一个要求是头。 负责人确认可以授予权利。

接下来是请求的第二部分。 来自存储的第二个请求转到实例和主机。 该请求考虑了相应环境的所有安装。 幻灯片上是生产环境的示例。 基于此，已经颁发了连接到特定主机和特定端口的权限。 这是对非团队雇员的授予请求的示例。

考虑一个当团队需要雇用新员工的例子。 需要授予他对所有服务（对该命令的所有存储）的访问权限（对于初学者-只读）。 在幻灯片上，选择不完整的真实团队。 绿色圆圈是团队负责人。 粉色圆圈是团队。 黄色是服务。 许多黄色服务都有蓝色存储。 灰色的是主机。 紫罗兰是主机上存储的安装。 这是一个小单位的示例。 但是有许多单位的服务不是7，而是27。对于此类单位，情况将会很大。 如果使用持久性结构，则可以在其中进行请求并获得列表中的答案。

让我们继续填充我们的智能结构，并讨论业务实体。 Avito中的实体是公告，用户，付款等。 从我有关数据仓库的出版物（ HP Vertica，设计数据仓库，大数据 ， Vertica +锚模型=开始发展蘑菇 ）中，您知道在Avito中有数百个这样的实体。 实际上，不需要全部记录它们。 我从哪里可以获得实体列表？ 来自分析存储库。 您可以上传有关他们从何处获得此实体的信息。 在第一阶段，这就足够了。

我们进一步发展了这一知识：对于每个实体，我们都会在其中存储一个清单。 我们还指示存储将实体存储为高速缓存，或者存储将实体存储为Golden Source，即它是其主要源。

填写此列后，您将有机会提出请求。 您有一个实体，您需要了解：实体在什么服务中生活，它在哪里反映，在哪个存储中以及在哪个主机上安装？ 例如，在处理个人数据时，您需要销毁日志文件。 为此，了解日志文件可以保留在哪些物理计算机上非常重要。

幻灯片说明了对虚构实体的简单查询。 减少了存储量，以使图形适合幻灯片。 红色圆圈是实体。 蓝色圆圈是此实体所在的基础。 其余部分与前面的幻灯片相同：灰色圆圈是主机，紫色圆圈是主机上的存储安装。

因此，如果要通过PCI DSS，则需要限制对某些实体的访问。 为此，您需要限制对灰色圆圈的访问。 如果您需要实时访问，我们将关闭对紫色圆圈的访问。 这是静态信息。

当我们谈论微服务架构时，最重要的是它会发生变化。 重要的是不仅要在实体之间具有层次关系，而且要具有同级关系。 一堆服务是单级连接的一个示例，我们已经很好地使用了它。 捆绑形式为“服务呼叫服务”。 有关直接调用的信息-该服务将调用另一个服务的API。

还应该有关于以下形式的连接的信息：服务编号1将事件发送到总线（队列），服务编号2已预订此事件。 这就像通过总线的异步慢速连接。 就数据移动而言，这种关系也很重要。 使用此类链接，可以检查服务的运行，如果它们所订阅的服务的版本已更改。

有一个实体，我们知道它存储在某些存储中。 如果我们考虑使用实体寻找点的问题，那么随之而来的显而易见的查询就是周界检查。 存储属于某些服务。 该实体从外围何处泄漏（复制）？ 它可能通过服务呼叫泄漏。 服务联系，接收并保留了用户。 它会通过轮胎泄漏。 轮胎可以使用Londiste的RabbitMQ将彼此连接起来。 在Londiste幻灯片上，我们尚未加载它。 但是呼叫已加载。

这是一个真实请求的示例：一个广告，存储该广告的两个数据库，拥有这些数据库的两个服务。 在三列之后是与拥有此实体的服务一起使用的服务。 这些是潜在的泄漏点，值得补充。

端点。 Vadim提到您可以使用文档来构建端点服务的注册表。 您也可以从监视中获取此信息。 如果端点很重要，那么开发人员自己会将其添加到监视中。 如果未监视端点，则我们不需要它。

因此，可以从监视获得度量。 将指标绑定到存储，服务，主机，实例（数据库分片）和端点。

例如，遇到故障时，端点发出HTTP代码500，为了跟踪问题的根源，您需要为此端点发出请求。 从端点转到服务，再转到该服务调用的服务，从服务转到存储，从存储转到实例和主机。

此外，如果您向下浏览该图表，则可以在其基础上获得用于监视的标识符列表。 您可以在整个链上寻找该端点，这可能会导致故障。 在微服务架构中，端点故障可能是由部署了一个数据库分片的某些服务器上的网络故障引起的。 在监视中可以看到这一点，但是由于服务结构较大，因此在监视中检查所有服务非常费力。

测试。 要充分测试微服务，您需要将其与其他需要工作的服务进行检查。 您需要在测试环境中提高其调用的服务。 对于所谓的服务，请提高所有基础。 在我们的记忆结构中，我们得到了一个连通的子图。 在本专栏中，并非所有连接都是必需的，有些可以忽略。 该子图可以作为全封闭系统进行隔离负载测试。

现在，非常棒的是显示Avito实体图，在这里可以测试可以独立产生的微服务的孤立子图，并在生产中进行推广。 实际上，事实证明，几乎所有微服务的调用子图都会进入并离开整体。 这说明了一个事实，即如果您开发微服务并且不考虑此类后果，那么，如果没有整体，微服务架构仍然无法工作，并且不允许进行隔离测试。

, . , . . .

— , . .

• . . . . storage. — . endpoint. , , .. .
• . «» . , , , connection, connection , . , . ( , Anchor Modeling ). . « ». . Neo4j, .
• , . . , UI points frontend , backend , storage DBA, DevOps , .

in-progress

.
(Londiste, PGQ, RabbitMQ).

. UI points . . (Persistent Fabric), UI points, Endpoint, . , , , , .