基礎知識

分佈式基礎理論

什麼是分佈式系統架構

《分佈式系統原理與範型》定義：“分佈式系統是若干獨立計算機的集合，這些計算機對於用戶來說就像單個相關係統”

發展演變

單一應用架構

當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的數據訪問框架(ORM)是關鍵。
適用於小型網站，小型管理系統，將所有功能都部署到一個功能裏，簡單易用。
缺點：性能擴展比較難、協同開發問題、不利於升級維護

垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。
通過切分業務來實現各個模塊獨立部署，降低了維護和部署的難度，團隊各司其職更易管理，性能擴展也更方便，更有針對性。
缺點：公用模塊無法重複利用，開發性的浪費

分佈式服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分佈式服務框架(RPC)是關鍵。

流動計算架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率。此時，用於提高機器利用率的資源調度和治理中心(SOA)[ Service Oriented Architecture]是關鍵。

RPC

RPC(Remote Procedure Call)是指遠程過程調用，是一種進程間通信方式，他是一種技術的思想，而不是規範。它允許程序調用另一個地址空間（通常是共享網絡的另一臺機器上）的過程或函數，而不用程序員顯式編碼這個遠程調用的細節。即程序員無論是調用本地的還是遠程的函數，本質上編寫的調用代碼基本相同。

流程如下：

dubbo核心概念

Apache Dubbo是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現。官網：http://dubbo.apache.org/

服務提供者（Provider）：暴露服務的服務提供方，服務提供者在啓動時，向註冊中心註冊自己提供的服務。
服務消費者（Consumer）: 調用遠程服務的服務消費方，服務消費者在啓動時，向註冊中心訂閱自己所需的服務，服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
註冊中心（Registry）：註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者
監控中心（Monitor）：服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

調用關係說明:

服務容器負責啓動，加載，運行服務提供者。
服務提供者在啓動時，向註冊中心註冊自己提供的服務。
服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。

服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

dubbo環境搭建

windows安裝zookeeper

下載zookeeper，網址https://archive.apache.org/dist/zookeeper/
解壓zookeeper，運行zkServer.cmd ，初次運行會報錯，沒有zoo.cfg配置文件
將conf下的zoo_sample.cfg複製一份改名爲zoo.cfg，注意：
dataDir=./ 臨時數據存儲的目錄（可寫相對路徑）
clientPort=2181 zookeeper的端口號
修改完成後再次啓動zookeeper
使用zkCli.cmd測試
ls /：列出zookeeper根下保存的所有節點
create –e /ryan 123：創建一個atguigu節點，值爲123
get /ryan：獲取/ryan節點的值

windows安裝dubbo-admin

下載dubbo-admin
https://github.com/apache/incubator-dubbo-ops
進入目錄，修改dubbo-admin配置
修改 src\main\resources\application.properties 指定zookeeper地址
打包dubbo-admin
mvn clean package -Dmaven.test.skip=true
運行dubbo-admin
java -jar dubbo-admin-0.0.1-SNAPSHOT.jar

linux安裝zookeeper和dubbo-admin

可以採用tar包安裝、yum安裝或者docker安裝
dubbo-admin打包後jar包放在服務器通過shell腳本運行即可

dubbo-helloworld

spring-dubbo

定義父工程，包括公共依賴的版本，packaging爲pom

springboot-dubbo-comon

定義公共模塊，包括公共的entities service exception…

springboot-dubbo-provider

定義服務提供者，包括服務的具體實現、服務註冊到服務中心並暴露服務，啓動類要配置@EnableDubbo

springboot-dubbo-consumer

定義服務調用方，包括提供對外api、並調用提供者實現業務、通過@Reference註解生成代理實現對提供者的調用，同樣啓動類需要添加@EnableDubbo註解

配置中心

下載代碼
https://github.com/apache/dubbo-admin.git
進入 dubbo-monitor-simple\src\main\resources\conf，修改 dubbo.properties文件
打包dubbo-monitor-simple，mvn clean package -Dmaven.test.skip=true
打包後的tar文件上傳服務器，解壓運行start.sh
可能shell腳本沒有權限，需要賦權限；
可能啓動默認內存過大，需要在start.sh裏調小，否則一直啓動後一直停留在starting無法啓動成功
這裏坑還是蠻多的，還有用騰訊雲服務器啓動監控中心，註冊到zk的地址是內網地址，本地起的服務者和提供者無法根據ip調用監控中心

