如何在微服务/事件驱动架构中处理HTTP请求? [英] How to handle HTTP requests in a Microservice / Event Driven Architecture?

问题描述

背景:

我正在构建一个应用程序，并且所建议的体系结构是基于微服务体系结构的事件/消息驱动.

I am building an application and the proposed architecture is Event/Message Driven on a microservice architecture.

整体的处理方式是我有一个User/HTTP request，并且该命令会操作某些具有直接synchronous response的命令.因此，响应同一用户/HTTP请求是无麻烦的".

The monolithic way of doing thing is that I've a User/HTTP request and that actions some commands that have a direct synchronous response. Thus, to respond to the same User/HTTP request is 'hassle free'.

问题:

用户将HTTP request发送到 UI服务(有多个UI服务)，从而将一些事件触发到队列(Kafka/RabbitMQ/any). N个服务选择事件/消息在此过程中发挥了神奇作用，然后然后在某个时刻，同一UI Service应该选择一个响应并将其返回给发起HTTP请求的用户.根据典型的HTTP交互，请求处理为ASYNC，但User/HTTP REQUEST->RESPONSE为SYNC.

The user sends an HTTP request to the UI Service (there are multiple UI Services) that fires some events to a queue (Kafka/RabbitMQ/any). a N of services picks up that Event/Message do some magic along the way and then at some point that same UI Service should pick that up a response and give that back to the user that originated HTTP request. Request processing is ASYNC but the User/HTTP REQUEST->RESPONSE is SYNC as per your typical HTTP interaction.

问题: 在这个不可知论/事件驱动的世界中，我如何向发起该操作的同一UI服务(该服务通过HTTP与用户进行交互)发送响应?

Question: How do I send a response to the same UI Service that originated the action (The service thats interacting with the user over HTTP) in this Agnostic/Event driven world?

到目前为止我的研究 我一直在环顾四周，似乎有些人正在使用WebSockets解决该问题.

My research so far I've been looking around and it seems that some people are solving that problem using WebSockets.

但是，复杂性在于，需要有一些映射(RequestId->Websocket(Client-Server))的表，该表用于发现"网关中的哪个节点具有用于特定响应的websocket连接.但是，即使我理解了问题和复杂性，我仍然陷于困境，因为找不到任何文章可以在实现层为我提供有关如何解决此问题的信息. 并且这仍然不是一个可行的选择，因为第三方集成，例如期望REQUEST->RESPONSE的付款提供商(WorldPay)-特别是在3DS验证上.

But the layer of complexity is that there needs to be some table that maps (RequestId->Websocket(Client-Server)) which is used to ‘discover’ which node in the gateway has the websocket connection for some particular response. But even if I understand the problem and complexity I'm stuck that I can't find any articles that would give me info on how to solve this problem at the implementation layer. AND this still is not a viable option because of 3rd party integrations such as payments providers(WorldPay) that expect REQUEST->RESPONSE - specially on the 3DS validation.

所以我有点不愿意认为WebSockets是一个选择.但是，即使WebSocket适用于Web界面应用程序，但用于连接到外部系统的API也不是一个好的体系结构.

So I am somehow reluctant to think that WebSockets is an option. But even if WebSockets are ok for Webfacing apps, for API that connects to external systems is not a great architecture.

** ** ** 更新: ** **

** ** ** Update: ** ** **

即使对于具有202 Accepted，Location header和retry-after header的WebService API来说，长轮询也是可能的解决方案，但对于高并发性和性能而言，这将不起作用.高能力的网站. 想象一下，有很多人试图在他们发出的每个请求中获取交易状态更新，而您必须使CDN缓存无效(现在就去解决这个问题！哈).

Even if long polling is an possible solution for a WebService API with a 202 Accepted a Location header and a retry-after header it wouldn't be performant for a high concurrency & high ability website. Imagine a huge number of people trying to get the transaction status update on EVERY request they make and you have to invalidate CDN cache (go and play with that problem now! ha).

但最重要且与我的情况相关的是我有第三方API(例如付款系统)，其中3DS系统具有由付款提供商系统处理的自动重定向，并且他们希望使用典型的REQUEST/RESPONSE flow，因此该模型不会为我工作，套接字模型也不会工作.

But most important and relatable to my case I've 3rd party APIs such as payment systems where the 3DS systems have automatic redirects that are handled by the payment provider system and they expect a typical REQUEST/RESPONSE flow, thus this model would not work for me nor the sockets model would work.

