[[404370]]

介紹

策略模式

這個(gè)毫無爭(zhēng)議，Dubbo是基于SPI來擴(kuò)展的，SPI就是典型的策略模式。

Dubbo中可替換的組件太多了，例如負(fù)載均衡策略

工廠模式

「簡(jiǎn)單工廠模式」：提供一個(gè)方法，返回創(chuàng)建好的對(duì)象

public class VideoFactory { 
 
    public static Video getVideo(String type) { 
        if ("java".equalsIgnoreCase(type)) { 
            return new JavaVideo(); 
        } else if ("python".equalsIgnoreCase(type)) { 
            return new PythonVideo(); 
        } 
        return null; 
    } 
} 

「工廠方法模式」：當(dāng)工廠想提供更多產(chǎn)品時(shí)，還得對(duì)創(chuàng)建過程進(jìn)行修改，因此抽象出一個(gè)工廠類，當(dāng)增加一種產(chǎn)品，就增加一個(gè)工廠類(繼承抽象工廠類或?qū)崿F(xiàn)接口)。這樣就實(shí)現(xiàn)了對(duì)擴(kuò)展開發(fā)，對(duì)修改關(guān)閉

public abstract class VideoFactory { 
 
    public abstract Video getVideo(); 
} 
public class JavaVideoFactory extends VideoFactory { 
    public Video getVideo() { 
        return new JavaVideo(); 
    } 
} 
public class Test { 
 
    public static void main(String[] args) { 
        VideoFactory videoFactory = new JavaVideoFactory(); 
        Video video = videoFactory.getVideo(); 
        // 學(xué)習(xí)Java視頻 
        video.study(); 
    } 
} 

「抽象工廠模式」：當(dāng)生產(chǎn)的產(chǎn)品較多時(shí)，如果我們用工廠方法模式會(huì)造成類爆照，此時(shí)我們就可以把相關(guān)的產(chǎn)品生產(chǎn)放到一個(gè)工廠類中

public abstract class CourseFactory { 
 
    public abstract Video getVideo(); 
    public abstract Article getArticle(); 
} 
public class JavaCourseFactory extends CourseFactory { 
    public Video getVideo() { 
        return new JavaVideo(); 
    } 
 
    public Article getArticle() { 
        return new JavaArticle(); 
    } 
} 

因?yàn)镴avaVideo和JavaArticle都是Java相關(guān)的資料，所以可以用一個(gè)工廠類來生產(chǎn)。如果用工廠方法模式來設(shè)計(jì)的話，JavaVideo和JavaArticle都會(huì)有一個(gè)對(duì)應(yīng)的工廠類

簡(jiǎn)單工廠模式

public class LoggerFactory { 
 
    public static Logger getLogger(Class<?> key) { 
        return LOGGERS.computeIfAbsent(key.getName(), name -> new FailsafeLogger(LOGGER_ADAPTER.getLogger(name))); 
    } 
} 

工廠方法模式

Dubbo可以對(duì)結(jié)果進(jìn)行緩存，緩存的策略有很多種，一種策略對(duì)應(yīng)一個(gè)緩存工廠類

@SPI("lru") 
public interface CacheFactory { 
 
    @Adaptive("cache") 
    Cache getCache(URL url, Invocation invocation); 
 
} 

抽象工廠模式

在RPC框架中，客戶端發(fā)送請(qǐng)求和服務(wù)端執(zhí)行請(qǐng)求的過程都是由代理類來完成的?？蛻舳说拇韺?duì)象叫做Client Stub，服務(wù)端的代理對(duì)象叫做Server Stub。

@SPI("javassist") 
public interface ProxyFactory { 
 
    // 針對(duì)consumer端，創(chuàng)建出代理對(duì)象 
    @Adaptive({Constants.PROXY_KEY}) 
    <T> T getProxy(Invoker<T> invoker) throws RpcException; 
 
    // 針對(duì)consumer端，創(chuàng)建出代理對(duì)象 
    @Adaptive({Constants.PROXY_KEY}) 
    <T> T getProxy(Invoker<T> invoker, boolean generic) throws RpcException; 
 
    // 針對(duì)provider端，將服務(wù)對(duì)象包裝成一個(gè)Invoker對(duì)象 
    @Adaptive({Constants.PROXY_KEY}) 
    <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) throws RpcException; 
 
} 

單例模式

服務(wù)導(dǎo)出的過程中，為了防止開啟多個(gè)NettyServer，用了單例模式

private void openServer(URL url) { 
    // find server. 
    String key = url.getAddress(); 
    //client can export a service which's only for server to invoke 
    boolean isServer = url.getParameter(Constants.IS_SERVER_KEY, true); 
    if (isServer) { 
        ExchangeServer server = serverMap.get(key); 
        if (server == null) { 
            synchronized (this) { 
                server = serverMap.get(key); 
                if (server == null) { 
                    // 創(chuàng)建服務(wù)器實(shí)例 
                    serverMap.put(key, createServer(url)); 
                } 
            } 
        } else { 
            // server supports reset, use together with override 
            server.reset(url); 
        } 
    } 
} 

裝飾者模式

