*dubbo是阿里soa服務化治理方案的核心框架，是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及soa服務治理方案。>>原文內容
*dubbo服務提供者發佈服務流程
1.暴露服務到本地
2.暴露服務到遠程
3.啓動netty服務
4.連接zookeeper
5.註冊服務到zookeeper
6.監聽zookeeper中的消費服務
*dubbo服務消費者消費服務流程
1.通過ReferenceConfig類的private void init()方法檢查並初始化所有配置信息
2.調用createProxy創建代理消費者，最終得到的是服務代理
3.調用代理中的Protocol接口實現的refer方法生成Invoker實例
4.把invoker通過proxyfactory代理工廠轉換爲客戶端需要的接口，創建服務並返回。
*dubbo使用的協議主要有dubbo，rmi，hessian，http，webservice，thrift，memcached,redis
*dubbo節點角色說明：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
*dubbo核心配置
dubbo:registry/
dubbo:provider/
dubbo:consumer/
dubbo:service/
dubbo:reference/
dubbo:protocol/
dubbo:application/
dubbo:method/
*dubbo容錯策略
1.Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器 [1]。通常用於讀操作，但重試會帶來更長延遲。可通過 retries=“2” 來設置重試次數(不含第一次)。
2.Failfast Cluster：快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
3.Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
4.Failback Cluster：失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
5.Forking Cluster：並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks=“2” 來設置最大並行數。
6.Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一臺報錯則報錯 [2]。通常用於通知所有提供者更新緩存或日誌等本地資源信息。
dubbo負載均衡策略
隨機
輪詢
一致性hash
最少活躍調用數
Dubbo入門—搭建一個最簡單的演示框架>>原文內容
Dubbo註冊中心怎麼配置？
（官網地址）dubbo註冊中心配置主要通過dubbo:registry 標籤進行配置，主要使用Zookeeper做註冊中心。 <dubbo:registry address=“zookeeper://10.20.153.10:2181” /> 或 <dubbo:registry protocol=“zookeeper” address=“10.20.153.10:2181” /> 。（詳情官網）
多註冊中心： Dubbo 支持同一服務向多註冊中心同時註冊，或者不同服務分別註冊到不同的註冊中心上去，甚至可以同時引用註冊在不同註冊中心上的同名服務。（詳情官網）
dubbo連接註冊中心和直連的區別
在開發及測試環境下，經常需要繞過註冊中心，只測試指定服務提供者，這時候可能需要點對點直連，
點對點直聯方式，將以服務接口爲單位，忽略註冊中心的提供者列表，
服務註冊中心，動態的註冊和發現服務，使服務的位置透明，並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover， 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，註冊中心，服務提供者，服務消費者三者之間均爲長連接，監控中心除外，註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
註冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
簡而言之：直連快些，但直連不能像連接註冊中心那樣動態增減提供者。
Dubbo在安全機制方面是如何解決的
Dubbo通過Token令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。
ZooKeeper的腦裂的出現和解決方案
出現：
在一個大的集羣中往往會有一個master的存在，在長期運行過程中不可避免會出現宕機等等的問題導致master不可用，在出現這樣的情況以後往往會對系統產生很大的影響，所以一般的分佈式集羣中的master都採用了高可用的解決方案來避免這樣的情況發生。
master-slaver方式，存在一個master的節點，平時對外服務，同時有一個slaver節點來監控master，監控的同時有某種方式來進行數據同步。假如現在master掛掉了，slaver能很快獲知並且迅速切換爲新的master。但是在這種方式中，監控切換是一個很大的難題，但是現在Zookeeper的watch和分佈式鎖機制能比較好的解決這個問題。雖然Zookeeper很好的解決了這個問題，但是它的使用也存在其他的問題，比如腦裂。
在搭建hadoop的HA集羣環境後，由於兩個namenode的狀態不一，當active的namenode由於網絡等原因出現假死狀態，standby接收不到active的心跳，因此判斷active的namenode宕機，但實際上active並沒有死亡。此時standby的namenode就會切換成active的狀態，保證服務能夠正常使用。若原來的namenode復活，此時在整個集羣中就出現2個active狀態的namenode，該狀態成爲腦裂。腦裂現象可能導致這2個namenode爭搶資源，從節點不知道該連接哪一臺namenode，導致節點的數據不統一，這在企業生產中是不可以容忍的。
解決方案：
1、添加心跳線。
原來兩個namenode之間只有一條心跳線路，此時若斷開，則接收不到心跳報告，判斷對方已經死亡。此時若有2條心跳線路，一條斷開，另一條仍然能夠接收心跳報告，能保證集羣服務正常運行。2條心跳線路同時斷開的可能性比1條心跳線路斷開的小得多。再有，心跳線路之間也可以HA（高可用），這兩條心跳線路之間也可以互相檢測，若一條斷開，則另一條馬上起作用。正常情況下，則不起作用，節約資源。
2、啓用磁盤鎖。
由於兩個active會爭搶資源，導致從節點不知道該連接哪一臺namenode，可以使用磁盤鎖的形式，保證集羣中只能有一臺namenode獲取磁盤鎖，對外提供服務，避免數據錯亂的情況發生。但是，也會存在一個問題，若該namenode節點宕機，則不能主動釋放鎖，那麼其他的namenode就永遠獲取不了共享資源。因此，在HA上使用"智能鎖"就成爲了必要措施。"智能鎖"是指active的namenode檢測到了心跳線全部斷開時才啓動磁盤鎖，正常情況下不上鎖。保證了假死狀態下，仍然只有一臺namenode的節點提供服務。
3、設置仲裁機制
腦裂導致的後果最主要的原因就是從節點不知道該連接哪一臺namenode，此時如果有一方來決定誰留下，誰放棄就最好了。因此出現了仲裁機制，比如提供一個參考的IP地址，當出現腦裂現象時，雙方接收不到對方的心跳機制，但是能同時ping參考IP，如果有一方ping不通，那麼表示該節點網絡已經出現問題，則該節點需要自行退出爭搶資源的行列，或者更好的方法是直接強制重啓，這樣能更好的釋放曾經佔有的共享資源，將服務的提供功能讓給功能更全面的namenode節點。
以上的3種方式可以同時使用，這樣更能減少集羣中腦裂情況的發生。但是還是不能保證完全不出現，如果仲裁機制中2臺機器同時宕機，那麼此時集羣中沒有namenode可以使用。此時需要運維人員人工的搶修，或者提供一臺新的機器作爲namenode，這個時間是不可避免的。希望未來能有更好的解決辦法，能徹底杜絕這類情況的發生吧~
*分佈式鎖的幾種實現方式》原文內容
*dubbo 應用 筆記-------多個application name衝突問題
*Dubbo教程
https://blog.csdn.net/hellozpc/article/details/78575773
*SpringBoot整合Dubbo、Zookeeper（無xml配置）
https://blog.csdn.net/weixin_36512652/article/details/82388601
*idea dubbo在debug（調試）模式下，啓動很慢的問題解決方法
https://blog.csdn.net/u014316423/article/details/82740764
*dubbo超時與超時後自動重複調用的問題
https://blog.csdn.net/bestcxx/article/details/72782981