分散式基礎理論 1. 什麼是分散式系統? 分散式系統是若幹獨立電腦的集合,這些電腦對於用戶來說就像單個系統 2. 應用架構演變 單一應用架構 當網站流量很小時,只需一個應用,將所有功能都部署在一起,以減少部署節點和成本,適用於小型網站,小型管理系統 垂直應用架構 當訪問量逐漸增大,單一應用增加機 ...
分散式基礎理論
1. 什麼是分散式系統?
分散式系統是若幹獨立電腦的集合,這些電腦對於用戶來說就像單個系統
2. 應用架構演變
-
單一應用架構
當網站流量很小時,只需一個應用,將所有功能都部署在一起,以減少部署節點和成本,適用於小型網站,小型管理系統
-
垂直應用架構
當訪問量逐漸增大,單一應用增加機器帶來的加速度越來越小,將應用拆成互不相干的幾個應用,以提升效率。通過切分業務來實現各個模塊獨立部署,降低了維護和部署的難度,團隊各司其職更易管理,性能擴展也更方便,更有針對性
-
分散式服務架構
當垂直應用越來越多,應用之間交互不可避免,將核心業務抽取出來,作為獨立的服務,逐漸形成穩定的服務中心,使前端應用能更快速的響應多變的市場需求
-
流動計算架構
當服務越來越多,容量的評估,小服務資源的浪費等問題逐漸顯現,此時需增加一個調度中心基於訪問壓力實時管理集群容量,提高集群利用率
3. RPC
RPC(Remote Procedure Call)是指遠程過程調用,是一種進程間通信方式,它是一種技術的思想,而不是規範。它允許程式調用另一個地址空間(通常是共用網路的另一臺機器上)的過程或函數,而不用程式員顯式編碼這個遠程調用的細節。即程式員無論是調用本地的還是遠程的函數,本質上編寫的調用代碼基本相同
一次完整的 RPC 調用流程如下:
-
服務消費方(client)調用以本地調用方式調用服務
-
client stub接收到調用後負責將方法、參數等組裝成能夠進行網路傳輸的消息體
-
client stub找到服務地址,並將消息發送到服務端
-
server stub收到消息後進行解碼
-
server stub根據解碼結果調用本地的服務
-
本地服務執行並將結果返回給server stub
-
server stub將返回結果打包成消息併發送至消費方
-
client stub接收到消息,併進行解碼
-
服務消費方得到最終結果
RPC框架的目標就是把 2~8 這些步驟都封裝起來,這些細節對用戶來說是透明的,不可見的
Dubbo 核心概念
1. 簡介
Apache Dubbo 是一款高性能、輕量級的開源Java RPC框架,它提供了三大核心能力:面向介面的遠程方法調用,智能容錯和負載均衡,以及服務自動註冊和發現
2. 設計架構
相關組件說明如下:
- 服務提供者(Provider):暴露服務的服務提供方,服務提供者在啟動時,向註冊中心註冊自己提供的服務
- 服務消費者(Consumer): 調用遠程服務的服務消費方,服務消費者在啟動時,向註冊中心訂閱自己所需的服務,服務消費者,從提供者地址列表中,基於軟負載均衡演算法,選一臺提供者進行調用,如果調用失敗,再選另一臺調用
- 註冊中心(Registry):註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者
- 監控中心(Monitor):服務消費者和提供者,在記憶體中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心
調用關係說明如下:
- 服務容器負責啟動,載入,運行服務提供者
- 服務提供者在啟動時,向註冊中心註冊自己提供的服務
- 服務消費者在啟動時,向註冊中心訂閱自己所需的服務
- 註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者
- 服務消費者,從提供者地址列表中,基於軟負載均衡演算法,選一臺提供者進行調用,如果調用失敗,再選另一臺調用
- 服務消費者和提供者,在記憶體中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心
Dubbo 環境搭建
1. 安裝 Zookeeper
下載 zookeeper,網址:https://archive.apache.org/dist/zookeeper/
解壓,將 conf 下的 zoo_sample.cfg 複製一份改名為 zoo.cfg,註意如下配置
dataDir=./ 臨時數據存儲的目錄(可寫相對路徑)
clientPort=2181 zookeeper的埠號
運行 zkServer.cmd 啟動 zookeeper,使用 zkCli.cmd 測試
2. 安裝管理控制台
下載 dubbo-admin,網址:https://github.com/apache/incubator-dubbo-ops
進入目錄,修改 src\main\resources\application.properties 指定 zookeeper 地址
打包 dubbo-admin,以 Jar 包形式運行,預設使用 root/root 登陸
3. 安裝監控中心
下載 dubbo-monitor,網址:https://github.com/apache/incubator-dubbo-ops
進入目錄,修改 src\main\resources\conf\dubbo.properties
dubbo.registry.address=zookeeper://127.0.0.1:2181 # 註冊中心地址
dubbo.jetty.port=8080 # http訪問埠號
打包 dubbo-monitor,找到解壓後的 assembly.bin 文件,start.bat 啟動
在服務提供者和消費者的 xml 中配置以下內容,再次啟動服務提供和消費者啟動類
<!-- dubbo-monitor-simple 監控中心發現的配置-->
<dubbo:monitor protocol="registry"></dubbo:monitor>
監控中心即可捕獲到服務提供方和消費方信息
Dubbo 開發
1. 創建服務提供和服務消費工程
假設有如下需求場景:訂單服務作為服務消費者,用戶服務作為服務提供者,訂單服務需要從用戶服務查詢用戶的所有收貨地址
基於上述要求,用戶服務作為服務提供方,要提供一個對應的介面,具體的實現和實體這裡不詳細列出
/**
* 用戶服務
*/
public interface UserService {
/**
* 按照用戶id返回所有的收貨地址
*/
public List<UserAddress> getUserAddressList(String userId);
}
訂單服務作為服務消費方,直接使用服務提供方的介面
public class OrderServiceImpl implements OrderService {
public UserService userService;
public void initOrder(String userID) {
// 查詢用戶的收貨地址
List<UserAddress> userAddressList = userService.getUserAddressList(userID);
}
}
因為服務提供方和消費方用到了同樣的介面和實體,所以可以將服務介面,服務實體等單獨放在一個公共項目中,方便調用
2. 服務提供方配置
引入依賴
<!-- dubbo -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.2</version>
</dependency>
<!-- 註冊中心是 zookeeper,引入 zookeeper 客戶端 -->
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.12.0</version>
</dependency>
在 resource 文件夾中創建 provider.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd
http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<!-- 1.指定當前服務/應用的名字(同樣的服務名字相同,不要和別的服務同名) -->
<dubbo:application name="user-service-provider"></dubbo:application>
<!-- 2.指定註冊中心的位置 -->
<dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"></dubbo:registry>
<!-- 3.指定通信規則 -->
<dubbo:protocol name="dubbo" port="20880"></dubbo:protocol>
<!-- 4.暴露服務,讓別人調用ref指向服務的真正實現對象-->
<dubbo:service interface="com.lemon.gmail.service.UserService" ref="userServiceImpl"></dubbo:service>
<!-- 5.服務的實現-->
<bean id="userServiceImpl" class="com.lemon.gmail.service.impl.UserServiceImpl"></bean>
</beans>
3. 服務消費方配置
引入依賴
<!-- dubbo -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.2</version>
</dependency>
<!-- 註冊中心是 zookeeper,引入 zookeeper 客戶端 -->
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.12.0</version>
</dependency>
在 resource 文件夾中創建 consumer.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.3.xsd
http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd
http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<!-- 1.指定當前服務/應用的名字(同樣的服務名字相同,不要和別的服務同名) -->
<dubbo:application name="order-service-consumer"></dubbo:application>
<!-- 2.指定註冊中心的位置 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181"></dubbo:registry>
<!-- 3.調用遠程暴露的服務,生成遠程服務代理 -->
<dubbo:reference interface="com.yeeq.service.UserService" id="userService"></dubbo:reference>
</beans>
在當前 OrderServiceImpl 實現類中加上註解
@Service
public class OrderServiceImpl implements OrderService {
@Autowired
public UserService userService;
public void initOrder(String userID) {
// 查詢用戶的收貨地址
List<UserAddress> userAddressList = userService.getUserAddressList(userID);
}
}
Dubbo 整合 SpringBoot
1. 服務提供方
引入依賴
<dependency>
<groupId>com.alibaba.boot</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>0.2.0</version>
</dependency>
介面和實體和之前一樣,配置 application.properties
dubbo.application.name=boot-user-service-provider
dubbo.registry.address=127.0.0.1:2181
dubbo.registry.protocol=zookeeper
dubbo.protocol.name=dubbo
dubbo.protocol.port=20880
# 連接監控中心
dubbo.monitor.protocol=registry
在啟動類加上註解
@EnableDubbo // 開啟基於註解的dubbo功能
@SpringBootApplication
public class BootProviderApplication {
public static void main(String[] args) {
SpringApplication.run(BootProviderApplication.class, args);
}
}
2. 服務消費方
引入依賴
<dependency>
<groupId>com.alibaba.boot</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>0.2.0</version>
</dependency>
介面和實體和之前一樣,配置 application.properties
server.port=8081
dubbo.application.name=boot-order-service-consumer
dubbo.registry.address=zookeeper://127.0.0.1:2181
# 連接監控中心 註冊中心協議
dubbo.monitor.protocol=registry
在啟動類加上註解
@EnableDubbo // 開啟基於註解的dubbo功能
@SpringBootApplication
public class BootConsumerApplication {
public static void main(String[] args){
SpringApplication.run(BootConsumerApplication.class,args);
}
}
Dubbo 配置
1. 配置原則
- JVM 啟動 -D 參數優先,這樣可以使用戶在部署和啟動時進行參數重寫,比如在啟動時需改變協議的埠
- XML 次之,如果在 XML 中有配置,則 dubbo.properties 中的相應配置項無效
- Properties 最後,相當於預設值,只有 XML 沒有配置時,dubbo.properties 的相應配置項才會生效,通常用於共用公共配置,比如應用名
2. 啟動檢查
Dubbo 會在啟動時檢查依賴的服務是否可用,不可用時會拋出異常,阻止 Spring 初始化完成,以便上線時能及早發現問題
以消費者為例,在 consumer.xml 中添加配置
<!-- 配置當前消費者的統一規則,開啟啟動檢查,預設true -->
<dubbo:consumer check="true"></dubbo:consumer>
3. 超時時間
由於網路或服務端不可靠,會導致調用出現一種不確定的中間狀態(超時)。為了避免超時導致客戶端資源(線程)掛起耗盡,必須設置超時時間
<!-- 全局超時配置 -->
<dubbo:consumer timeout="5000" />
<!-- 指定介面以及特定方法超時配置 -->
<dubbo:reference interface="com.foo.BarService" timeout="2000">
<dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>
Dubbo 消費端和服務端都可以設置,推薦在 Provider 上儘量多配置 Consumer 端屬性,原因如下:
- 一般來說,服務提供者比服務使用方更清楚服務性能參數,如調用的超時時間,合理的重試次數等等
- 在 Provider 配置後,Consumer 不配置則會使用 Provider 的配置值,即 Provider 配置可以作為 Consumer 的預設值。否則,Consumer 會使用 Consumer 端的全局設置,這對於 Provider 是不可控的,並且往往是不合理的
4. 重試次數
當出現調用失敗,一般會進行重試。但重試會帶來更長延遲,可通過 retries="2"
來設置重試次數(不含第一次)
<!-- 有三種方式配置 -->
<dubbo:service retries="2" />
<dubbo:reference retries="2" />
<dubbo:reference>
<dubbo:method name="findFoo" retries="2" />
</dubbo:reference>
5. 多版本
當一個介面實現,出現不相容升級時,可以用版本號過渡,版本號不同的服務相互間不引用
服務端配置
<!-- 老版本服務提供者配置 -->
<bean id="BarServiceImpl01" class="com.foo.BarService.impl.BarServiceImpl01" />
<dubbo:service interface="com.foo.BarService" ref="BarServiceImpl01" version="1.0.0" />
<!-- 新版本服務提供者配置 -->
<bean id="BarServiceImpl02" class="com.foo.BarService.impl.BarServiceImpl02" />
<dubbo:service interface="com.foo.BarService" ref="BarServiceImpl02" 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="*" />
6. 本地存根
遠程服務中,客戶端通常只剩下介面,實現全在服務端,但服務方有時候也想在客戶端執行部分邏輯,比如:做 ThreadLocal 緩存,提前驗證參數,調用失敗後偽造容錯數據等等,此時就需要在 API 中帶上 Stub,客戶端生成 Proxy 實例,通過構造函數把 Proxy 傳給 Stub,然後把 Stub 暴露給用戶,Stub 可以決定要不要去調 Proxy
消費端開發對應服務的本地存根
public class UserServiceStub implements UserService {
private final IUserService userService;
// 構造函數傳入真正的遠程代理對象
public UserServiceStub(IUserService userService){
this.userService = userService;
}
@Override
public String hello(String name) {
if(name == null || "".equals(name)){
return "validate param";
}
return userService.hello(name);
}
}
設置存根配置
@Reference(version = "*",stub = "com.yeeq.stub.UserServiceStub")
private UserService userService;
Dubbo 高可用
1. Dubbo 的健壯性
- 監控中心宕掉不影響使用,只是丟失部分採樣數據
- 資料庫宕掉後,註冊中心仍能通過緩存提供服務列表查詢,但不能註冊新服務
- 註冊中心對等集群,任意一臺宕掉後,將自動切換到另一臺
- 註冊中心全部宕掉後,服務提供者和服務消費者仍能通過本地緩存通訊
- 服務提供者無狀態,任意一臺宕掉後,不影響使用
- 服務提供者全部宕掉後,服務消費者應用將無法使用,並無限次重連等待服務提供者恢復
2. Dubbo 集群下負載均衡
在集群負載均衡時,Dubbo 提供了多種均衡策略,預設為 random 隨機調用:
- Random LoadBalance:隨機,按權重設置隨機概率
- RoundRobin LoadBalance:輪循,按公約後的權重設置輪循比率
- LeastActive LoadBalance:最少活躍調用數,相同活躍數的隨機,活躍數指調用前後計數差
- ConsistentHash LoadBalance:一致性 Hash,相同參數的請求總是發到同一提供者
服務端和客戶端均可以設置
<!-- 服務級別 -->
<dubbo:service interface="..." loadbalance="roundrobin" />
<!-- 方法級別 -->
<dubbo:service interface="...">
<dubbo:method name="..." loadbalance="roundrobin" />
</dubbo:service>
3. 服務降級
當伺服器壓力劇增的情況下,根據實際業務情況及流量,對一些服務和頁面有策略的不處理或換種簡單的方式處理,從而釋放伺服器資源以保證核心交易正常運作或高效運作。可以通過服務降級功能臨時屏蔽某個出錯的非關鍵服務,並定義降級後的返回策略
向註冊中心寫入動態配置覆蓋規則:
RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));
其中:
mock=force:return+null
表示消費方對該服務的方法調用都直接返回 null 值,不發起遠程調用,用來屏蔽不重要服務不可用時對調用方的影響mock=fail:return+null
表示消費方對該服務的方法調用在失敗後,再返回 null 值,不拋異常,用來容忍不重要服務不穩定時對調用方的影響
4. 集群容錯
在集群調用失敗時,Dubbo 提供了多種容錯方案,預設為 failover 重試:
- Failover Cluster:失敗自動切換,當出現失敗,重試其它伺服器,通常用於讀操作,但重試會帶來更長延遲,可通過
retries="2"
來設置重試次數(不含第一次) - Failfast Cluste:快速失敗,只發起一次調用,失敗立即報錯,通常用於非冪等性的寫操作,比如新增記錄
- Failsafe Cluster:失敗安全,出現異常時,直接忽略。通常用於寫入審計日誌等操作
- Failback Cluster:失敗自動恢復,後臺記錄失敗請求,定時重發。通常用於消息通知操作
- Forking Cluster:並行調用多個伺服器,只要一個成功即返回,通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。可通過
forks="2"
來設置最大並行數 - Broadcast Cluster:廣播調用所有提供者,逐個調用,任意一臺報錯則報錯,通常用於通知所有提供者更新緩存或日誌等本地資源信息
按照以下示例在服務提供方和消費方配置集群模式
<!-- 兩種方式配置 -->
<dubbo:service cluster="failsafe" />
<dubbo:reference cluster="failsafe" />