dubbo使用遇到的問題 （舊業務過渡到dubbo）

其文檔位址： http://dubbo.io/User+Guide-zh.htm 源碼git位址： https://github.com/alibaba/dubbo.git

公司最近業務擴充從原先古老的spring架構SOA服務化，為分布式拆分，選了dubbo這個上手快的設計架構，剛畢業啥也沒接觸過，作為初學者在這中間遇到了很多問題，以下先簡略的整理出來。 先引入項目依賴： <dependency>

<groupId>com.alibaba</groupId>

<artifactId>dubbo</artifactId>

<version>2.5.3</version>

<exclusions>

<exclusion>

<artifactId>spring</artifactId>

<groupId>org.springframework</groupId>

</exclusion>

</exclusions>

</dependency>

<dependency>

<groupId>org.apache.zookeeper</groupId>

<artifactId>zookeeper</artifactId>

<version>3.3.3</version>

</dependency>

<dependency>

<groupId>com.github.sgroschupf</groupId>

<artifactId>zkclient</artifactId>

<version>0.1</version>

</dependency>

碰到的問題：

1.傳輸位元組流限制：

代碼品質不過關導緻超出dubbo支援的最大傳輸位元組，導緻服務崩潰而關閉：

在項目中遇到使用 dubbo 進行服務間調用（provider-consumer），由于系統需要傳輸檔案，于是使用位元組流在provider 和 consumer間通信，但是在

使用 dubbo時，收到報錯，提示 payload 過大，查閱資料發現，provider 和 consumer 之間的傳輸 有效載荷 不得大于 8兆  payload=88388608(=8M)

，而這個屬性是可選屬性，是以可以自己在配置檔案中配置

  <dubbo:protocol payload="883886080" name="" port="2880" />

2.分布式事務：

本地事務放在最先 ，遠端事務按其本地事務一層層往下封裝業務。

原先垂直式的業務調用，事務是基于本地記憶體管理的，是以要對其進行服務拆分，異常復原能夠保證事務的原子性。

3.序列化：

遠端傳輸的資料模型（實體等）必須實作序列化

舊業務代碼，以前是本地記憶體建立的實體對象，在做分布式網絡拆分後，TCP/IP協定是基于二進制流的，是以原先這些實體必須實作序列化。

4.多點部署：

一個服務多伺服器同個zk注冊，多個zk注冊（一個服務注冊到多個注冊中心，可隻在其中一個中心訂閱）

5.zk端口沖突：

按照ip+端口決定唯一性，開發階段經常會遇到在一台機器啟動同一個端口的服務，原來問題出在這。

6.服務失敗請求3次機制：

dubbo遇到服務調用失敗預設會共調用3次請求，如開發過程中遇到某一事務沒控制好，會導緻3次髒資料的入庫

7.啟動時檢查

在剛進行拆分重構時建議關閉這個啟動時檢查，以友善開發，可以無序的啟動相關服務。

預設會在啟動時檢查依賴的服務是否可用，不可用時會抛出異常，阻止Spring初始化完成，以便上線時，能及早發現問題，預設check=true。

關閉所有服務的啟動時檢查：(沒有提供者時報錯)

   <dubbo:consumer check="false" />

關閉某個服務的啟動時檢查：(沒有提供者時報錯)

   <dubbo:reference inter check="false" />