Dubbo的微内核机制

时间 2019-11-07

标签 dubbo 内核机制栏目 Dubbo 繁體版

原文原文链接

做者：刘昊旻 / 伯昊 / ludvik / haomin_liu(at)hotmail.comhtml

摘要

最近一直在思考蜂鸟物流系统中台化可否引入微内核机制。做为思考做业，首先把dubbo的微内核设计进行了总结沉淀。但愿也对你们有用。java

本文借由Dubbo采用微内核设计的原因做为引子，简单地探讨了微内核架构（Microkernel Architecture）设计实践的思想。本文适合对Dubbo有必定使用经验、并对其实现原理感兴趣的同窗；也适合对微内核架构感兴趣、并但愿在本身的问题域中实践的同窗。web

Wikipedia上微内核（Microkernel）的定义

In computer science, a microkernel (also known as μ-kernel) is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system (OS). These mechanisms include low-level address space management, thread management, and inter-process communication (IPC). If the hardware provides multiple rings or CPU modes, the microkernel may be the only software executing at the most privileged level, which is generally referred to as supervisor or kernel mode. Traditional operating system functions, such as device drivers, protocol stacks and file systems, are typically removed from the microkernel itself and are instead run in user space. 数据库

wikipedia上的定义特指这是一种操做系统内核设计风格，其对标的内核设计风格是monolithic kernel。apache

本文提到的微内核

本文讲到的微内核架构（Microkernel architecture）更宽泛一些，不局限于操做系统内核设计问题域，是一种设计范型（design paradigm），更接近于《Software Architecture Patterns》一书中所写：bootstrap

The microkernel architecture pattern allows you to add additional application features as plug-ins to the core application, providing extensibility as well as feature separation and isolation. The microkernel architecture pattern consists of two types of architecture components: a core system and plug-in modules. Application logic is divided between independent plug-in modules and the basic core system, providing extensibility, flexibility, and isolation of application features and custom processing logic. 缓存

微内核架构由两大架构模块组成：核心系统与插件模块。设计一个微内核体系关键工做所有集中于核心系统怎么构建。ruby

全部的软件存在的目的都是为了去解决某个现实世界中具体领域的问题，简称问题域。好比dubbo的问题域是服务化与服务治理、maven的问题域是编译打包与软件项目管理。性能优化

若是某个问题域发现有以下特征，就能够考虑使用微内核设计思想：bash

问题域可以沉淀一层比较核心的概念、流程或功能，这些元素能够被稳定维护在一个核心之中；
- Maven将代码编译打包场景定义为三套生命周期：clean、default、site；其核心的default生命周期中20多个编译步骤将问题域进行了高度抽象；Maven的plugin（又名mojo）在定义时都须要将本身挂载到某个goal和step上；
- Dubbo将SOA调用高度抽象为20余个核心SPI，这些SPI又相似协议栈分层的设计细分为核心的七、8个层次（proxy、cluster、protocol等）；dubbo将本身主要的SOA服务调用功能实现都定义为这些SPI的具体扩展实现（plugin）；有了这些抽象的SPI，plugin也就有了依附的基础；
问题域有开放封闭的迫切需求，其中封闭的部分、可扩展部分分别由不一样的团队、工程来维护与组织。好比：
- Framework的实现封闭 vs. 依赖Framework的应用扩展开放，好比dubbo这样的中间件设计场景；
- 操做系统核心实现封闭 vs. 操做系统应用层开放，好比全部微内核操做系统设计场景；
- 平台级业务系统核心逻辑实现封闭 vs. 具体业务系统扩展开放，好比阿里中台核心平台系统的设计场景；

上面的两个问题域特征，恰好带出了在进行微内核架构核心系统设计时的两个关键点：

对问题域的核心概念、流程、功能的洞察与抽象；有了这些核心元素，plugin的扩展才能有所依附、与其代码之间的互动才能实际落地发生；
设计一套机制用于规范和管理plugin生命周期：定义、加载、销毁等；

Dubbo架构概要介绍

Dubbo主要解决了服务化架构中的几个关键问题：

远程调用（RPC）
- 解决远程的进程到进程的调用；
集群逻辑（cluster invoke cluster）
- 更进一步，解决服务集群到服务集群的调用问题，例如软负载机制；
服务发现与服务治理（Registry / Governance）
- 集中解决服务治理所须要的基础功能：服务的注册与发现、注册中内心的基础服务治理功能

采用了相似协议栈的分层设计，概括下来主要分为三层：

Service层（Service/Config/Proxy）
- 解决provider侧服务暴露 / consumer侧消费服务的问题
集群层（Registry / Cluster）
- 解决服务注册与发现、集群调用策略领域关键问题
RPC层（Protocol / Exchange/ Transport / Serialize）
- 解决点到点的同步远程调用领域的问题