Dubbo中網(wǎng)絡(luò)傳輸層用到了Netty，當(dāng)我們用Netty開發(fā)時(shí)，一般都是寫多個(gè)ChannelHandler，然后將這些ChannelHandler添加到ChannelPipeline上，就是典型的責(zé)任鏈模式

但是Dubbo考慮到有可能替換網(wǎng)絡(luò)框架組件，所以整個(gè)請(qǐng)求發(fā)送和請(qǐng)求接收的過程全部用的都是裝飾者模式。即只有NettyServerHandler實(shí)現(xiàn)的接口是Netty中的ChannelHandler，剩下的接口實(shí)現(xiàn)的是Dubbo中的ChannelHandler

如下是服務(wù)端消息接收會(huì)經(jīng)過的ChannelHandler

代理模式

前面說過了哈，Client Stub和Server Stub都是代理對(duì)象

適配器模式

Dubbo可以支持多個(gè)日志框架，每個(gè)日志框架的實(shí)現(xiàn)都有對(duì)應(yīng)的Adapter類，為什么要搞Adapter類呢，因?yàn)镈ubbo中日志接口Logger用的是自己的，而實(shí)現(xiàn)類是引入的。但這些日志實(shí)現(xiàn)類的等級(jí)和Dubbo中定義的日志等級(jí)并不完全一致，例如JdkLogger中并沒有trace和debug這個(gè)等級(jí)，所以要用Adapter類把Logger中的等級(jí)對(duì)應(yīng)到實(shí)現(xiàn)類中的合適等級(jí)

public interface Logger 
 
    // 省略部分代碼 
     
    void trace(String msg); 
 
    void debug(String msg); 
 
    void info(String msg); 
 
    void warn(String msg); 
 
} 

觀察者模式

在Dubbo中提供了各種注冊(cè)中心的實(shí)現(xiàn)，類圖如下。AbstractRegistry對(duì)注冊(cè)中心的內(nèi)容進(jìn)行了緩存，這樣能保證當(dāng)注冊(cè)中心不可用的時(shí)候，還能正常提供服務(wù)

「既然對(duì)注冊(cè)中心的內(nèi)容進(jìn)行了緩存，那么注冊(cè)中心的內(nèi)容發(fā)生改變的時(shí)候，怎么通知客戶端呢?」

例如客戶端從注冊(cè)中心獲取到服務(wù)端的地址，并緩存到本地，如果服務(wù)端宕機(jī)了，本地緩存怎么清除呢?此時(shí)就得需要對(duì)有可能變動(dòng)的節(jié)點(diǎn)進(jìn)行訂閱。當(dāng)節(jié)點(diǎn)發(fā)生變化的時(shí)候，就能收到通知，這樣就能更新本地緩存。

NotifyListener就是接收節(jié)點(diǎn)變動(dòng)的接口，各種注冊(cè)中心的節(jié)點(diǎn)發(fā)生變化都會(huì)主動(dòng)回調(diào)這個(gè)接口

public interface RegistryService { 
 
    // 注冊(cè) 
    void register(URL url); 
 
    // 注銷 
    void unregister(URL url); 
 
    // 訂閱，訂閱的數(shù)據(jù)發(fā)生變化，會(huì)主動(dòng)通知NotifyListener#notify方法 
    void subscribe(URL url, NotifyListener listener); 
 
    // 退訂 
    void unsubscribe(URL url, NotifyListener listener); 
 
    // 查找服務(wù)地址 
    List<URL> lookup(URL url); 
 
} 

責(zé)任鏈模式

代理對(duì)象(Client Stub或者Server Stub)在執(zhí)行的過程中會(huì)執(zhí)行所有Filter的invoke方法，但是這個(gè)實(shí)現(xiàn)方法是對(duì)對(duì)象不斷進(jìn)行包裝，看起來非常像裝飾者模式，但是基于方法名和這個(gè)Filter的功能，我更覺得這個(gè)是責(zé)任鏈模式

private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker, String key, String group) { 
    Invoker<T> last = invoker; 
    // 獲取自動(dòng)激活的擴(kuò)展類 
    List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group); 
    if (!filters.isEmpty()) { 
        for (int i = filters.size() - 1; i >= 0; i--) { 
            final Filter filter = filters.get(i); 
            final Invoker<T> next = last; 
            last = new Invoker<T>() { 
 
                // 省略部分代碼 
 
                @Override 
                public Result invoke(Invocation invocation) throws RpcException { 
                    // filter 不斷的套在 Invoker 上，調(diào)用invoke方法的時(shí)候就會(huì)執(zhí)行filter的invoke方法 
                    Result result = filter.invoke(next, invocation); 
                    if (result instanceof AsyncRpcResult) { 
                        AsyncRpcResult asyncResult = (AsyncRpcResult) result; 
                        asyncResult.thenApplyWithContext(r -> filter.onResponse(r, invoker, invocation)); 
                        return asyncResult; 
                    } else { 
                        return filter.onResponse(result, invoker, invocation); 
                    } 
                } 
 
            }; 
        } 
    } 
    return last; 
} 

本文轉(zhuǎn)載自微信公眾號(hào)「Java識(shí)堂」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java識(shí)堂公眾號(hào)。