服务应用独立式架构系统
技术领域
本发明涉及通信数据处理领域，尤其涉及一种服务应用独立式架构系统。
背景技术
随着互联网行业的迅猛发展，企业业务不断扩张，企业所提供的线上服务应用种类也越来越多。
现有技术中，企业线上提供服务应用采用的是单块架构，多个应用程序之间高度耦合，但是，随着应用程序所需的功能越来越多以及用户增多后的并发请求数量也越来越多，单块架构面临着诸多挑战，例如维护成本增加(应用程序功能的增多，工作团队的扩大，沟通成本、管理成本、人员协调成本必然显著提升)、交付周期长(应用程序功能的增多，代码逐渐复杂，构建和部署时间也会相应增加)、技术选型成本高(采用统一的技术平台或方案来解决所有问题，每个团队成员都必须使用相同的开发语言、持久化存储机制以及消息系统，使用类似的工具，随着应用程序复杂性的增加，引入新的框架、技术，或者对现有技术栈的升级，都将会面临应用程序稳定性风险)。
发明内容
发明目的：本发明旨在提供一种服务应用独立式架构系统。
技术方案：本发明实施例中提供的一种服务应用独立式架构系统，包括：客户端、网关单元、服务应用发现单元、多个服务应用提供单元，其中：
所述客户端，依据接收的调用指令，向预先从所述应用发现单元缓存的服务应用列表中查询对应的服务应用并获得通信接口，通过网关请求对应的服务应用提供单元进行程序调用；
服务应用提供单元，根据客户端的有效请求为客户端调用程序提供服务应用；多个服务应用提供单元内存储的程序之间相互独立；多个服务应用提供单元提供的服务应用预先注册于所述服务应用发现单元；
所述网关单元，接收客户端的请求，保留有调用权限的客户端的请求通过。
具体的，所述网关单元，至少具有以下一种功能：防止恶意代码入侵、流量监控、通信安全防护、验证客户端请求中的用户注册信息。
具体的，所述网关单元，是Zuul网关，包括反馈模块，其作用是将客户端请求的处理结果反馈至客户端。
具体的，所述服务应用发现单元，包括多个采用Eureka的服务应用列表模块，每个服务应用列表模块均存储有服务应用列表，相互之间定期同步。
具体的，还包括：服务管理单元，预存服务应用提供单元的通信接口并定期更新；所述客户端查询得到对应服务应用后，向所述服务管理单元获取对应的通信接口。
具体的，所述客户端，包括基于Netflix Ribbon的负载均衡工具，用于依据服务应用提供单元的各个服务器的负载情况，采用轮询方式将客户端的请求转送至有负载空间的服务器。
具体的，所述负载均衡工具中包括基于Hystrix的服务熔断组件，还用于服务应用提供单元调用程序失败的次数达到预设次数，停止与所述服务应用提供单元的通信连接，并返回调用失败至客户端。
具体的，服务应用提供单元，调用程序后缓存得到的缓存数据供多个服务应用提供单元查询，若查询未命中，则向数据库进行查询。
具体的，还包括中间消息单元，包括消息发送方和消息接收方，所述消息发送方接收操作指令后，向所述消息接收方发送事务消息；所述消息接收方基于接收的事务消息向所述消息发送方反馈接收成功，消息发送方基于接收成功的反馈对数据库进行Crud操作，若操作成功，则向消息接收方发送操作成功的消息，而消息接收方则向缓存数据投放事务消息。
具体的，所述网关单元，在验证通过客户端请求的用户注册信息后，生成具有时效性的验证通过数据并反馈至客户端；所述客户端，再次发送的服务应用调用请求包括所述验证通过数据。
有益效果：与现有技术相比，本发明具有如下显著优点：服务应用相互独立，降低维护成本、缩短交付周期、便于应用程序、服务应用系统引入新的框架、技术，或者对现有的技术栈进行升级。
附图说明
图1为本发明实施例中提供的服务应用独立式架构系统的工作流程示意图。
具体实施方式
下面结合附图对本发明的技术方案作进一步说明。
参阅图1，其为本发明实施例中提供的服务应用独立式架构系统的示意图。
本发明实施例中提供的一种服务应用独立式架构系统，包括：客户端、网关单元、服务应用发现单元、多个服务应用提供单元，其中：
所述客户端，根据接收的调用指令，向预先从所述应用发现单元缓存的服务应用列表中查询对应的服务应用并获得通信接口，通过网关请求对应的服务应用提供单元进行程序调用；
服务应用提供单元，根据客户端的有效请求为客户端调用程序提供服务应用；多个服务应用提供单元内存储的程序之间相互独立；多个服务应用提供单元所提供的服务应用预先注册于所述服务应用发现单元；
所述网关单元，接收客户端的请求，保留有调用权限的客户端的请求通过。
在具体实施中，服务应用提供单元(对应微服务A、微服务B和微服务C)所提供的服务应用均预先存于服务应用发现单元(对应注册中心)，客户端可以通过查询注册信息(缓存服务应用列表)获得详细的服务应用列表，以此来确定可以调用的服务应用。
在具体实施例中，服务应用提供单元内用于提供服务的应用程序是相互独立的，由此开发者可以专注于一项服务应用的开发，将整体系统的耦合程度降低。在开发过程中，开发人员只需要对外披露访问接口的地址即可，即客户端通过通信接口与服务应用提供单元取得连接并调用服务应用，根据客户端所需调用的服务应用种类，判断该客户端是否有权限调用该服务应用，保留有调用权限的客户端的请求通过。
本发明实施例中，所述网关单元，至少具有以下一种功能：防止恶意代码入侵、流量监控、通信安全防护、验证客户端请求中的用户注册信息。
本发明实施例中，所述网关单元，是Zuul网关，包括反馈模块，还用于将客户端请求的处理结果反馈至客户端。
在具体实施中，单元网关提供所有服务应用的请求、通信请求的统一入口，具备安全防护，防止恶意代码入侵，流量监控，限流，降级和熔断等功能。在验证客户端请求用户注册信息的过程中，用户输入的信息数据可以在缓存或者数据库中进行查询，返回给用户具体的成功或者失败的响应结果(包括验证结果以及调用权限结果等)。
本发明实施例中，所述服务应用发现单元，包括多个采用Eureka的服务应用列表模块，每个服务应用列表模块均存储有服务应用列表，相互之间定期同步。
在具体实施中，为了避免由于单个服务应用列表模块因故障等原因导致客户端无法获取服务应用列表或者无法获取最新的服务应用列表的问题，设置多个服务应用列表。
本发明实施例中，服务管理单元，预存服务应用提供单元的通信接口并定期更新；所述客户端查询到对应的服务应用后，向所述服务管理单元获得对应的通信接口。
在具体实施中，如果服务应用提供单元的通信接口(api)地址或端口发生了更改，并且客户端的通信接口地址和端口等信息是写在配置文件中的，那么需要通知客户端进行修改或者重新编译部署。为了避免上述技术负累，可以增加服务管理单元，即客户端从服务管理单元获取通信接口的信息。由于通信接口具有唯一标识，通信接口发生变更时要通知服务管理单元，服务管理单元通知相关的客户端，或者客户端定时从服务管理单元获取最新的通信接口，因此整个服务应用发现机制具有很高的稳定性、可靠性。
本发明实施例中，所述客户端，包括基于Netflix Ribbon的负载均衡工具，主要用于依据服务应用提供单元中各个服务器的负载情况，采用轮询方式将客户端的请求转送至有负载空间的服务器。
在具体实施中，负载均衡是对系统的高可用，网络压力的环节和处理能力扩容的重要手段。在高并发的请求中，大量用户同时点击某个服务应用请求按钮，导致短时间内网络带宽急剧增加，服务器负载过重，这时为了避免服务器负载过重导致崩溃的问题，需要把这些请求进行引流，分发至不同的服务器上，采用轮询方式将客户端的请求转送至有负载空间处理请求的服务器，可以很大程度上提升系统的响应速度，缓解负载压力。
本发明实施例中，所述负载均衡工具中包括基于Hystrix的服务熔断组件，用于服务应用提供单元调用程序失败的次数达到预设次数，停止与所述服务应用提供单元的通信连接，并返回调用失败至客户端。
本发明实施例中，服务应用提供单元，调用程序后缓存得到的缓存数据供多个服务应用提供单元查询，若查询未命中，则向数据库进行查询。
在具体实施中，服务应用提供单元之间相互独立，但是对于整体的架构，每个单元之间存在着相互配合，相互协作。例如，用户登录或者注册账户服务后，对于其他服务应用程序，在用户登录或者注册完成之后，都需要用户的个人信息，由此导致服务应用程序之间呈现低耦合，高内聚的特点。因此，引入缓存设计，将数据库进行解耦合，降低系统架构的复杂程度。系统采用在服务访问与数据库之间加入缓存设计的思想，可以提高数据的读取性能。在访问调用时，首先在缓存中进行查询，若查询未命中，再向数据库进行查询。
本发明实施例中，具体的，还包括中间消息单元，包括消息发送方和消息接收方，所述消息发送方收到操作指令后，向所述消息接收方发送事务消息；所述消息接收方基于接收到的事务消息向所述消息发送方反馈接收成功，消息发送方基于接收成功的反馈对数据库进行Crud操作，若操作成功，则向消息接收方发送操作成功的消息，而消息接收方则向缓存数据投放事务消息。
在具体实施中，中间消息单元包括消息发送方和消息接收方，Crud是指SQL语句的4类操作，C＝Create，R＝Retrieve，U＝Update，D＝Delete。若消息发送方基于接收成功的反馈对数据库进行的Crud操作没有成功，则向消息接收方发送操作失败的消息，消息接收方删除事务消息，并且不会向缓存数据投放事务消息。
在具体实施中，消息接收方向缓存数据投放事务消息后，各个服务应用提供单元在缓存数据中可以查询到。
在具体实施中，仅将操作成功的事务消息投放给服务应用提供单元进行查询，避免了过多无效的消息侵占查询时间和计算空间。
本发明实施例中，所述网关单元，在验证通过客户端请求的用户注册信息后，生成具有时效性的验证通过数据并反馈至客户端；所述客户端，再次发送的服务应用调用请求包括所述验证通过数据。
在具体实施中，客户端在通过验证后，再次请求调用服务应用时，在验证通过数据的有效时间内，可以免去向服务应用提供单元进行用户注册信息验证，提高交互效率。
