摘要：當提供程序線程池耗盡時，不能發送到使用者端。一些錯誤修正動態配置不能刪除，支持參數，監控統計問題等新功能支持手冊線程池耗盡時自動堆棧轉儲。在注冊表無法連接時被阻止。正常關機，在注冊表取消注冊和線程池關閉之間增加額外的等待時間。

dubbo分析

原因比較簡單，首先就是spring在開發環境的成熟以及使用的易用都是好評，spring本身的擴展成本也不高
關于xsd:schema的各個屬性具體含義就不作過多陳述，大家可以參見
http://www.w3school.com.cn/sc...
DubboBeanDefinitionParser和DubboNamespaceHandler的完成了對schemas的實現。源碼暫且另說，

ExtensionLoader dubbo核心類。
dubbo擴展性好主要在于它的插件形式，針對業務什么技術好就用什么（只針對在rpc架構的要點方面）
通過插件機制解耦依賴來實現框架設計原則中的針對接口編程而不針對實現。 如果屬性ExtensionLoader就屬性了dubbo的擴展。

提到擴展，我們看看jdk的service provider interface,后文用SPI簡寫，主要解耦機制比較強勢體現。經?？丛创a的同學應該很熟了吧，于dubbo的SPI對比。

jdk-spi:當服務的提供者，提供了服務接口的一種實現之后，在jar包的META-INF/services/目錄里同時創建一個以服務接口命名的文件。該文件里就是實現該服務接口的具體實現類。而當外部程序裝配這個模塊的時候，就能通過該jar包META-INF/services/里的配置文件找到具體的實現類名，并裝載實例化，完成模塊的注入。

各種jdbc驅動,log4j,spring對servlet3.0規范對ServletContainerInitializer的實現等。JDK的SPI是加載所有的實現，這里好像又得說到類加載器，可以自己去看看相關的文章。而dubbo只加載自己所想要的。
dubbo的SPI是對jdk的封裝，來滿足自己的特性。

dubbo-spi:dubbo的加載是單例模式，可以延遲加載

ExtensionLoader
| +-getAdativeExtension                             #獲取擴展的適配器類#
| +-createAdativeExtension                          #緩存中沒有就創建一個#
| +-getAdativeExtensionClasses                      #獲取適配器類#
| +-getExtensionClass                               #加載所有擴展點實現類#
| -createAdativeExtansionClass                     #dubbo幫我們動態創建一個適配器類

大致的流程如此，源碼暫時先不詳解了。
簡而言之，dubbo的特性

dubbo自己實現了一套代理機制

/*com.alibaba.dubbo.common.bytecode.Proxy*/
public abstract class Proxy
{
    private static final AtomicLong PROXY_CLASS_COUNTER = new AtomicLong(0);

    private static final String PACKAGE_NAME = Proxy.class.getPackage().getName();

    public static final InvocationHandler RETURN_NULL_INVOKER = new InvocationHandler(){
        public Object invoke(Object proxy, Method method, Object[] args){ return null; }
    };

    public static final InvocationHandler THROW_UNSUPPORTED_INVOKER = new InvocationHandler(){
        public Object invoke(Object proxy, Method method, Object[] args){ throw new UnsupportedOperationException("Method [" + ReflectUtils.getName(method) + "] unimplemented."); }
    };

    private static final Map> ProxyCacheMap = new WeakHashMap>();

