Questions tagged «microservices»

一种将单个应用程序开发为一组可单独部署的小型服务的体系结构方法。

7
编排微服务
编排微服务的标准模式是什么？ 如果微服务仅了解其自己的域，但是有数据流需要多个服务以某种方式进行交互，那么该怎么办呢？ 假设我们有这样的事情： 开票 装船 为了便于讨论，我们假设一旦订单发货，就应创建发票。 某处某人按下按钮GUI“我已经完成，让我们开始吧！” 在经典的整体式服务体系结构中，我会说要么进行ESB处理，要么运货服务具有发票服务的知识，然后就调用它。 但是，在这个勇敢的微服务新世界中，人们如何处理这一问题？ 我确实认为这可以认为是高度基于意见的。但是它有一个具体的方面，因为微服务不应该做到这一点。因此，必须有一个“根据定义应该做什么”，它不是基于观点的。 射击。
10
跨REST微服务的交易？
假设我们有一个User，Wallet REST微服务和一个将事物粘合在一起的API网关。当Bob在我们的网站上注册时，我们的API网关需要通过User微服务创建用户，并通过Wallet微服务创建钱包。 现在，这是一些可能出错的场景： 用户Bob的创建失败：可以，我们只向Bob返回一条错误消息。我们正在使用SQL事务，因此没人能在系统中看到Bob。一切都很好:) 用户Bob已创建，但是在创建我们的电子钱包之前，我们的API网关会严重崩溃。现在，我们有一个没有钱包的用户（数据不一致）。 用户Bob已创建，并且在我们创建电子钱包时，HTTP连接断开。钱包创建可能成功，也可能没有成功。 有哪些解决方案可以防止这种数据不一致的情况发生？是否存在允许事务跨越多个REST请求的模式？我已经阅读了有关两阶段提交的Wikipedia页面，该页面似乎涉及到此问题，但是我不确定如何在实践中应用它。这种原子分布式事务：一个RESTful设计纸似乎也有意思，虽然我还没有看过它。 另外，我知道REST可能不适合此用例。处理这种情况的正确方法也许会完全丢弃REST，并使用其他通信协议（例如消息队列系统）来进行处理吗？还是我应该在应用程序代码中强制执行一致性（例如，通过具有检测不一致之处并进行修复的后台作业，或者通过在用户模型上使用“创建”，“创建”的值等方式具有“状态”属性）？
10
GraphQL和微服务架构
我试图了解GraphQL在微服务体系结构中最适合使用的地方。 关于仅使用1个GraphQL模式作为API网关将请求代理到目标微服务并强制其响应的问题，存在一些争论。微服务仍将使用REST / Thrift协议进行通信。 相反，另一种方法是每个微服务具有多个GraphQL模式。拥有一个较小的API网关服务器，该服务器使用请求的所有信息+ GraphQL查询将请求路由到目标微服务。 第一种方法 具有1个GraphQL架构作为API网关将具有一个缺点，即每次您更改微服务合同的输入/输出时，我们都必须在API网关侧相应地更改GraphQL架构。 第二种方法 如果每个微服务使用多个GraphQL架构，则以某种方式有意义，因为GraphQL会强制执行架构定义，并且使用者将需要尊重微服务提供的输入/输出。 问题 您是否认为GraphQL适合设计微服务架构？ 您如何设计具有可能的GraphQL实现的API网关？
4
微服务认证策略
我很难为微服务架构选择一种体面/安全的身份验证策略。我在该主题上找到的唯一SO帖子是：Microservice Architecture中的单点登录 我的想法是在每个服务（例如身份验证，消息传递，通知，配置文件等）中具有对每个用户的唯一引用（从逻辑上说，然后是其用户user_id），并具有id在登录时获得当前用户的可能性。 从我的研究中，我发现有两种可能的策略： 1.共享架构 在这种策略中，身份验证应用是其中一项服务。但是每个服务都必须能够进行转换session_id=>，user_id因此必须非常简单。这就是为什么我想到Redis时会存储key：value的原因session_id:user_id。 2.防火墙架构 在此策略中，会话存储并不重要，因为它仅由身份验证应用处理。然后，user_id可以将其转发到其他服务。我想到了Rails + Devise（+ Redis或mem-cached，或cookie存储等），但是有很多可能性。唯一重要的是，Service X永远不需要对用户进行身份验证。 这两种解决方案在以下方面的比较： 安全 健壮性 可扩展性 使用方便 也许您会建议我在这里没有提到的另一种解决方案？ 我更喜欢＃1解决方案，但还没有发现很多默认的实现方式可以确保我朝正确的方向前进，因此可以确保我的安全。 我希望我的问题不会被解决。我真的不知道还有什么要问的。 提前致谢
5
微服务和数据库联接
对于将单一应用程序拆分为微服务的人们，您如何处理拆分数据库的难题。出于性能和简单性的原因，我从事的典型应用程序进行了很多数据库集成。 如果您有两个逻辑上不同的表（如果有的话，则是有界上下文），但是经常对大量数据进行汇总处理，那么在整体中，您很有可能避免面向对象，而是使用数据库的标准JOIN功能可在将聚合视图返回到您的应用程序层之前处理数据库上的数据。 您如何证明将此类数据拆分为微服务是合理的，因此可能需要您通过API（而不是数据库）“联接”数据。 我读过Sam Newman的《微服务》一书，在有关拆分Monolith的章节中，他举了一个“打破外键关系”的示例，他承认通过API进行联接会比较慢-但他继续说是否您的应用程序是否足够快，是否比以前慢？ 这似乎有点不高兴吗？人们的经历是什么？您使用什么技术来使API联接的性能令人满意？
1
Elixir / erlang在哪里适合微服务方法？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 改善这个问题 最近，我一直在使用docker compose做一些实验，以部署多个协作微服务。我可以看到微服务提供的许多好处，并且现在有了一个很好的工具集来管理它们，我认为跳入微服务旅行并不难。 但是，我也一直在尝试Elixir，我非常喜欢它本身提供的好处。鉴于它鼓励将代码打包到多个解耦的应用程序中，并支持热代码升级，您如何将docker与elixir（或erlang）混合使用？ 例如，如果我要使用docker，因为它提供了dev-prod奇偶校验，那么elixir怎么适合呢？鉴于Docker容器是不可变的，我将失去进行热代码升级的能力，对吗？蓝色/绿色部署或Canary版本又如何呢？ 我的意思是，我可以用Elixir编写微服务，并像使用其他任何语言编写微服务一样使用。多语制仍然是微服务的好处之一，但是我没有得到使用OTP平台的全部好处，我猜想纯协作式erlang应用程序比使用中间队列在以不同（或不同）语言编写的微服务之间进行通信的方式更为优化。
3
API网关与反向代理
为了处理微服务架构，它通常与反向代理（例如nginx或apache httpd）一起使用，并且出于交叉考虑， 使用API​​网关模式。有时反向代理会完成API网关的工作。 很高兴看到这两种方法之间存在明显的差异。看来API网关使用的潜在好处是调用了多个微服务并汇总了结果。API网关的所有其他职责都可以使用反向代理来实现，例如： 身份验证（可以使用nginx LUA脚本来完成）； 运输安全。它本身就是反向代理任务； 负载均衡 .... 因此，基于此有几个问题： 同时使用API​​网关和反向代理是否有意义（例如request-> Api网关->反向代理（nginx）->具体的mictoservice）？在什么情况下？ 使用API​​网关可以实现的其他区别还有反向代理不能实现的其他区别，反之亦然？
4
微服务：如何处理外键关系
微服务架构建议每个服务应处理自己的数据。因此，任何依赖于其他服务（服务B）拥有的数据的服务（服务A）都不应通过直接DB调用而是通过第二个服务（服务B）提供的api访问此类数据。 因此，微服务最佳实践对检查外键约束有何建议？ 示例：我正在开发产品的交付功能（微服务1），并且某些产品只能交付到产品表中提到的某些位置，只有产品微服务（微服务2）可以访问该表。 我如何确保微服务1（即送货功能）不会将订单送到未服务的地点。我有这个问题，因为交付功能无法直接访问产品数据库，因此在将交付订单放入交付数据库中时，在数据库级别没有适用的约束（无法检查产品数据库中是否存在外键匹配项）或表格）。
3
微服务与单片架构[已关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 改善这个问题 我读了一些有关微服务的文章，但我对此有些兴趣，好像是一个有趣的概念。但是我想知道，使用微服务比单片架构有什么优点和缺点，反之亦然。 微服务何时更合适，单片架构更适合。
4
数据非规范化如何与微服务模式一起使用？
我刚刚读了一篇有关微服务和PaaS体系结构的文章。在那篇文章中，作者大约说了三分之一，（在Denormalize像Crazy一样）： 重构数据库架构，并对所有内容进行规范化，以允许数据的完全分离和分区。也就是说，请勿使用为多个微服务服务的基础表。不应共享跨越多个微服务的基础表，也不应共享数据。相反，如果多个服务需要访问相同的数据，则应通过服务API（例如已发布的REST或消息服务接口）进行共享。 从理论上讲，这听起来不错，但在实践中，有一些严重的障碍需要克服。其中最大的问题是，通常数据库是紧密耦合的，并且每个表与至少一个其他表都有某种外键关系。因此它可能是不可能的分区的数据库进Ñ通过控制子数据库Ñ微服务。 所以我问：给定一个完全由相关表组成的数据库，如何将其规范化为较小的片段（表组），以便可以由单独的微服务控制这些片段？ 例如，给定以下（虽然很小，但示例）数据库： [users] table ============= user_id user_first_name user_last_name user_email [products] table ================ product_id product_name product_description product_unit_price [orders] table ============== order_id order_datetime user_id [products_x_orders] table (for line items in the order) ======================================================= products_x_orders_id product_id order_id quantity_ordered 不要花太多时间来批判我的设计，我是即时进行的。对我来说，关键是将这个数据库分为3个微服务是合乎逻辑的： UserService-用于在系统中添加用户；最终应该管理[users]表；和 ProductService-对系统中的产品进行填充；最终应该管理[products]表；和 OrderService-用于在系统中添加订单；最终应该管理[orders]和[products_x_orders]表 但是，所有这些表之间都具有外键关系。如果我们对它们进行非规范化并将其视为整体，它们将失去所有语义含义： [users] table ============= user_id user_first_name user_last_name user_email …
8
如何将gRPC定义的API引入网络浏览器
我们想为我们的gRPC-microservices构建一个Javascript / HTML gui。由于浏览器端不支持gRPC，因此我们考虑使用Web套接字连接到node.js服务器，该服务器通过grpc调用目标服务。我们很难找到一个完美的解决方案来做到这一点。特别是，由于我们使用gRPC流在微服务之间推送事件。似乎我们需要第二个RPC系统，仅用于在前端和node.js服务器之间进行通信。这似乎有很多开销，必须维护其他代码。 有没有人有做过这样的事情的经验或有解决办法的想法？
4
播种微服务数据库
给定服务A（CMS）来控制模型（产品，让我们假设它具有的唯一字段是id，标题，价格）以及服务B（运费）和服务C（电子邮件）必须显示给定模型的方法是什么在事件采购方法中跨这些服务同步给定的模型信息？我们假设产品目录很少更改（但确实会更改），并且有管理员可以非常频繁地访问货运和电子邮件数据（示例功能为：B：display titles of products the order contained和C：）display content of email about shipping that is going to be sent。每个服务都有自己的数据库。 解决方案1 发送事件内有关产品的所有必需信息-这意味着以下结构order_placed： { order_id: [guid], product: { id: [guid], title: 'Foo', price: 1000 } } 关于服务B和C的产品信息存储在表的productJSON属性orders中 这样，为了显示必要的信息，仅使用从事件中检索到的数据 问题：根据需要在B和C中提供哪些其他信息，事件中的数据量可能会增加。B和C可能不需要有关Product的相同信息，但是事件必须包含两者（除非我们将事件分成两个）。如果给定事件中不存在给定数据，则代码将无法使用它-如果我们将给给定产品添加颜色选项，则对于B和C中的现有订单，给定产品将是无色的，除非我们更新事件然后重新运行它们。 解决方案2 在事件内仅发送产品的GUID-这意味着以下结构order_placed： { order_id: [guid], product_id: [guid] } 在服务B和C上，产品信息存储在表的product_id属性orders中 必要时，服务B和C通过对A/product/[guid]端点执行API调用来检索产品信息 问题：这使得B和C始终依赖于A。如果产品模式在A上发生更改，则必须对依赖于它们的所有服务进行更改 解决方案3 仅在事件内发送产品的GUID-这表示order_placed的结构如下： { …
2
Docker实现中的微服务
我们正在使用Amazon fargate使用Docker容器编写第一个微服务。我们对使用Spring Boot的实现水平有很多疑问 我们将在项目中拥有多个微服务，这是一种好的做法，我们将所有微服务都写在一个容器中，还是我必须为单独的微服务创建单独的Docker容器。我们以节省成本的方式使用单个容器，但是这将来会对我们的项目结构造成任何问题吗？ 我们正计划在AWS fargate中部署该应用程序，并且我们的应用程序将具有很大的扩展空间，可以在将来扩展，并有望提供约100至150种不同的微服务。在这种情况下，如果我们也将所有这些微服务也上传到不同的容器中，是否具有成本效益？
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.