Questions tagged «microservices»

微服务是相互独立的小型，独立进程，相互通信以形成利用与语言无关的API的复杂应用程序。这些服务是小型构建块，高度分离，并且专注于执行小任务，从而促进了模块化的系统构建方法。

5
跨微服务同步数据的正确方法是什么？
我对微服务架构比较陌生。我们有一个中等大小的Web应用程序，我在权衡将其细分为微服务而不是我们目前正在发展的单片系统的利弊。 据我了解，考虑微服务A，B每个微服务都依赖于另一个服务。如果通过A说某件事已发生更改来发布消息，则B可以使用该消息并复制的信息的本地副本，A并使用该副本执行所需的任何B操作。 但是，如果B出现故障/失败，过一会儿又重新出现，该怎么办。在那段停机时间内，A又发布了两条消息。如何B知道如何更新其本地信息副本A？ 当然，如果B是A队列的唯一使用者，那么一旦它重新联机，它就可以开始读取它，但是如果该队列还有其他使用者并且这些消息被消耗了怎么办？ 作为一个更具体的示例，如果Users服务在Billing微服务关闭时更新了其电子邮件地址，如果Billing微服务又恢复了，它如何知道电子邮件已更新？ 当微服务恢复正常运行时，是否会广播说“嘿，我已经备份了，给我您所有的当前信息？” 通常，什么是数据同步的最佳行业实践？
3
没有数据重复的微服务
我发现即使对于最简单的微服务设计，也很难避免重复数据或共享数据库，这让我觉得我缺少了一些东西。这是我面临的问题的基本示例。假设某人正在使用Web应用程序来管理库存，那么他们将需要两项服务：一个用于管理物品和库存数量的库存，以及一个用于管理用户数据的用户服务。如果我们要审核谁库存数据库，可以将用户ID添加到库存服务的数据库中，作为最后按价值库存的库存。 使用该应用程序，我们可能希望查看所有即将用完的物品，以及上次库存者的清单，以便我们可以要求他们再次进行库存。使用上述架构，将向库存服务发出请求，以检索数量小于5的所有商品的商品详细信息。这将返回包含用户ID的列表。然后，将对用户服务进行单独的请求，以获取从库存服务获得的用户ID列表的用户名和联系方式。 这似乎效率很低，并且在我们向不同的服务API发出多个请求之前，不需要更多的服务，而这些服务API又会进行多个数据库查询。一种替代方法是复制库存数据中的用户详细信息。当用户更改其联系方式时，我们将需要通过所有其他服务来复制更改。但这似乎与微服务的有限上下文概念不符。我们还可以使用一个数据库，并在不同的服务之间共享它，从而解决集成数据库的所有问题。 什么是实现此目的的正确/最佳方法？
1
SOA /微服务：如何处理服务间通信中的授权？
前景 我们正在从单一平台过渡到更加面向服务的体系结构。我们正在应用非常基本的DDD原则，并将我们的域划分为不同的有界上下文。每个域都是分布式的，并通过Web API（REST）公开服务。 由于我们的业务性质，我们提供诸如订舱，服务，客户，产品等服务。 我们还建立了一个Identity Server（基于Thinktecture Identity Server 3），其主要作用是： 集中身份验证（给定颁发令牌的凭据） 在令牌中添加声明，例如：客户范围（按照客户，我是指执行请求的应用程序），客户标识符（按照客户，我是指使用该应用程序的人） 我们还介绍了API网关的作用，它可以集中外部访问我们的服务。API网关提供的功能不需要深入了解内部域，例如： 反向代理：将传入请求路由到适当的内部服务 版本控制：API网关的一个版本映射到内部服务的不同版本 身份验证：客户端请求包括由Identity Server发行的令牌，API网关会验证令牌（确保用户说的是她的身份） 节流：每个客户端的请求数量限制 授权书 与授权有关，这不是在API网关中管理，而是在内部服务本身中进行管理。我们目前正在执行两种主要的授权类型： 基于客户范围的授权。示例：客户端（使用我们的API的外部应用程序）需要范围“ bookings”来访问Bookings服务API端点 基于客户的授权。示例：仅当客户（使用应用程序的自然人）是预订的参与者时，才能从预订服务访问端点GET / bookings 为了能够处理内部服务中的授权，API网关仅转发令牌（在将请求路由到内部服务时），该令牌既包含有关客户端（执行请求的应用程序）的信息，也包含有关客户的信息（作为声明）有人在客户端应用程序中登录的情况）。 问题描述 到目前为止，到目前为止还不错，直到我们引入了服务间通信（某些服务可以与其他服务进行通信以获得一些数据）。 题 在服务间通信中，我们应该如何处理授权？ 考虑的选项 为了讨论不同的选项，我将使用以下示例方案： 我们有一个名为ExternalApp的外部应用程序，该应用程序访问我们的API（可以将ExternalApp视为客户端），以建立预订流程 ExternalApp需要访问预订服务，因此我们授予ExternalApp范围“预订” 在内部（这对于ExternalApp来说是完全透明的），预订服务使服务服务获得预订的默认服务，例如航班，保险或租车 在内部讨论此问题时，会弹出几个选项，但我们不确定哪个选项最好： 当Bookings与Services通信时，它应该只转发他从API网关收到的原始令牌（表明客户端是ExternalApp）。 启示：我们可能需要将不应该被授予的范围授予ExternalApp。示例：ExternalApp可能需要同时具有“预订”和“服务”范围，而只有“预订”范围才足够 当Bookings与Services通信时，它转发一个令牌，指示该客户端现在已成为Bookings（而不是ExternalApp），并且添加了一个声明，表明Bookings模仿了原始客户端ExternalApp 通过还包括原始客户端是信息ExternalApp的服务业务也可以做逻辑如过滤取决于原调用一些服务（如用于内部应用程序，我们应该返回所有的战斗，外部应用程序只有一些） 服务不应相互通信（因此我们甚至不应面对这个问题） 预先感谢您的输入。
3
从整体式迁移到微服务时，如何处理外键约束？
我的团队正在从单一的ASP.NET应用程序迁移到.NET Core和Kubernetes。代码更改似乎正在进行中，并且可以预期，但是我的团队遇到的很多问题都围绕数据库进行。 当前，我们有一个相当大的SQL Server数据库，其中包含了整个业务的所有数据。我提议我们以与拆分代码类似的方式拆分数据库-一个逻辑数据库中的目录数据，另一个数据库中的库存数据，另一个数据库中的订单等-每个微服务都将成为其数据库的关守者。 这就意味着跨微服务边界的外键将必须被删除，跨边界的程序和视图将被禁止。所有数据模型可能会或可能不会驻留在同一个物理数据库中，但是即使它们存在，它们也不应直接相互交互。订单可能仍按ID引用目录项，但不会在数据库级别严格执行数据完整性，并且必须将数据以代码而不是SQL形式联接。 我认为这些损失是迁移到微服务并获得随之而来的可伸缩性优势时的必要折衷。只要我们明智地选择接缝并围绕它们发展，那应该没问题。其他团队成员坚持认为，所有内容都必须保留在同一个整体数据库中，以便所有内容都可以是ACID并在各处保留引用完整性。 这使我想到了我的问题。首先，我对外键约束和加入的立场是否合理？如果是这样，有人知道我可以提供给同事的任何可靠的阅读材料吗？他们的立场几乎是宗教性的，他们似乎不会因马丁·福勒本人告诉他们自己的错而受到任何影响。
1
为什么大多数API网关解决方案都不支持“聚合”？
在阅读有关API Gateway的内容时，每一次出现的一件事是API Gateway是一个您应该在其中汇总多个端点的结果的地方。听起来真的很好。但是，许多流行的API网关解决方案（例如AWS API Gateway，Kongo和Netflix Zuul）不支持该功能。您需要自己修改或实施自定义过滤器。 聚合被视为不良做法吗？人们如何从多个端点返回结果？
3
API网关（REST）+事件驱动的微服务
我有一堆微服务，这些服务根据API网关模式通过REST API公开。由于这些微服务是Spring Boot应用程序，因此我正在使用Spring AMQP来实现这些微服务之间的RPC风格的同步通信。到目前为止，一切进展顺利。但是，我对事件驱动的微服务体系结构了解得越多，对诸如Spring Cloud Stream之类的项目的了解越多，我就深信我可能会采用RPC同步方法以错误的方式进行操作（特别是因为我需要按比例缩放）以便每秒响应来自客户端应用程序的数百或数千个请求）。 我了解事件驱动架构背后的观点。我不太了解的是当坐在期望对每个请求都响应的模型（REST）后面时，如何实际使用这种模式。例如，如果我将我的API网关作为一个微服务，而另一个将存储和管理用户的微服务作为一个微服务，那么我该如何GET /users/1以纯粹的事件驱动方式对诸如a之类的事物进行建模呢？
3
在微服务之间共享DTO对象
TL; DR-可以在服务之间共享POJO库吗？ 通常，如果可能的话，我们希望将服务之间的共享严格限制为无共享。共享数据的服务是否应提供客户端库供客户端使用一直存在争议。客户端库通常对于服务的客户端是可选的，并且可以使用API​​，但是无论他们愿意使用API​​，还是使用客户端库还是使用替代语言并使用库的一般方面，等等。 就我而言-我考虑一种创建数据对象的服务。假设此对象是PET。不是数据库实体，而是严格地隐式表示基础数据的POJO。该POJO是API定义的。假设：宠物-年龄，体重，姓名，所有者，地址，种类等。 服务1 -PetKeeper：无论出于何种原因，它都会生成一个pet，并保留所有数据，并且必须引用此服务来获取pet，或者对pet进行修改，可以说名称更改或地址更改必须通过以下方式完成：此服务的API调用。 服务2 -PetAccessor：此服务收集宠物并进行验证检查 服务3,4-更多中间服务呼叫 服务5-用户界面 这些都是很随意的，但重点很简单。UI或某些面向用户的服务希望以某种方式呈现此“ PET”对象。它必须通过API调用一个服务，该服务调用一个服务，再调用一个服务，依此类推，直到到达收集所需信息并开始中继的服务为止。最后，UI服务具有要显示的PET对象。 这很普遍-但出于我们的绝对思想，我们在每次服务中都复制了PET对象。DRY（请勿重复）原则仅适用于服务内的代码，不适用于所有服务，但重点仍然存在。如果我们添加一个字段怎么办...我们必须在每个字段中修改POJO的5个服务。 -或-我们可以提供一个Pet-Objects-Library，其中包含API中的一些pojo，并且每个服务都可以导入/依赖该库。与服务本身无关，而与常规库无关。我喜欢这个想法，以便每个服务都具有相同类型的对象，并且更新更加容易。但是我担心神物。 优点/缺点是什么-最佳设计是什么？您做了什么在服务之间传递数据，以最大程度地减少重复执行相同的POJO类，同时保持解耦状态？
6
自治微服务，事件队列和服务发现
最近，我一直在阅读有关微服务的很多文章，这是到目前为止我得出的一些结论（如果我在任何时候错了，请更正我）。 微服务架构与域驱动设计配合得很好。通常一个MS代表一个有界上下文。 如果微服务A需要驻留在微服务B中的功能，则我的模型可能是错误的，并且A和B 实际上应该是一个微服务/ BC。 微服务之间的同步通信（直接HTTP请求）很糟糕，导致它违背了微服务的目的，并引入了组件之间的耦合。 服务之间的异步通信是可取的。服务应将事件发布到消息队列，以便其他服务可以订阅和处理事件的一部分，或使用它复制上下文所需的部分数据。这样，服务可以处理请求，甚至其他服务也已关闭，而在同步通信中则不会。 如果微服务A发布事件，微服务B订阅该事件并产生一个新事件作为结果，则微服务A不应是一个正在处理的新创建事件，因为这将是循环依赖性。在这种情况下，我们应该引入第三种微服务，或者将A和B合并到AB微服务中。 微服务实际上是一个误导性术语。我们应该为小环境而努力，但这不是必须的。术语不应该是“微服务”，而是“ 足够大以进行工作服务 ”。 微服务使我们可以更轻松地引入新功能，而不必担心会破坏整个系统。可以通过引入新服务或重构现有服务之一来完成。 每个微服务都应具有自己的数据存储。数据复制/复制是此体系结构中的理想行为。 除了证实我对这种体系结构的理解之外，问题的其他部分主要与服务发现有关。如果服务异步通信，并使用亚马逊SQS之类的中央事件队列，这是否意味着服务发现在这样的体系结构中没有位置？ 服务不应对系统中的其他服务有任何了解。他们只知道应该发布或订阅的上下文和事件吗？
5
微服务和消费者的授权和认证系统
我们计划将公司系统重构为基于微服务的系统。该微服务将由我们自己的公司内部应用程序以及需要的第三方合作伙伴使用。一种用于预订，一种用于产品等。 我们不确定如何处理角色和范围。这个想法是创建3个基本用户角色，例如Admins，Agent和End-Users，并让消费者应用程序根据需要微调作用域。 管理员可以默认（针对其公司）创建，更新，读取和删除所有资源。 代理可以为其公司创建，更新和读取数据。 最终用户可以创建，更新，删除和读取数据，但不能访问与代理或管理员相同的端点。他们也将能够创建或修改数据，而不必与代理或管理员处于同一级别。例如，最终用户可以更新或阅读他们的帐户信息，就像代理可以为他们完成此操作一样，但他们看不到或更新管理员注释。 假设代理默认情况下可以为其公司创建，读取和更新每个资源，这是可以为其令牌/会话请求的最大范围，但是客户端（API使用者）应用程序的开发人员已决定他们的代理之一可以仅读取和创建某些资源。 更好的做法是在我们的内部安全性中处理此问题，然后让他们在数据库中写入该数据，还是让客户端通过请求范围较小的令牌在内部进行处理，并让他们编写哪个代理在数据库中具有哪个范围？这样，我们仅需跟踪令牌范围。 不利的一面是，我们的团队还需要在内部应用程序中创建经过微调的访问机制。 用这种思维方式，微服务及其授权系统不应受到客户需求的困扰，因为它们只是消费者，而不是系统的一部分（即使其中一些消费者是我们自己的内部应用程序）？ 这是一个好的方法吗？
4
微服务REST或AMQP，在这种情况下
我读过许多有关微服务体系结构的文章，我想知道何时使用AMQP或REST。 我读到服务之间的松耦合是一件好事，在这种情况下，AMQP似乎是一个不错的选择。但是，如果我们使用AMQP，则意味着我们不再需要REST端点（但这意味着我们将失去HATEOAS概念）。 但是REST真的是构建我的服务的好方法吗？原因我将不使用任何端点...在这种情况下，一个端点比另一个端点更好？ 什么时候应该使用其中一个？
3
扩展整体与扩展微服务
使用微服务的常见论点之一是更好的可伸缩性。但我想知道这种说法是否真的有效。 假设我们有一个包含10个微服务的应用程序，其中9个有两个实例（用于冗余），其中一个有4个实例来处理负载（可伸缩性）。赞成微服务的论点是，您可以独立于其他服务扩展此微服务。 但是，可以说所有10个微服务都是单个整体中的模块，并且已部署了该整体的几个（例如22个，类似于上面的总和）实例。该系统应该能够处理一个关键部分的负载，因为有足够的实例可以执行此操作。如果实例中不需要程序逻辑，唯一的缺点是二进制文件和所需的RAM数量会稍大。但话又说回来，在大多数情况下，差异应该不会太大-至少与堆栈的其余部分相比（与Spring Boot相比）应该没有。可缩放的monlith的优势将是没有（大部分）分布式系统的谬误的更简单的系统。 我想念什么吗？
1
微服务应该是用户吗？
我们正在尝试确定授权微服务体系结构中用户的最佳方法，同时确保微服务的权限受到限制。我们的体系结构使用中央授权服务来处理JWT令牌的发行。 我们有以下要求： 应该限制​​用户执行某些角色。例如，用户只能创建/修改/读取他拥有的内容。 微服务应仅限于其所需的权限。例如，应该明确禁止只需要从另一个服务读取数据的微服务将数据写入该服务。 例如，假设我们有一个系统，用户可以在其中将图片上传到图像存储服务。我们有一个标记服务，可以自动标记带有位置的图片。用户只能CRUD他们自己的照片。标记服务可以从图像存储服务读取任何图像，但是不能修改/删除。 使用JWT令牌实现上述目标的好方法是什么？我们讨论过的一些解决方案是： 图像存储服务公开了2个API，一个在外部可用（给用户CRUD访问），另一个在内部可用（给内部只读访问）。似乎不灵活-如果另一项内部服务需要对所有图像进行读/写访问（例如，自动删除显式图像的访问），该怎么办？ 我们在用户的JWT中设置了两个权限，一个权限是CRUD_OwnImages，另一个权限是READ_ForAnalysis。标记服务可以查看用户是否具有READ_ForAnalysis权限，如果有，则发出适当的请求。我们还有另一个微服务，用于检查用户是否具有CRUD_OwnImages以便对用户自己的映像执行CRUD操作。这使每个微服务都有责任确保用户受限于他需要的操作。图像存储无法用这种方法来限制每个微服务，因此它可能容易出错和出错。 我们给标签微服务自己的用户，并以READ_ForAnalysis作为权限。然后，当加标签服务从图像存储请求图像时，将授予它们访问这些图像的权限，但禁止对其进行修改。用户的用户仅具有CRUD_OwnImages权限，因此他只能从前端检索和访问其图像。如果另一个服务需要对所有数据使用CRUD，则可以给它CRUD_AllData或类似的名称。我们喜欢这种方法，因为每个服务现在都负责其自己的数据（而不是在多个服务之间重复该逻辑），但是如果该服务同时需要用户权限和微服务权限怎么办？我们可以安全地发送两个JWT令牌（用户的和微服务的）吗？有没有一种方法可以安全地组合权限并通过发送？例如 如果更下游（需要2或3个微服务）需要用户信息，则会使问题更加严重。我们是否只是假设将单个微服务限制在它们自己需要的动作上，而不是将其明确化，这取决于单个微服务？
1
跨多个微服务跨数据搜索
我在微服务和旧数据库之间分配了某个域的数据。我的搜索跨越了旧版和微服务数据库上的字段。以前（在拆分微服务之前），它是通过1个sql查询完成的。现在，我需要一个REST调用和一个对旧数据库的查询来提供此搜索功能。我们在这里谈论的是几百万行。我怎样才能做到最好？由于数据量大，REST调用通常也会返回分页结果。激发SQL调用并将结果与​​REST响应合并和合并的幼稚方法太慢且不切实际。
3
部署Web应用程序的系统的健康检查的范围应该是什么？
今天，我有一项任务是为长期运行的服务“编写运行状况检查”，该服务是用于部署Web应用程序的业务流程系统。 我试图确定这种健康检查的范围，并提出了与健康检查范围有关的以下问题： 如果业务流程系统报告任务正在运行，则认为服务正常是否足够好？ 还是我们应该手动ping每个服务？ 还是应该走得更远，并尝试确保网络应用按照显示网页的目的进行操作？ 运行状况检查是否还必须检查某些依赖服务是否也在运行？就像数据库或业务流程系统本身一样。还是其他健康检查的责任？ 最后，如果其中一项从属服务失效，并且Web应用程序随后发生故障，那么Web应用程序应该报告不良运行状况还是良好运行状况，因为这不是Web应用程序的故障？ 我知道这是5个独立的问题，但是它们都与部署Web应用程序的长期运行服务的运行状况检查范围有关，因此我认为将它们分组在一个问题中会更有意义。 这对我来说很难实现，因为我不确定什么是健康的定义或类似标准的健康检查应该是什么样。 此特定服务的健康检查应包含哪些内容？
4
微服务中的多对多关联
我目前有两个微服务。我们称它们为A和B。 微服务下的数据库A具有下表： A |-- users 微服务下的数据库B具有下表： B |-- trackers 需求说明users并trackers具有多对多关系。 我不确定如何在微服务架构中正确处理此问题。 我可以看到此方法是以下三种方法之一： 一个user_trackers表添加到微服务A。这类似于包含表中的“ users和”的“外键”的联接表trackers。 一个owners表添加到微服务B。该表的作用类似于多态联接表。这将允许任何服务创建与跟踪器的关联。这可能看起来像这样： B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id 为保存记录users并trackers在每个微服务。使它们与某种pubsub系统保持同步。 我最初打算使用选项2，因为我喜欢它保留了事务边界。我可以创建一个跟踪器并将其与某些原子关联。但是，它似乎超出了微服务的范围B。微B服务为什么要关心微服务A想要建立关联？ 我觉得这里可能存在一个我不知道的好模式。我提出的任何选择是否有意义？还有另一种可能更有意义的选择吗？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.