[发明专利]基于微服务架构的交易请求处理系统和方法

说明书

本发明涉及基于微服务架构的交易请求处理系统和方法，包括：负载服务器，用于判断下游机构发送的交易请求是正交易请求还是反交易请求，若是正交易请求则将正交易请求发送至任一甬道，若是反交易请求则将反交易请求发送至后置服务器；以及将甬道或后置服务器处理后的交易请求发送至上游机构；若干甬道，用于处理负载服务器发送的正交易请求，并将正交易请求中携带的业务请求发送至后置服务器进行处理；以及处理后置服务器发送的反交易请求，该反交易请求中未携带业务请求；后置服务器，用于处理甬道发送的正交易请求中携带的业务请求；以及处理负载服务器发送的反交易请求中携带的业务请求，并将反交易请求发送至任一甬道进行处理。

技术领域

本发明涉及交易请求处理技术领域，特别涉及一种基于微服务架构的交易请求处理系统和方法。

背景技术

目前交易系统采用的是微服务架构，每个服务采用集群模式。微服务将整个交易系统划分为多个微小、独立的服务，各服务之间相互调用、相互配合，完成整个交易流程。请参见图4，所有的服务共用一个数据库，请求会先到达负载服务器，由负载服务器选择一个服务实例处理请求。请求进入交易系统后，交易系统会处理校验参数、请求上游、风控检查、计费、分账等业务，处理结束后向下游返回结果。同时请求不区分类型，所有的请求都会进入到交易系统。

目前基于微服务架构的交易系统在一定程度上保证了数据一致性和可用性，但是依然存在以下问题：

①交易是一种比较特殊的业务场景，它对请求/响应时效要求非常高，现有设计中存在较多时间在处理非重要性事务，导致整体上延长了处理请求的时间；

②多个服务共用一个数据，在高并发的情况下，可能会导致数据库不可用，进而造成系统无法提供服务；

③交易系统包含了正交易和反交易两种，现有技术中不区分，所有的请求都会进入交易系统，可能会导致因为处理反交易而拖累正交易的问题，无法很好保证正交易的可靠性；

④每个服务都是集群的，多模块之间会相互调用，但调用关系混乱；

⑤整个交易流程在一个系统中，修改其中某个功能时，需要将所有代码重新部署、投产，浪费资源。

发明内容

本发明的目的在于基于微服务架构的基础上，采取业务分离的方式，对交易请求处理要求的时效性高，并且解决了数据高并发的场景问题，提供一种基于微服务架构的交易请求处理系统和方法，将交易请求中的正交易请求、反交易请求、业务请求分离处理。

为了实现上述发明目的，本发明实施例提供了以下技术方案：

基于微服务架构的交易请求处理系统，包括：

负载服务器，用于判断下游机构发送的交易请求是正交易请求还是反交易请求，若是正交易请求则将正交易请求发送至任一甬道，若是反交易请求则将反交易请求发送至后置服务器；以及将甬道或后置服务器处理后的交易请求发送至上游机构；

若干甬道，各甬道相互独立，用于处理负载服务器发送的正交易请求，并将正交易请求中携带的业务请求发送至后置服务器进行处理；以及处理后置服务器发送的反交易请求，该反交易请求中未携带业务请求；

后置服务器，用于处理甬道发送的正交易请求中携带的业务请求；以及处理负载服务器发送的反交易请求中携带的业务请求，并将反交易请求发送至任一甬道进行处理。

所述负载服务器包括判断接口，所述判断接口用于判断下游机构发送的交易请求是正交易请求还是反交易请求。

每个所述甬道包括交易系统、交易通道，其中，

所述交易系统用于判断接收到的交易请求是负载服务器发送的正交易请求，还是后置服务器发送的反交易请求；如果是负载服务器发送的正交易请求，则将正交易请求发送至交易通道进行处理，并将正交易请求中携带的业务请求发送至后置服务器；如果是后置服务器发送的反交易请求，则将该反交易请求发送至交易通道进行处理，该反交易请求中未携带业务请求；

所述交易通道用于处理交易系统发送的正交易请求或反交易请求。