dubbo配置

配置原則

JVM 啓動 -D 參數優先，這樣可以使用戶在部署和啓動時進行參數重寫，比如在啓動時需改變協議的端口。
XML 次之，如果在 XML 中有配置，則 dubbo.properties 中的相應配置項無效。
Properties 最後，相當於缺省值，只有 XML 沒有配置時，dubbo.properties 的相應配置項纔會生效，通常用於共享公共配置，比如應用名。

重試次數

失敗自動切換，當出現失敗，重試其它服務器，但重試會帶來更長延遲
可通過 retries=“2” 來設置重試次數(不含第一次)
冪等操作設置重試次數：查詢刪除修改
非冪等操作不設置重試次數：新增

啓動檢查

Dubbo 缺省會在啓動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止 Spring 初始化完成，以便上線時，能及早發現問題，默認 check=“true”。
可以通過 check=“false” 關閉檢查，比如，測試時，有些服務不關心，或者出現了循環依賴，必須有一方先啓動。另外，如果你的 Spring 容器是懶加載的，或者通過 API 編程延遲引用服務，請關閉 check，否則服務臨時不可用時，會拋出異常，拿到 null 引用，如果 check=“false”，總是會返回引用，當服務恢復時，能自動連上。

如果check=“true”，不啓動provider直接啓動consumer會報錯

可以在註解上添加check參數

或者在配置中添加

還可以關閉註冊中心是否存在的啓動時檢查

超時時間

Provider

或者Consumer

Dubbo推薦在Provider上儘量多配置Consumer端屬性：

作服務的提供者，比服務使用方更清楚服務性能參數，如調用的超時時間，合理的重試次數等等
在Provider配置後，Consumer不配置則會使用Provider的配置值，即Provider配置可以作爲Consumer的缺省值。否則，Consumer會使用Consumer端的全局設置，這對於Provider不可控的，並且往往是不合理的

配置的覆蓋規則：

方法級配置別優於接口級別，即小Scope優先
Consumer端配置優於 Provider配置優於全局配置
最後是Dubbo Hard Code的配置值（見配置文檔）

版本號

當一個接口實現，出現不兼容升級時，可以用版本號過渡，版本號不同的服務相互間不引用
可以按照以下的步驟進行版本遷移：

在低壓力時間段，先升級一半提供者爲新版本
再將所有消費者升級爲新版本
然後將剩下的一半提供者升級爲新版本

老版本服務提供者配置：
<dubbo:service interface=“com.foo.BarService” version=“1.0.0” />
新版本服務提供者配置：
<dubbo:service interface=“com.foo.BarService” version=“2.0.0” />
老版本服務消費者配置：
<dubbo:reference id=“barService” interface=“com.foo.BarService” version=“1.0.0” />
新版本服務消費者配置：
<dubbo:reference id=“barService” interface=“com.foo.BarService” version=“2.0.0” />
如果不需要區分版本，可以按照以下的方式配置：
<dubbo:reference id=“barService” interface=“com.foo.BarService” version="*" />

本地存根

提供方有些時候想在客戶端也執行部分邏輯，比如：做 ThreadLocal 緩存，提前驗證參數，調用失敗後僞造容錯數據等等，此時就需要在 API 中帶上 Stub，客戶端生成 Proxy 實例，會把 Proxy 通過構造函數傳給 Stub，然後把 Stub 暴露給用戶，Stub 可以決定要不要去調 Proxy。

dubbo和springboot三種整合

導入dubbo-starter，在application.yml配置屬性，使用@Service暴露服務，用@Reference引用服務。啓動類@EnableDubbo或者配置包掃描。
保留dubbo xml配置文件，可以對具體方法進行配置。啓動類@ImportResource(locations]=“classpath:provider.xml”)
使用註解api的方式，自己寫配置類，添加到容器中，啓動類用@EnableDubbo或者@DubboComponentScan

【Way to java】Dubbo 1

文章目錄