这主要的三层符合分层架构风格的特征，即: 上层逻辑无需关注下层实现细节。 这个特征使得dubbo的扩展方能够采用相似搭积木的方式进行扩展。好比：完全更换RPC协议，而共享上层的集群调用与服务治理实现；更多的奥妙就不在此文展开，感兴趣的同窗能够仔细研究下图（摘自Dubbo官方文档），内涵与细节很是丰富：

Dubbo与微内核架构

Dubbo为何会使用微内核架构？最直观的缘由：为了推广方便

Dubbo在设计之初，正值Alibaba B2B进行服务化转型的关键时期。所要推广的应用系统要么还处于“恐龙级单体”应用状态；要么用“土办法”解决简单的集群间调用。

想要顺利推广，得具有这几个关键特征：

性能好
- 在一次服务调用中，框架所占用的资源和时间要缩小到对应用层基本能够忽略的程度；
鲁棒性好
- 各类设计细节都须要兜底和防呆，避免由于一些次要的缘由，致使整个应用系统崩溃（最经典的案例就是由于注册中心bug致使服务的提供者被所有剔除恶性事件了，其中各类心酸，具体的心得能够另开一篇文章专门探讨）；
引入的依赖少
- 最小化对业务代码的侵入：能够作到应用容器无关（不一样的web容器、homemade应用容器都不影响使用）、框架无关（不强依赖Spring）
可扩展性好（能作到开放封闭）
- 依赖于本身抽象的SPI以及plugin加载机制，能作到应用方很是自由地经过SPI方式插入本身想要的逻辑，而不须要修改Dubbo自己

最后这一项，就是Dubbo采用微内核设计的主要缘由： dubbo所要支持的应用系统千差万别，在一个组织中推行服务化，dubbo须要面临诸多的扩展需求，举几个场景：

场景一：
- 遗留系统是Python写的单体应用，想要用Java来进行领域拆分改造，有一些RPC调用的场景，老系统采用Rest + VIP的方式进行远程调用；
场景二：
- 用户想要实现本身的分布式调用跟踪，在这个基础之上创建本身的运维工具体系。
场景三：
- 但愿在SOA的调用链条上插入本身的filter逻辑，去实现调用审计的需求；

还有不少不一一列举。做为一个开源框架，尝试将全部上面的需求都不加区分的在框架内实现必定是不可取的，众口难调。

如何作到干好本身的活儿，又不挡用户的道儿呢？

答案不言自明。

Dubbo的扩展点实现举例

以扩展实现Filter SPI为例。

Filter SPI 定义：

package org.apache.dubbo.rpc;

import org.apache.dubbo.common.extension.SPI;

/** * Filter. (SPI, Singleton, ThreadSafe) */
@SPI
public interface Filter {

    /** * do invoke filter. * <p> * <code> * // before filter * Result result = invoker.invoke(invocation); * // after filter * return result; * </code> * * @param invoker service * @param invocation invocation. * @return invoke result. * @throws RpcException * @see org.apache.dubbo.rpc.Invoker#invoke(Invocation) */
    Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException;
}
复制代码

filter是链式组装的，要实现本身的filter逻辑，只须要实现下面的invoke接口便可。filter的组装须要注意官方文档中记录的约定：

用户自定义 filter 默认在内置 filter 以后。

特殊值 default，表示缺省扩展点插入的位置。好比：filter="xxx,default,yyy"，表示 xxx 在缺省 filter 以前，yyy 在缺省 filter 以后。
特殊符号 -，表示剔除。好比：filter="-foo1"，剔除添加缺省扩展点 foo1。好比：filter="-default"，剔除添加全部缺省扩展点。
provider 和 service 同时配置的 filter 时，累加全部 filter，而不是覆盖。好比：<dubbo:provider filter="xxx,yyy"/> 和 <dubbo:service filter="aaa,bbb" />，则 xxx,yyy,aaa,bbb 均会生效。若是要覆盖，需配置：<dubbo:service filter="-xxx,-yyy,aaa,bbb" />

扩展配置

<!-- 消费方调用过程拦截 -->
<dubbo:reference filter="xxx,yyy" />
<!-- 消费方调用过程缺省拦截器，将拦截全部reference -->
<dubbo:consumer filter="xxx,yyy"/>
<!-- 提供方调用过程拦截 -->
<dubbo:service filter="xxx,yyy" />
<!-- 提供方调用过程缺省拦截器，将拦截全部service -->
<dubbo:provider filter="xxx,yyy"/>
复制代码

XxxFilter.Java

package com.xxx;
 
import com.alibaba.dubbo.rpc.Filter;
import com.alibaba.dubbo.rpc.Invoker;
import com.alibaba.dubbo.rpc.Invocation;
import com.alibaba.dubbo.rpc.Result;
import com.alibaba.dubbo.rpc.RpcException;
 