    private static final Object PendingGenerationMarker = new Object();

根據申明的這些final static對象我們可以大概知道dubbo自己的需求
緩存機制: 遍歷所有入參接口+";"作為Key

/**
 * get method desc.
 * int do(int arg1) => "do(I)I"
 * void do(String arg1,boolean arg2) => "do(Ljava/lang/String;Z)V"
 * /

版本機制: 通過 PROXY_CLASS_COUNTER 作為單個版本號，規則大概為 pkg + ".poxy"+id,保證了沒有沖突

        // create ProxyInstance class.
        String pcn = pkg + ".proxy" + id;
        ccp.setClassName(pcn);
        ccp.addField("public static java.lang.reflect.Method[] methods;");
        ccp.addField("private " + InvocationHandler.class.getName() + " handler;");
        ccp.addConstructor(Modifier.PUBLIC, new Class[]{ InvocationHandler.class }, new Class[0], "handler=$1;");
        ccp.addDefaultConstructor();
        Class clazz = ccp.toClass();
        clazz.getField("methods").set(null, methods.toArray(new Method[0]));

        // create Proxy class.
        String fcn = Proxy.class.getName() + id;
        ccm = ClassGenerator.newInstance(cl);
        ccm.setClassName(fcn);
        ccm.addDefaultConstructor();
        ccm.setSuperClass(Proxy.class);
        ccm.addMethod("public Object newInstance(" + InvocationHandler.class.getName() + " h){ return new " + pcn + "($1); }");
        Class pc = ccm.toClass();
        proxy = (Proxy)pc.newInstance();

優雅的關機
MonitorFilter阻止RPC進程
動態配置：不能指定消費者IP，提供者端的配置不能被刪除。
路由規則解析問題
異步會影響下游的RPC調用。
供應商方面的流量控制優化。
社區報告的一些錯誤修正。

修復了PojoUtils問題：枚舉類型，私有文件。
當提供程序線程池耗盡時，RejectException不能發送到使用者端。
當負載過載時避免不必要的響應傳輸。
Slf4jLogger可以反映實際的行號。
使用延遲導出時，并發會導致意外的多端口綁定
當沒有提供者時，模擬不會工作。
一些優化：OverrideListener，在提供程序上停止不必要的心跳，Main Bootstrap進程等。
一些錯誤修正：動態配置不能刪除，telnet invoke支持json參數，監控統計問題等

新功能
支持Netty4 手冊
線程池耗盡時自動堆棧轉儲。手冊
Jdk 1.8新的日期時間類型支持hessian2序列化。

全新的注釋配置實現，修復了舊注釋版本報告的所有缺陷。（dubbo-spring-boot-starter將在稍后發布）
*更多詳情請參閱Dubbo Annotation-Driven
支持讀取IP和端口以注冊和綁定環境變量。
例
調整一些XML配置項目：dump.directory等。
Bootstrap在注冊表無法連接時被阻止。
MonitorService在第一次調用MonitorService時無法連接ZK時阻止RPC進程。
標記內部的JSON序列化已棄用，請改用fastjson。
RMI協議支持附件傳遞。
EnumSet類型支持hessian2序列化。
修復了一些錯誤和優化。

Dubbo編程模型增強。
修復了2.5.7中報告的一些錯誤。
更多細節請參閱Dubbo注解驅動
外部配置EnableDubbo，EnableDubboBindings也為Spring-Boot-Starter做準備。
更多細節請參閱Dubbo外部化配置
通過telnet和更強大的OPShttp：僅支持online，offline在此版本中，將在以下版本中提供更多功能
路由規則不應該每次都默認運行
優化春季活動表現
修復了使用策展人時的NPE路徑問題
修復了使用dubbo-admin報告的一些錯誤
Redis注冊表支持認證

bug
向后兼容RMI協議
Hessian序列化：
為java.util.Time類型添加空檢查
恢復hessian的覆蓋序列，子類的字段應該覆蓋父類的字段，而不是其他方式
Redis和多播注冊表不能脫機。
增加功能
注釋增強?；谶@個版本的dubbo-spring-boot-starter也已經發布。
為qos添加開關：dubbo.application.qos.enable=true/false。例如，注意我們配置qos的新方法，dubbo.qos.port已被更改為dubbo.application.qos.port。
正常關機，在注冊表取消注冊和線程池關閉之間增加額外的等待時間。
通過避免使用低效率來提高黑森序列化的性能synchronized。
參數驗證失敗時避免重試。
條件路由器還應檢查默認值。
解決漏洞

在這個版本中，我們將檢查從網絡接收到的序列化標識（只有當標識JDK序列化時）與當前實例中的標識匹配。如果無法匹配，則反序列化過程將被拒絕。由于原來的JDK反序列化有安全問題，我們這樣做是為了防止序列化類型，例如從意外篡改hessian2來java。

bug
FutureUnapter中的TimeUnit轉換錯誤。
在Docker中部署時，提供者端無法調用服務
Hessian序列化問題類型：short和byte。
刪除isdestrory（）在注冊表中檢查，確保在關閉時取消注冊
引用注釋支持注釋類型上的注釋

在本次發布中，我們主要合并了當當網貢獻的dubbox分支，突出了以下功能：

REST支持（通過整合resteasy）
高性能的序列化框架：kryo，FST
嵌入式tomcat支持
我們試圖保留原來的分支，同時進行以下小調整：

升級了一些依賴的版本：kryo，FST和tomcat
刪除了對核心RPC協議的更改以避免兼容性問題