微服務之間的協作方式

原文地址： , 歡迎大家訪問。

前面幾篇文章大概寫了什麼是微服務以及我們應該如何去劃分微服務，那麼本篇文章我們就來看下如果整合微服務，其實就是微服務之間如何溝通並且進行資料交換。

整合的幾點原則

• 保證API的技術無關性
  為什麼要保證這一點呢，之前在一文中提到過微服務有一個優點我們稱為技術異構性。也就是我們可以在不同的服務中選擇適合該服務具體業務的技術棧而不受其他服務的影響。那麼如果我們的API和技術強關聯性，也就意味著我們可能不能夠隨心所欲的去選擇技術棧。

• 使服務易於消費者使用
  這點就很好理解了，如果我們提供的服務消費者使用起來非常的困難或者複雜，那麼消費者為啥不去自己單獨實現一套呢而非要使用你的服務呢。

• 隱藏內部實現的細節
  過多的內部實現細節暴露給消費方，將會極大的增加微服務之間的耦合度。

整合方式

• 共享資料庫
  首先說明一下，雖然這種方式的整合速度最快，但是非常不推薦使用共享資料庫的方式來整合微服務，下面我們就一起來看下共享資料庫會帶來的問題。

  • 增加修改表結構的成本，因為幾乎所有的服務都會和資料庫打交道，哪怕是其中的一張表的修改也會牽扯到很多的服務。

  • 資料庫會限制我們的技術選型

  • 資料的修改點可能會分佈在各個服務，會導致資料庫極難維護，也很難去定位bug。

• 同步與非同步
  這個主要說的是服務之間的協作方式。

  • 同步
    客戶端發起一個遠端服務呼叫後，呼叫方會阻塞自己並等待整個操作的完成。通常情況下同步的方式是基於請求/響應機制的，客戶端發起一個請求，然後等待服務端響應，我們最常用的兩種呼叫方式就是RPC呼叫和REST呼叫。

  • 非同步
    呼叫方不用等待操作完成就可以返回，甚至不需要關係操作是否執行成功。非同步方式是基於事件的，客戶端釋出一個事件，其他的協作者收到事件後就知道該去做什麼事情，無需客戶端說明，可能不同的協作者收到同一個個事件後的執行的業務邏輯並不是一樣的。一般來講我們使用RabbitMQ等類似的訊息中介軟體就可以實現非同步呼叫。

• 編排與協同
  這裡我們透過一個例子來說明編排與協同，我們有一個系統，當使用者註冊一個賬號後我們會分別透過簡訊和郵件的方式通知使用者註冊成功，系統中存在三個服務分別是賬號服務、簡訊服務、郵件服務。下面我們分別來看一下在這個業務場景下編排和協同分別是一個什麼樣的表現形式。

  

  透過編排處理註冊

  • 可以顯著的解耦，只需要釋出一個一個的事件即可。如果其他服務關係某個事件的話，只需要簡單的訂閱即可。（優）

  • 完整的業務流程很難從程式碼中看出來，最好維護一份完整的文件。（缺）

  • 需要做一些額外的工作來監控流程是否正常的執行。（缺）

  • 可以降低耦合度，靈活性高。（優）

    
    

    

    透過協同處理註冊

  • 協同：告知各個服務的職責，服務透過監控事件或者訊息訂閱來觸發對應的操作。在上述例子中，賬號服務完成賬號的註冊之後可能只需要向訊息中介軟體傳送一條註冊成功的訊息，當訂閱了這類訊息的服務（郵件服務和簡訊服務）就可以執行已經定義好的業務邏輯了。

  • 中心服務承擔了太多職責。（缺）

  • 這種架構風格容易產生少量的“上帝”服務，而與其打交道的服務則通常淪為營養不良的、基於CRUD的服務。（缺）

  • 編排：有一個總指揮的大腦去告驅動各個服務。在這個例子中賬號服務就是一個大腦，當使用者註冊成功之後，賬號服務會取呼叫簡訊服務和郵件服務給使用者傳送簡訊和郵件通知。

服務間的DRY和程式碼重用

• 在微服務內部不要違反DRY

• 但是在跨服務的情況下可以適當違反DRY，服務之間的大量共享程式碼可能會帶來大量的耦合，這比重複程式碼帶來的問題更大。

• 如果要開發客戶端庫，儘量保證SDK是由服務端API開發人員之外的人來開發。理由是，如果是同一團隊開發SDK和服務端API的話很容易將服務端的邏輯洩露到SDK中，也就會降低內聚性。

作者：名字想好沒
連結：