資訊專欄INFORMATION COLUMN
摘要：微服務去中心化治理上圖中外部服務和內部服務屬于網關所有的服務由統一的網關進行管理比如外部應用要調用服務就會經過網關外部服務內部應用也是一樣的如果服務要調用服務則也需要通過網關進行調用這樣看起來很規范但是每個用戶請求時只要有服務之間的交互則都
微服務去中心化治理
上圖中, 外部服務和內部服務屬于 API 網關, 所有的服務由統一的 API 網關進行管理.
比如外部應用要調用服務1, 就會經過 API 網關(外部服務), 內部應用也是一樣的. 如果服務N要調用服務2, 則也需要通過 API 網關進行調用.
這樣看起來很規范, 但是每個用戶請求時只要有服務之間的交互, 則都會從 API 網關進行路由, 業務量增大后, 在很大程度上增加了 API 網關的調用 TPS, API 網關很快就遇到了性能瓶頸.
微服務倡導去中心化的治理, 不推薦每個服務都使用相同的標準和技術來開發和使用服務. 也就是說你可以使用 C++ 開發一個服務, 來對接 Java 開發的另一個服務.
對于異構系統之間的交互標準, 可以使用 Thrift 遠程調用框架使用中間語言 (IDL) 來定義接口, 中間語言是獨立于任何語言的, 并提供了工具來生成中間語言, 以及在中間語言與具體語言之間的代碼轉換.
最后談下微服務架構是否就一定是去中心化的, 如果一個微服務架構沒有使用微服務網關那它一定是去中心化的, 如果使用了微服務網關就需要進行判斷.
微服務網關是否只提供了類似Dubbo服務注冊和發現能力, 實際訪問仍然是點對點的服務調用, 如果是這種模式也可以理解為整個微服務架構是去中心化的. 如果一個微服務網關提供了完全的對被調用系統的安全隔離, 包括提供了對每次消息調用的日志追溯能力, 那么微服務網關就是一個不可繞過的中心節點, 整個微服務架構也不再是去中心化的架構.
微服務的交互模式 讀者容錯模式讀者容錯模式指微服務化中服務提供者和消費者之間如何對接口的改變進行容錯. 也就是說, 消費者獲取到提供者返回的數據時, 無論這個數據如何變化, 我們只需要從中獲取到我們想要的數據, 可以忽略新的消息項、可選的消息項等不需要的數據.
只有當消費者不能完全識別接收到的消息, 或者無法通過識別的信息繼續處理流程時, 才拋出異常.去數據共享模式
在微服務領域, 微服務之間的交互通過定義良好的接口來實現, 不允許使用共享數據來實現.
在實踐的過程中, 有些方案的設計使用緩存或者數據庫作為兩個服務之間的紐帶, 在業務流程的處理過程中, 為了處理簡單, 前一個服務將中間結果存入數據庫或緩存, 下一個服務從緩存或數據庫中拿到數據繼續處理. 如下圖:
這種交互流程的缺點如下:
使得微服務之間的交互除了接口契約, 還存在數據庫存儲契約.
上游的數據庫格式發生變化時, 可能導致下游的處理邏輯出現問題.
多個服務共享一個資源服務, 對資源服務的運維難以劃清職責和界限.
在做雙機獨立部署時, 需要考慮服務和資源的路由情況, 跨機房的服務調用不能使用獨立的資源部署模式, 因此難以實現服務自治.
因此, 在設計微服務架構時, 一定不要共享緩存和數據庫等資源, 也不要使用總線模式, 服務之間的通信和交互只能依賴定義良好的接口, 通過使用 RESTful 樣式的 API 或透明的 RPC 調用框架.
消費者驅動契約模式消費者驅動契約模式用來定義服務之間交互接口改變的規則. 分為: 提供者契約、消費者契約、消費者驅動的契約.
提供者契約: 提供者提供了什么功能和消息格式, 各消費者不論實際需要多少功能都要無條件地遵守這些約定.
消費者契約: 是對某個消費者的需求進行更為精確的描述, 在一次具體的服務業交互場景下, 代表消費者需要提供者提供功能中的哪些部分數據. 消費者契約可以被用來標識現有的提供者契約, 也可以用來發現一個尚未明確的提供者契約.
消費者驅動的契約: 代表服務提供者向其所有當前消費者承諾遵守的約束. 一旦各消費者把自己的具體期望告訴提供者, 則提供者無論在什么時間和場景下, 都不能打破契約.
在實現的服務交互設計中, 上面這三種契約是同時存在的, 筆者(這本書的作者)所在的支付平臺里, 交易系統在完成一筆支付后, 需要到賬務系統為商戶入賬, 這個過程中, 服務契約表現如下.
生產者契約: 賬務系統提供 Dubbo 服務化接口, 參數為商戶賬號ID、入賬訂單號和入賬金額.
消費者契約: 賬務系統返回 DTO, 包含賬戶賬戶ID、入賬訂單號、入賬金額、入賬時間、賬務流水號、入賬狀態等, 而交易系統只需要使用其中的入賬訂單號和入賬狀態.
消費者驅動的契約: 為了保證資金安全, 交易系統作為入賬的發起者向賬務提出要求, 需要賬務做冪等和濾重處理, 對重復的入賬請求進行攔截; 賬務系統在接受這個契約后, 即將來有任何改變, 也不能打破這個限制, 否則就造成資金流失, 這在金融系統中是最嚴重的問題.
服務提供者契約是服務提供者單方面定下的規則, 而一個消費者契約會成為提供者契約的一部分, 多個服務消費者可以對服務提供者提出約束, 服務提供者需要在將來遵守服務消費者提出的契約, 這就是消費者驅動的契約.
上面的資料是我抄書加自己寫的, 如果難以理解可以看看 文章1 和 文章2總結
當調用任意一個服務時, 都需要經過同一個服務(API 網關, 也就是說每個服務都不能繞過這個節點), 這就是中心化; 微服務提倡去中心化治理, 因為當業務量增加后可能會導致 API 網關出現性能瓶頸.
不推薦每個服務都使用相同的標準和技術來開發和使用服務. 可以使用 C++ 開發一個服務來調用 Java 服務.
微服務推薦使用 RESTful 樣式的 API 或透明的 RPC 調用框架, 進行交互, 不推薦使用數據共享模式.
讀者容錯模式就是在消費者或提供者接口改變時進行容錯, 比如提供者返回數據中新增項后, 消費者指獲取需要的數據.
提供者契約: 服務提供者提供了哪些約定, 比如提供了什么功能和消息格式.
消費者契約: 是對某個消費者的需求進行更為精確的描述, 在一次具體的服務業交互場景下, 代表消費者需要提供者提供功能中的哪些部分數據.
消費者驅動契約: 例如服務端調整架構或接口調整而對消費者不透明, 導致接口調用失敗, 而CDC則是以消費者提出接口契約, 交由服務提供方實現, 并以測試用例對契約進行產生約束, 所以服務提供方在滿足測試用例的情況下可以自行更改接口或架構實現而不影響消費者.
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/72910.html
摘要：本文會以引出問題為主，后面有時間的話，筆者陸續會抽些重要的知識點進行詳細的剖析與解答。敬請關注服務端思維微信公眾號，獲取最新文章。 原文地址：梁桂釗的博客博客地址：http://blog.720ui.com 這里，筆者結合自己過往的面試經驗，整理了一些核心的知識清單，幫助讀者更好地回顧與復習 Java 服務端核心技術。本文會以引出問題為主，后面有時間的話，筆者陸續會抽些重要的知識點進...
摘要：昨天有個小學弟給我發來微信，說他現在有點后悔選擇開發了，月月光不說，還加班特別嚴重，平時也沒有屬于自己的時間去學習，問我剛畢業的時候是不是這樣。每天回到出租屋都是倒頭就睡，非常累，也沒有其他時間提升自己的技術。 昨天有個小學弟給我發來微信，說他現在有點后悔選擇Android開發了，月月光不說...
摘要：而微服務架構能否成功實踐，利用各種工具解決潛在問題是關鍵。因此，微服務本身可以通過庫和運行時代理解決客戶端服務發現負載均衡配置更新統計跟蹤等。與相比，解決了更廣的微服務架構問題。和處理了不同范圍的微服務架構技術點，而且是用了不同的方法。 Spring Cloud vs. Kubernetes，誰才是部署微服務的最佳拍檔？ Spring Cloud和Kubernetes都聲稱自己是開發和...
摘要：如何快速搭建一個微服務架構上圖異步通信方式通常異步的生產者消費者模式，通過等異步消息通訊協議規范。數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的數據庫技術等。 什么是微服務？ 微服務(Microservices Architecture)是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服...
摘要：鑒于目前大多數服務器環境都是，提前接觸能夠相輔相成。正則也是必須要掌握的一個知識點。有多種創建多線程的方式，不過目前使用線程池的多一些。 原創：小姐姐味道（微信公眾號ID：xjjdog），歡迎分享，轉載請保留出處。 你可能有所感悟。零散的資料讀了很多，但是很難有提升。到處是干貨，但是并沒什么用，簡單來說就是缺乏系統化。另外，噪音太多，雷同的框架一大把，我不至于全都要去學了吧。 這里，我...
閱讀 2438·2021-11-22 13:53
閱讀 1131·2021-09-22 16:06
閱讀 1373·2021-09-02 15:21
閱讀 1905·2019-08-30 15:55
閱讀 3125·2019-08-29 11:19
閱讀 1923·2019-08-26 13:23
閱讀 940·2019-08-23 18:23
閱讀 1753·2019-08-23 16:06