由于这种用例，HTTP REQUEST/RESPONSE应该以一种典型的方式处理，我有一个笨拙的客户端，期望在后台处理进餐的复杂性.

Because of this use-case the HTTP REQUEST/RESPONSE should be handled in the typical fashion where i have a dumb client that expect that the complexity of the precessing is handled in back-end.

所以我正在寻找一种解决方案，在外部我有一个典型的Request->Response(SYNC)并且状态(系统的ASYNCrony)的复杂性是在内部处理的

So i am looking for a solution where externally I have a typical Request->Response(SYNC) and the complexity of the status(ASYNCrony of the system) is handled internally

长时间轮询的示例，但该模型不适用于不在我控制范围内的第三方API，例如3DS Redirects上的付款提供商.

An example of the long polling, but this model wouldn't work for 3rd party API such as payments provider on 3DS Redirects that are not within my control.

 POST /user
    Payload {userdata}
    RETURNs: 
        HTTP/1.1 202 Accepted
        Content-Type: application/json; charset=utf-8
        Date: Mon, 27 Nov 2018 17:25:55 GMT
        Location: https://mydomain/user/transaction/status/:transaction_id
        Retry-After: 10

GET 
   https://mydomain/user/transaction/status/:transaction_id

推荐答案

正如我所期望的那样-人们尝试将所有内容都放入一个概念中，即使它不适合该概念.这不是批评，这是我的经验以及阅读您的问题和其他答案后的观察结果.

As I was expecting - people try to fit everything into a concept even if it does not fit there. This is not a criticism, this is an observation from my experience and after reading your question and other answers.

是的，微服务架构基于异步消息传递模式是正确的.但是，当我们谈论UI时，我想到了两种可能的情况:

Yes, you are right that microservices architecture is based on asynchronous messaging patterns. However, when we talk about UI, there are 2 possible cases in my mind:

1. UI立即需要响应(例如，读取操作或用户希望其立即响应的命令). 这些不必是异步的.如果立即在屏幕上需要响应，为什么还要增加消息传递和异步的开销?没有道理.微服务体系结构应该解决问题，而不是通过增加开销来创建新问题.

1. UI needs a response immediately (e.g. read operations or those commands on which user expects answer right away). These don't have to be asynchronous. Why would you add an overhead of messaging and asynchrony if the response is required on the screen right away? Does not make sense. Microservice architecture is supposed to solve problems rather than create new ones by adding an overhead.

UI可以进行重组以容忍延迟的响应(例如，UI无需等待结果，而可以仅提交命令，接收确认，并在准备响应时让用户执行其他操作).在这种情况下，您可以引入异步. gateway 服务(与UI直接交互的服务)可以协调异步处理(等待完整的事件等)，并且准备就绪后，可以与UI进行通信.在这种情况下，我已经看到UI使用SignalR，并且网关服务是一个接受套接字连接的API.如果浏览器不支持套接字，则理想情况下应回退到轮询.无论如何，重要的一点是，这只能在偶然情况下起作用: UI可以容忍延迟的答案.

UI can be restructured to tolerate delayed response (e.g. instead of waiting for the result, UI can just submit command, receive acknowledgement, and let the user do something else while response is being prepared). In this case, you can introduce asynchrony. The gateway service (with which UI interacts directly) can orchestrate the asynchronous processing (waits for complete events and so on), and when ready, it can communicate back to the UI. I have seen UI using SignalR in such cases, and the gateway service was an API which accepted socket connections. If the browser does not support sockets, it should fallback to the polling ideally. Anyway, important point is, this can only work with a contingency: UI can tolerate delayed answers.

如果微服务确实与您的情况相关(案例2)，则相应地构建UI流程，并且后端微服务应该没有挑战.在这种情况下，您的问题归结为将事件驱动的体系结构应用于服务集(边缘是连接事件驱动和UI交互的网关微服务).这个问题(事件驱动的服务)可以解决，您知道这一点.您只需要确定是否可以重新考虑UI的工作原理即可.

If Microservices are indeed relevant in your situation (case 2), then structure UI flow accordingly, and there should not be a challenge in microservices on the back-end. In that case, your question comes down to applying event-driven architecture to the set of services (edge being the gateway microservice which connects the event-driven and UI interactions). This problem (event driven services) is solvable and you know that. You just need to decide if you can rethink how your UI works.

这篇关于如何在微服务/事件驱动架构中处理HTTP请求?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！