Dubbo接口受權

Dubbo是阿里巴巴開源的一個分佈式服務框架，在咱們 貝聊內部，普遍地使用了這個框架。

使用Dubbo能夠很方便地進行遠程服務調用，在同一個註冊中心，業務系統能夠隨意調用其餘服務。可是有時候咱們但願某些接口只有符合條件的用戶才能調用，其餘人不能隨意調用。

Dubbo自己沒有接口的受權機制，咱們決定爲Dubbo加上這個機制。大體是這樣：

受權應該知足不一樣的粒度：

• 全部接口
• 部分接口
• 某個接口

同時，若是受權服務不可用，不該該影響接口的訪問。

在Dubbo中，provider能夠經過實現com.alibaba.dubbo.rpc.Filter對接口的調用進行處理：

/**
 * 處理Dubbo接口受權
 */
public class AuthorizationFilter implements Filter {

    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        if (受權經過) {
            return invoker.invoke(invocation);
        }
        else {
            // TODO 錯誤處理
        }
    }
}
複製代碼

Dubbo配置：

<dubbo:provider filter="自定義filter的名稱"/>
複製代碼

那麼，如何知道調用者是誰？咱們能夠給每一個系統分配一個ID，好比叫appId。

consumer經過attachment把appId傳遞給provider，那麼provider就知道是誰發起調用了，在consumer能夠這樣設置：

RpcContext.getContext().setAttachment("appId", "someAppId");
複製代碼

在provider讀取appId：

String appId = invocation.getAttachment("appId");
複製代碼

權限的設計就比較簡單了：
權限粒度能夠根據本身的須要設計。

還能夠實現更復雜的驗證，好比加上時間戳、簽名。可是設置這些attachment對於consumer是比較麻煩的，每次調用都要設置，若是未來規則變化，就更麻煩了。

因而咱們再寫一個filter處理consumer的attachment：

public class ConsumerContextFilter implements Filter {
    /*
     * TODO 經過讀取配置或注入appId
     */
    private String appId;
    
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        // 設置appId
        RpcContext.getContext().setAttachment("appId", appId);
        
        // 執行接口
        return invoker.invoke(invocation);
    }
}
複製代碼

這樣 consumer 經過配置 filter 的方式就完成了受權參數的設置，全部調用 provider 的代碼不須要作任何修改。 至此，一個簡單的Dubbo接口受權機制就完成了。