public class XxxFilter implements Filter {
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        // before filter ...
        Result result = invoker.invoke(invocation);
        // after filter ...
        return result;
    }
}
复制代码

扩展实现Jar包Maven 项目结构：

src
 |-main
    |-java
        |-com
            |-xxx
                |-XxxFilter.java (实现Filter接口)
    |-resources
        |-META-INF
            |-dubbo
                |-com.alibaba.dubbo.rpc.Filter (纯文本文件，内容为：xxx=com.xxx.XxxFilter)
复制代码

META-INF/dubbo/com.alibaba.dubbo.rpc.Filter：

xxx=com.xxx.XxxFilter
复制代码

xxx就是com.xxx.XxxFilter全限定名的别名了，它会出如今dubbo的provider或者consumer的配置文件中，dubbo会按需加载组装。

按照这样的方式定义其余的扩展点，以此类推，运行时dubbo会把自带的、以及应用本身扩展的实现所有加载进来，以下图所示（假设该应用还扩展了LoadBalance以及Protocol另外两个扩展点）：

Dubbo扩展点加载机制实现

扩展点加载

截取自dubbo官方文档《开发者指南-扩展点加载》， Dubbo的扩展点加载由JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制增强而来，主要针对这三个缺点：

JDK 标准的 SPI 会一次性实例化扩展点全部实现，若是有扩展实现初始化很耗时，但若是没用上也加载，会很浪费资源。
若是扩展点加载失败，连扩展点的名称都拿不到了。好比：JDK 标准的 ScriptEngine，经过 getName() 获取脚本类型的名称，但若是 RubyScriptEngine 由于所依赖的 jruby.jar 不存在，致使 RubyScriptEngine 类加载失败，这个失败缘由被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的缘由。
增长了对扩展点 IoC 和 AOP 的支持，一个扩展点能够直接 setter 注入其它扩展点。

扩展点加载源代码位于dubbo-common/src/main/java/org/apache/dubbo/common/extension/ExtensionLoader.java

扩展点装配

ServiceConfig.export()和ReferenceConfig.refer()是dubbo bootstrap时组装运行时扩展点的关键入口，能够根据代码顺藤摸瓜。看代码时可能会被各类xxxConfig搞晕，能够参考dubbo官方文档《开发者指南-实现细节》

写在后面

对于Dubbo来说，本文中描述的微内核机制足够使用了。但对于上文中提到过的中台业务系统而言，仅仅依靠核心系统+plugin加载机制又远远不够。中台业务系统面临的是更为严苛的工程挑战：

当扩展点SPI定义上千，如何治理？
如何作到复杂业务流程配置所见即所得？
中台系统修改以后，如何作到对现有业务系统不影响？

这些问题，阿里中台的星环系统都给出了本身答案，不得不佩服阿里中台战略坚决推动的勇气以及其实现者的智慧。

饿了么蜂鸟物流招聘啦！

蜂鸟物流现急招资深Java工程师！

在这里，你将可以深度参与行业领先的即时配送核心系统开发工做、了解饿了么微服务架构，更可以在平常开发工做中深度践行饿了么多活的核心技术。

欢迎有意象的同窗踊跃投递简历！ 简历投递邮箱：wei.chensh@ele.me

岗位描述

职责

1. 负责物流业务系统相关的需求分析、代码开发、代码审查工做
2. 配合架构师、技术Leader确保业务系统技术产出质量，对系统可用性进行设计，代码质量进行把控，确保系统稳定性等
复制代码

岗位要求

1. 本科及以上学历（985/211优先），扎实的计算机基础
2. 有过复杂、高并发交易系统的架构设计和优化经验，尤为是深度参与过互联网业务架构设计的优先，拥有和工做年限相称的广度和（或）深度
3. 3年及以上工做经验，长期使用JAVA及开源框架进行项目开发，并有必定得项目管理经验；深刻使用Java，熟悉掌握经常使用的Java类库及框架，如多线程、并发处理、I/O与网络通信，Spring、Mybatis等;有系统排障经验，能够快速排查定位问题
4. 至少对高并发、分布式、缓存、jvm 调优、序列化、微服务等一个或多个领域有过研究，而且有相关实践经验
5. 熟悉 MySQL 应用开发，熟悉数据库原理和经常使用性能优化技术，以及 NoSQL，Queue 的原理、使用场景以及限制。
6. 学习能力强，认真负责，对技术有热情有渴望
7. 具有良好的分析解决问题能力，能独立承担任务
8. 具备良好的沟通、团队协做、计划和主动性思考的能力，在互联网或业界有必定影响力公司的工做经验者优先
复制代码

阅读博客还不过瘾？

欢迎你们扫二维码经过添加群助手，加入交流群，讨论和博客有关的技术问题，还能够和博主有更多互动

博客转载、线下活动及合做等问题请邮件至 shadowfly_zyl@hotmail.com 进行沟通