centos选择什么版本_有几千个 Dubbo 实例的瓜子二手车，为什么要选择2.7.3版本？...
public void register(URL url) {
super.register(url);
failedRegistered.remove(url);
failedUnregistered.remove(url);
try {
// Sending a registration request to the server side
doRegister(url);
} catch (Exception e) {
Throwable t = e;
// If the startup detection is opened, the Exception is thrown directly.
boolean check = getUrl().getParameter(Constants.CHECK_KEY, true)
&& url.getParameter(Constants.CHECK_KEY, true)
&& !Constants.CONSUMER_PROTOCOL.equals(url.getProtocol());
boolean skipFailback = t instanceof SkipFailbackWrapperException;
if (check || skipFailback) {
if (skipFailback) {
t = t.getCause();
}
throw new IllegalStateException("Failed to register " + url + " to registry " + getUrl().getAddress() + ", cause: " + t.getMessage(), t);
} else {
logger.error("Failed to register " + url + ", waiting for retry, cause: " + t.getMessage(), t);
}
// Record a failed registration request to a failed list, retry regularly
failedRegistered.add(url);
}
}
在繼續排查問題前，我們先普及下這些概念：Dubbo 默認使用 curator 作為ZooKeeper 的客戶端， curator 與 ZooKeeper 是通過 session 維持連接的。當 curator 重連 ZooKeeper 時，若 session 未過期，則繼續使用原 session 進行連接；若 session 已過期，則創建新 session 重新連接。而 Ephemeral 節點與 session 是綁定的關系，在 session 過期后，會刪除此 session 下的 Ephemeral 節點。繼續對 doRegister(url) 的代碼進行進一步排查，我們發現在 CuratorZookeeperClient.createEphemeral(path) 方法中有這么一段邏輯：在createEphemeral(path) 捕獲了 NodeExistsException ，創建 Ephemeral 節點時，若此節點已存在，則認為 Ephemeral 節點創建成功。這段邏輯初看起來并沒有什么問題，且在以下兩種常見的場景下表現正常：Session 未過期，創建 Ephemeral 節點時原節點仍存在，不需要重新創建。
Session 已過期，創建 Ephemeral 節點時原節點已被 ZooKeeper 刪除，創建成功。
public void createEphemeral(String path) {
try {
client.create().withMode(CreateMode.EPHEMERAL).forPath(path);
} catch (NodeExistsException e) {
} catch (Exception e) {
throw new IllegalStateException(e.getMessage(), e);
}
}
但是實際上還有一種極端場景，ZooKeeper 的 Session 過期與刪除 Ephemeral 節點不是原子性的，也就是說客戶端在得到 Session 過期的消息時， Session 對應的 Ephemeral 節點可能還未被 ZooKeeper刪除。此時 Dubbo 去創建 Ephemeral 節點,發現原節點仍存在，故不重新創建。待 Ephemeral 節點被 ZooKeeper 刪除后，便會出現 Dubbo 認為重新注冊成功，但實際未成功的情況，也就是我們在生產環境遇到的問題。此時，問題的根源已被定位。定位問題之后，經我們與 Dubbo 社區交流，發現考拉的同學也遇到過同樣的問題，更確定了這個原因。問題的復現與修復定位到問題之后，我們便開始嘗試本地復現。由于 ZooKeeper 的 Session 過期但 Ephemeral 節點未被刪除的場景直接模擬比較困難，我們通過修改 ZooKeeper 源碼，在 Session 過期與刪除 Ephemeral 節點的邏輯中增加了一段休眠時間，間接模擬出這種極端場景，并在本地復現了此問題。在排查問題的過程中，我們發現 Kafka 的舊版本在使用 ZooKeeper 時也遇到過類似的問題，并參考 Kafka 關于此問題的修復方案，確定了 Dubbo 的修復方案。在創建 Ephemeral 節點捕獲到 NodeExistsException 時進行判斷，若 Ephemeral 節點的 SessionId 與當前客戶端的 SessionId 不同，則刪除并重建 Ephemeral 節點。在內部修復并驗證通過后，我們向社區提交了 issues 及 pr。Kafka 類似問題 issues：https://issues.apache.org/jira/browse/KAFKA-1387Dubbo 注冊恢復問題 issues：https://github.com/apache/dubbo/issues/5125瓜子的 Dubbo 升級歷程上文中的問題修復方案已經確定，但我們顯然不可能在每一個 Dubbo 版本上都進行修復。在咨詢了社區 Dubbo 的推薦版本后，我們決定在 Dubbo2.7.3 版本的基礎上，開發內部版本修復來這個問題。并借這個機會，開始推動公司 Dubbo 版本的統一升級工作。為什么要統一 Dubbo版本？統一 Dubbo 版本后，我們可以在此版本上內部緊急修復一些 Dubbo 問題(如上文的 Dubbo 注冊故障恢復失效問題)。
瓜子目前正在進行第二機房的建設，部分 Dubbo 服務也在逐漸往第二機房遷移。統一 Dubbo 版本，也是為 Dubbo 的多機房做鋪墊。
有利于我們后續對 Dubbo 服務的統一管控。
Dubbo 社區目前的發展方向與我們公司現階段對 Dubbo 的一些訴求相吻合，如支持 gRPC、云原生等。
我們了解到，在我們之前攜程已經與 Dubbo 社區合作進行了深度合作，攜程內部已全量升級為 2.7.3 的社區版本，并在協助社區修復了 2.7.3 版本的一些兼容性問題。感謝攜程的同學幫我們踩坑～
Dubbo2.7.3 版本在當時雖然是最新的版本，但已經發布了 2 個月的時間，從社區 issues 反饋來看，Dubbo 2.7.3 相對 Dubbo2.7 之前的幾個版本，在兼容性方面要好很多。
我們也咨詢了 Dubbo 社區的同學，推薦升級版本為 2.7.3。
初步兼容性驗證。首先，我們梳理了一些需要驗證的兼容性 case ，針對公司內部使用較多的 Dubbo 版本，與 Dubbo 2.7.3 一一進行了兼容性驗證。經驗證，除 DubboX 外， Dubbo 2.7.3 與其他 Dubbo 版本均兼容。DubboX 由于對 Dubbo 協議進行了更改，與 Dubbo2.7.3 不兼容。
生產環境兼容性驗證。在初步驗證兼容性通過后，我們與業務線合作，挑選了一些重要程度較低的項目，在生產環境對 Dubbo 2.7.3 與其他版本的兼容性進行了進一步驗證。并在內部版本修復了一些兼容性問題。
推動公司 Dubbo 版本升級。在 10 月初，完成了 Dubbo 兼容性驗證后，我們開始在各個業務線推動 Dubbo 的升級工作。截止到 12 月初,已經有 30% 的 Dubbo 服務的完成了版本升級。按照排期，預計于 2020 年 3 月底前完成公司 Dubbo 版本的統一升級。
org.apache.curator
curator-framework
4.2.0
org.apache.curator
curator-recipes
4.2.0
b. 分布式調度框架 elastic-job-lite 強依賴低版本的 curator，與 Dubbo 2.7.3 使用的 curator 版本不兼容，這給 Dubbo 版本升級工作帶來了一定阻塞。考慮到 elastic-job-lite 已經很久沒有人進行維護，目前一些業務線計劃將 elastic-job-lite 替換為其他的調度框架。3、OpenFeign 與 Dubbo 兼容性問題issues：https://github.com/apache/dubbo/issues/3990Dubbo 的 ServiceBean 監聽 Spring 的 ContextRefreshedEvent，進行服務暴露。OpenFeign 提前觸發了 ContextRefreshedEvent，此時 ServiceBean 還未完成初始化，于是就導致了應用啟動異常。參考社區的 pr，我們在內部版本修復了此問題。4、RpcException 兼容性問題Dubbo 低版本 consumer 不能識別 Dubbo 2.7 版本 provider 拋出的 org.apache.dubbo.rpc.RpcException。因此，在 consumer 全部升級到 2.7 之前，不建議將 provider 的 com.alibaba.dubbo.rpc.RpcException 改為 org.apache.dubbo.rpc.RpcException。5、QoS 端口占用Dubbo 2.7.3 默認開啟 QoS 功能，導致一些混部在物理機的 Dubbo 服務升級時出現 QoS 端口占用問題。關閉 QoS 功能后恢復。6、自定義擴展兼容性問題業務線對于 Dubbo 的自定義擴展比較少，因此在自定義擴展的兼容性方面暫時還沒有遇到比較難處理的問題，基本上都是變更 package 導致的問題，由業務線自行修復。7、Skywalking agent 兼容性問題我們項目中一般使 Skywalking 進行鏈路追蹤，由于 Skywalking agent6.0 的 plugin 不支持 Dubbo 2.7，因此統一升級 Skywalking agent 到 6.1 。Dubbo 多機房方案瓜子目前正在進行第二機房的建設工作，Dubbo 多機房是第二機房建設中比較重要的一個話題。在 Dubbo 版本統一的前提下，我們就能夠更順利的開展 Dubbo 多機房相關的調研與開發工作。初步方案我們咨詢了 Dubbo 社區的建議，并結合瓜子云平臺的現狀，初步確定了 Dubbo 多機房的方案。在每個機房內，部署一套獨立的 ZooKeeper 集群。集群間信息不同步。這樣就沒有了 ZooKeeper 集群跨機房延遲與數據不同步的問題。
Dubbo 服務注冊時，僅注冊到本機房的 ZooKeeper 集群；訂閱時，同時訂閱兩個機房的 ZooKeeper 集群。
實現同機房優先調用的路由邏輯。以減少跨機房調用導致的不必要網絡延遲。
瓜子云平臺默認將機房的標志信息注入容器的環境變量中。
provider 暴露服務時，讀取環境變量中的機房標志信息，追加到待暴露服務的 url 中。
consumer 調用 provider 時，讀取環境變量中的機房標志信息，根據路由策略優先調用具有相同標志信息的 provider。
總結
以上是生活随笔為你收集整理的centos选择什么版本_有几千个 Dubbo 实例的瓜子二手车，为什么要选择2.7.3版本？...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python flask高级编程之res
- 下一篇： Java常用设计模式————外观模式