面向服务的模块化系统体系架构技术方案

本发明专利技术公开一种面向服务的模块化系统体系架构,包括插件和应用程序编程接口枢纽；所述插件将服务器应用中的不同功能抽象成了一个个可插拔的业务模块，通过在所述应用程序编程接口枢纽上注册应用程序编程接口分发器，所述插件中某个的业务模块动态地将当前能够提供的服务以应用程序编程接口的形式暴露给所述插件中其它的业务模块。本发明专利技术将服务器应用中的不同功能独立抽象成了一个个可插拔的业务模块，将不同功能各自封装和隔离为服务的隔离效果，且允许不同业务模块间相互暴露接口给对方使用。

【技术实现步骤摘要】

本专利技术涉及分布式服务器集群系统领域，尤其涉及一种面向服务的模块化系统体系架构。
技术介绍
长久以来，服务器端的高层架构大体被区分为对立的两类：SOA(Service-oriented architecture)以及AIO(All in one)。SOA将一个完整的应用分割为相互独立的服务，每个服务提供一个单一标准功能(如：会话管理、交易评价、用户积分等等)。服务间通过RPC、WebAPI等IPC机制暴露功能接口，并以此相互通信，最终组合成一个完整的应用。而AIO则相反，它将一个应用规约在一个独立的整体中，SOA中的不同服务在AIO架构下呈现为不同的功能组件和模块。AIO应用的所有组件通常都运行在一个地址空间(同一进程)内，所有组件的代码也常常放在同一个产品项目中一起维护。AIO的优势是部署简单，不需要分别部署多个服务，并为每个服务实现一套高可用集群。与此同时，由于可避免网络传输、内存拷贝等IPC通信所带来的大量开销，因此AIO架构的单点效率通常远高于SOA。另一方面，由于AIO架构中组件依赖性强，组件间经常知晓并相互依赖对方的实现细节，因此组件的可重用性及可替换性差，维护和扩展也较困难。特别是对于刚加入团队的新人来说，面对包含了大量互相深度耦合之组件和模块的“巨型项目”，常常需要花费大量努力、经历很多挫折并且犯很多错误才能真正接手。而即使对于老手来说，由于模块间各自对对方实现细节错综复杂的依赖关系，也容易发生在修改了一个模块的功能后，莫名奇妙地影响到其它看起来毫不相干功能的情况。与此相反，SOA模型部署和配置复杂——现实中，一个大型应用常常被拆分为数百个相互独立的服务，《程序员》期刊中的一份公开发表的论文显示，某个国内“彻底拥抱”SOA的著名(中国排名前5)电商网站将他们的Web应用拆分成了一千多个服务。可以想象，在多活数据中心的高可用环境内部署成百上千个服务器集群，并且配置他们彼此间的协作关系是多大的工作量。最近的程程(ctrip.com)网络瘫痪事件也是因为上千台服务组成的庞大SOA架构导致故障恢复缓慢。除了部署复杂以外，SOA的另一个主要缺点就是低效——从逻辑流的角度看，几乎每次来自客户端的完整请求都需要依次流经多个服务后，才能产生最终结果并返回用户端。而请求(通过消息中间件)每“流经”一个服务都需要伴随多次网络IO和磁盘访问，多个请求可累计产生较高的网络时延，使用户请求的响应时间变得不可确定，用户体验变差，并额外消耗大量资源。此外，无论是每个Service各自连接不同的DBMS还是它们分别接入同一个后端分布式DBMS系统，实现跨服务的分布式事务支持工作都要落到应用层开发者手中。而分布式事务(XA)本身的实现复杂度恐怕就已超过大部分普通应用了，更何况还需要为分布式事务加上高可靠和高可用保证——需要在单个数据切片上使用Paxos/Raft或主从+Arbiter之类的高可用、强一致性算法，同时在涉及多个数据切片的事务上使用2PC/3PC等算法来保证事务的原子性。因此SOA应用中的跨Service事务基本都只能退而求其次，做到最终一致性保证，即便如此，也需要增加大量的额外工作——在稍微复杂点的系统里，高可用，并能在指定时间内可靠收敛的最终一致性算法实现起来也不是那么容易。与此同时，大部分SOA系统经常需要使用消息中间件来实现消息分发服务。如果对消息中间件的可用性(部分节点故障不会影响正常使用)、可靠性(即使在部分节点故障时，也确保消息不丢失、不重复、并严格有序)、功能性(如：发布/订阅模型、基于轮转的任务分发等)等方面有所要求的话，那么消息中间件本身也容易成为系统的瓶颈。
技术实现思路
本专利技术的目的是：为了解决上述问题，提供了一种面向服务的模块化系统体系架构，独立运行的服务被替换成了支持动态插拔的跨平台功能插件(IPlugin)；而插件则通过(并仅可通过)应用程序编程接口枢纽(API Nexus)来动态地暴露(注册)和隐藏(注销)自身所提供的功能接口，同时也使用API Nexus来消费其它插件提供服务。为了实现上述目的，本专利技术的技术方案是：一种面向服务的模块化系统体系架构,包括插件和应用程序编程接口枢纽；所述插件将服务器应用中的不同功能抽象成了一个个可插拔的业务模块(BMOD，通常每个业务模块对应一个插件)，通过在所述应用程序编程接口枢纽(API Nexus)上注册应用程序编程接口分发器(API Dispacher)，所述插件中的业务模块动态地将当前能够提供的服务以应用程序编程接口(API)的形式暴露给当前系统以及其下的其它业务模块或其它插件。进一步的，所述应用程序编程接口动态的注册和注销机制匹配所述插件接口的动态插拔能力。进一步的，每个所述插件均可携带任意复杂度的的配置信息，它们被分割为常规配置部分、高级配置部分和内部配置部分，且每个部分的内容可分别由所述插件类别或具体实现自行定义。进一步的，每个所述插件均可携带两个包含任意资源的虚拟文件系统(VFS),它们分别为：用于对外服务的资源虚卷，以及对内自用的私有虚卷。进一步的，所述应用程序编程接口枢纽包括分发器注册单元、分发器注销单元、发起应用程序编程接口调用请求单元、提交应用程序编程接口调用请求单元以及应用程序编程接口分发器匹配单元。本专利技术完全继承了SOA架构高内聚、低耦合的优点，每个插件如独立的服务一样，有清晰的接口和边界，可容易地被替换和重用。在可维护性上，μSOA也与SOA完全一致，每个插件都可以被单独地开发和维护，开发人员只需要管好自己维护的功能插件即可。通过加入新插件以及对现有功能插件的重新组合，甚至可比SOA模式更容易地对现有功能进行变更和扩展。而在性能方面，由于所有功能插件都运行在同一个进程内，因此通过API Nexus的相互调用不需要任何网络IO、磁盘访问和内存拷贝，也没有任何形式的其它IPC开销，因此其性能和效率均可与AIO架构保持在相同量级。与此同时，μSOA的部署与AIO同样简单——部署在单个节点即可使用，只需部署一个集群即可实现高可用和横向扩展。在配置方面也远比SOA简单，仅需要比AIO应用多配置一个待加载模块列表而已，并且这些配置也可通过各种配置管理产品来实现批量维护。简单的部署和配置过程不但简化了运营和维护工作，也大大方便了开发和测试环境的构建。此外，μSOA也在极大程度上避免了对消息中间件的依赖，取而代之的是通过API Nexus的直接API调用；或是在需要削峰填谷的场合中，使用由内存零拷贝和无锁算法高度优化的线程间消息队列。这一方面大大增加了吞吐，避免了延迟，另一方面也避免了部署和维护一个高可用的消息分发服务集群所带来的巨大工作量——μSOA集群内的节点间协作和协调通信需求已被将至最低，对消息分发的可靠性、可用性和功能性都没有太高要求。在多数情况下，使用Gossip Protocol等去中心化的P2P协议即足以满足需要，有时甚至可以完全避免这种集群内的节点间通信。附图说明图1是本专利技术实施例一示意图。图2是本专利技术实施例二示意图。具体实施方式以下结合附图进一步说明本专利技术的实施例。为了使本专利技术的目的、技术方案和优点更加清楚明白，下面结合功能图和流程图，对本专利技术做进一步详细说明。以下的示意性实施方式及其说明用于本文档来自技高网...

【技术保护点】
一种面向服务的模块化系统体系架构,其特征在于:包括插件和应用程序编程接口枢纽；所述插件将服务器应用中的不同功能抽象成了一个个可插拔的业务模块，通过在所述应用程序编程接口枢纽上注册应用程序编程接口分发器，所述插件中某个的业务模块动态地将当前能够提供的服务以应用程序编程接口的形式暴露给所述插件所在应用程序中的其它业务模块或其它插件。

【技术特征摘要】
1.一种面向服务的模块化系统体系架构,其特征在于:包括插件和应用程序编程接口枢纽；所述插件将服务器应用中的不同功能抽象成了一个个可插拔的业务模块，通过在所述应用程序编程接口枢纽上注册应用程序编程接口分发器，所述插件中某个的业务模块动态地将当前能够提供的服务以应用程序编程接口的形式暴露给所述插件所在应用程序中的其它业务模块或其它插件。2.根据权利要求1所述的面向服务的模块化系统体系架构,其特征在于:所述应用程序编程接口动态的注册和注销机制匹配所述插件接口的动态插拔能力。3.根据权利要求1所述的面向服务的模块化...

【专利技术属性】
技术研发人员：白杨，
申请(专利权)人：白杨，
类型：发明
国别省市：上海;31