4.  若存在可用的内核扩展，微内核将会应用负载均衡策略，选择最合适的内核扩展
用于处理请求。
5.  若存在对应的内核监视器，则调用内核监视器的相应拦截方法，传入请求对象。
6.  微内核调用选定的内核扩展的处理逻辑以处理请求。    
7.  若请求处理过程中未发生异常，则按顺序执行如下操作：
7.1. 若存在相应的内核监视器，则调用内核监视器的相应拦截方法，传入请求对象
和响应对象。
7.2. 若存在相应的处理器，则调用处理器的处理方法，传入请求对象和响应对象。
7.3. 将响应对象返回给请求发起方。
8.  若请求处理过程中产生异常，则按顺序执行如下操作：
8.1. 若存在相应的内核监视器，则调用内核监视器的相应拦截方法，传入异常对象。  
8.2. 若存在相应的处理器，则调用处理器的处理方法，传入请求对象和异常对象。
8.3. 将异常重新封装后再次抛出，异常会被请求发起方捕获。
4.2.1.2.5. 销毁内核扩展
系统在关闭时会通知内核销毁所有内核扩展。销毁内核扩展时，内核会调用每一
个已注册的内核扩展的销毁方法，以允许内核扩展完成销毁操作。
4.2.1.3.  服务总线
内核是体现开放式的第一个层次。微内核管理了宿主和内核扩展的契约，也同时
实现了一个简单的服务总线，所有内核扩展均可视为微内核上的服务。微内核发现并
装配内核扩展，通过内核扩展的元数据识别内核扩展，在一个相对较高的层次管理了
内核扩展之间的通信。内核扩展之间的交互会通过微内核的中介来进行，借助微内核
中的服务总线，各个内核扩展可以获得一致的、可靠的交互界面。而由于上层模块只
与微内核进行交互，因此也可以很好地支持基于微内核的服务的封装、重用和服务组
合。内核级别的服务总线如图 4-6所示。
 
图4-6：服务总线      
4.2.1.4.  内核级分布式
在实际应用场景中，各个内核扩展之间的负载不尽相同，而系统本身并未限制具
体内核扩展的实现模式，因此对于成为瓶颈的内核扩展，可以应用分布式策略来提升
负载能力。内核扩展可以通过RMI或者RPC 方式来调用远程方法，在远程构建独立的
分布式系统以调度并响应请求，并由远程的分布式系统实现负载均衡。同时，系统支
持同一个消息类型可以被多个内核扩展所处理，因此也可以通过服务冗余的方式将分
布在远程的业务处理模块挂载至微内核，并通过内核中内建的负载均衡机制实现请求
调度。内核级分布式如图 4-7所示。
 
图4-7：内核级分布式
4.2.1.5.  内核级负载均衡
如前文所述，微内核中已经构建了服务总线，因此可以很容易地通过服务总线实
现内核级别的负载均衡。服务总线可以将所有从上层传入的调用请求放入请求队列
中，并根据各个内核扩展间的不同负载状况决定响应顺序。一个可以考虑的负载均衡
策略是，仅根据内核扩展在过去一段时间内的请求处理数量来选择负载较低的内核扩
展以响应请求。内核级负载均衡如图 4-8所示。
图 4-8：内核级负载均衡
4.2.1.6.  可扩展性
内核级别的扩展主要集中在添加新的内核扩展、添加新的内核监视器以及添加新
的内核契约。
若要添加新的内核契约，只需要向内核契约模块中添加新的请求——响应报文
对，并向内核声明新的内核契约。在添加了内核契约后，上层模块和内核扩展即可发 面向服务的开放式平台架构(7):http://www.youerw.com/jisuanji/lunwen_3091.html