Dubbo部分
- Dubbo工作原理
- dubbo工作原理
第一層：service層，接口層，給服務提供者和消費者來實現的
第二層：config層，配置層，主要是對dubbo進行各種配置的
第三層：proxy層，服務代理層，透明生成客戶端的stub和服務單的skeleton
第四層：registry層，服務註冊層，負責服務的註冊與發現
第五層：cluster層，集羣層，封裝多個服務提供者的路由以及負載均衡，將多個實例組合成一個服務
第六層：monitor層，監控層，對rpc接口的調用次數和調用時間進行監控
第七層：protocol層，遠程調用層，封裝rpc調用
第八層：exchange層，信息交換層，封裝請求響應模式，同步轉異步
第九層：transport層，網絡傳輸層，抽象mina和netty爲統一接口
第十層：serialize層，數據序列化層
- dubbo工作原理
工作流程： 1）第一步，provider向註冊中心去註冊
2）第二步，consumer從註冊中心訂閱服務，註冊中心會通知consumer註冊好的服務
3）第三步，consumer調用provider
4）第四步，consumer和provider都異步的通知監控中心
- 註冊中心掛了可以繼續通信嗎？
可以，因爲剛開始初始化的時候，消費者會將提供者的地址等信息拉取到本地緩存，所以註冊中心掛了可以繼續通信。- Dubbo的執行流程：
項目一啓動，加載配置文件的時候，就會初始化，服務的提供方ServiceProvider就會向註冊中心註冊自己提供的服務，當消費者在啓動時，就會向註冊中心訂閱自己所需要的服務，如果服務提供方有數據變更等，註冊中心將基於長連接的形式推送變更數據給消費者。默認使用Dubbo協議：連接個數：單連接連接方式：長連接傳輸協議：TCP傳輸方式：NIO異步傳輸序列化：Hessian二進制序列化適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者無法壓滿提供者，儘量不要使用dubbo協議傳輸大文件或超大字符串使用場景：常規遠程服務方法調用從上面的適用範圍總結，dubbo適合小數據量大併發的服務調用，以及消費者機器遠大於生產者機器數的情況，不適合傳輸大數據量的服務比如文件、視頻等，除非請求量很低。
- Dubbo的安全性如何得到保障：
a.在有註冊中心的情況下,可以通過dubbbo admin中的路由規則，來指定固定ip的消費方來訪問
b.在直連的情況下，通過在服務的提供方中設置密碼(令牌)token，消費方需要在消費時也輸入這 個密碼，才能夠正確使用。
Dubbo添加服務ip白名單，防止不法調用 - Duubo中如何保證分佈式事務？
一般情況下，我們儘量將需要事務的方法放在一個service中，從而避開分步式事務。
Dubbo底層是基於socket： Socket通信是一個全雙工的方式，如果有多個線程同時進行遠程方法調用，這時建立在client server之間的socket連接上會有很多雙方發送的消息傳遞，前後順序也可能是亂七八糟的，server處理完結果後，將結果消息發送給client，client收到很多消息，怎麼知道哪個消息結果是原先哪個線程調用的？
答：使用一個ID，讓其唯一，然後傳遞給服務端，再服務端又回傳回來，這樣就知道結果是原先哪個線程的了。 - Dubbo的心跳機制：
目的：
維持provider和consumer之間的長連接
實現：
dubbo心跳時間heartbeat默認是1s，超過heartbeat時間沒有收到消息，就發送心跳消 息(provider，consumer一樣),如果連着3次(heartbeatTimeout爲heartbeat*3)沒有收到心跳響應，provider會關閉channel，而consumer會進行重連;不論是provider還是consumer的心跳檢測都是通過啓動定時任務的方式實現；
Dubbo的zookeeper做註冊中心，如果註冊中心全部掛掉，發佈者和訂閱者還能通信嗎？可以通信的，啓動dubbo時，消費者會從zk拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用；註冊中心對等集羣，任意一臺宕機後，將會切換到另一臺；註冊中心全部宕機後，服務的提供者和消費者仍能通過本地緩存通訊。服務提供者無狀態，任一臺 宕機後，不影響使用；服務提供者全部宕機，服務消費者會無法使用，並無限次重連等待服務者恢復；掛掉是不要緊的，但前提是你沒有增加新的服務，如果你要調用新的服務，則是不能辦到的。
隨便寫點什麼，然後就發佈了！