分布式微服務架構設計原理

2020-09-05 閃念基因

一、單體服務架構

1、JEE架構：UI、EJB邏輯層、資料庫

優點：對單體架構分層，接入層、邏輯層、數據層；

缺點：

a、邏輯層業務耦合性高，組件指責劃分不清晰，導致新功能迭代，增加和維護非常困難。

b、EJB2.0實現採用了大量的XML配置文件，組件學習曲線高、難以單元測試，超重量級；

2、SSH架構：Structs（UI 交互層）、Spring（業務邏輯實現）、Hibernate（對象領域的模型與關係型資料庫模式映射）

Structs MVC模型：

Spring：邏輯層實現核心容器，核心思想 IOC和AOP

a、IOC（控制反轉）：

EJB 實現： 實現服務化組件 Bean 時，將依賴多個容器接口，複雜容器規則的 XML配置，測試依賴應用伺服器環境；

Spring 實現：業務邏輯服務組件都是獨立的，Spring 容器支持單元測試，對下層依賴服務進行 Mock, 方便測試。

b、AOP(面向切面編程）：日誌、安全、事物、應用程式性能APM； 具體實現：AspectJ

Hibernate：對象領域模型與關係型資料庫模型映射

存在性能問題，使用更加靈活的MyBatis實現ORM

二、服務化架構 SOA

1、WebService:

原理：

1）通過UDDI協議註冊WebService服務目錄

2）通過UDDI協議查詢服務，並獲得WSDL服務描述文件

3） 通過WSDL語言遠程調用WebService提供服務

缺點：

1）依賴中心服務發現機制

2）使用SOAP通信協議，通過XML序列和反序列化數據

3）服務化管理和治理設施不完善

2、ESB: 企業服務總線

原理：

1、每個服務提供者通過總線模式插入系統

2、總線根據路程的編排將服務的輸出轉化為流程的下一個輸出節點

缺點：

1、ESB服務過重的整體服務

2、通過ESB試圖隱藏系統內部的複雜性，但是系統內部複雜性依舊存在

三、微服務架構

1、職能團隊劃分

2、去中心化服務治理

微服務架構倡導去中心化的服務管理和治理，儘量不要設置中心化的管理服務，最差在中心化管理服務癱瘓時有替代方案和設計。

API網關：所有外部服務和內部服務通過API網關統一管理

缺點：用戶請求通過機房，都需要經過API網關路由，服務上量後，很大程度上放量了API網關的調用TPS。

3、微服務交互模式

a、讀者容錯模式：服務提供與消費者之間對接口改變進行容錯

b、消費者驅動契約模式：

舉例：

生產者契約：帳務系統入帳請求（商戶帳戶ID、入帳訂單號、入帳金額）

消費者契約：帳務系統入帳返回（商戶帳戶ID、入帳訂單號、入帳金額、入帳時間、財務流水號、入帳狀態）

消費者驅動契約：對於交易系統只需要帳戶系統的入帳訂單號和入帳狀態，為了保證資金的安全，交易系統對帳務系統發起者

提出冪等和濾重處理，對重複的入帳請求進行攔截。

c、去數據共享模式

缺點：

a、微服務之前交互除了接口契約，還有數據存儲契約

b、上遊數據格式發生變化時，可能導致下遊處理邏輯出現問題

在數據服務時，一定不要共享緩存和資料庫等資源。

4、微服務的分解和組合模式

分解：

微服務架構需求分析和架構設計中，通常用領域的動詞和名詞來劃分。拆分後，系統具有敏捷性、靈活性、可伸縮性。

例如電商後臺系統，可分解為訂單、商戶、商戶目錄、庫存、購物車、交易、支付、發票、物流等子系統

組合：

1、服務代理模式：

平滑系統遷移四階段：

1)、新老系統雙寫

2)、遷移雙寫之前的歷史遺留數據

3)、讀請求切換新系統

4)、下調雙寫邏輯、，只寫新系統

2、服務聚合模式

根據業務流程處理的需要，按一定的順序調用一依賴的多個服務，對依賴的微服務返回的數據進行組合、加工和轉換，最後按一定的形式返回給使用方。

3、服務串聯模式，類似工作流

四、技術選型

1、RPC

1）JDK RMI：JDK1.4後內置遠程服務調用技術棧，不採用

a、RMI採用自帶JDK專用序列化協議，不能跨語言

b、使用底層網絡協議，不如基於文本的HTTP可讀

2）Hessian和Burlap

a、基於Http傳輸。

b、Hessian將對象序列化成語言無關的二進位協議

Burlap將對象序列化成與語言無關的XML數據

c、都適合傳輸較小對象，大複雜對象，都沒有RMI有優勢

2、服務化時代框架 （過時）

Dubbo:提供高性能和透明化的RPC遠程服務調用，包含基本服務監控、服務治理和服務調度能力

默認採用傳輸Hessian序列化數據，Dubbo採用ZooKeeper作為註冊中心來註冊和發現服務。

並通過客戶端負載均衡來路由請求，算法包括：隨機、輪詢、最少活躍調用數、一致性hash等。

HSF:淘寶內部大規模使用，不開源。

Thrift: 高性能支持多語言服務調用框架，Apache開源，具有跨語言和高性能優點。

AXIS: Apache Web Service項目，採用SOAP協議

Mule ESB:

3、微服務框架

1）Spring Boot

a、JEE時代

Tomcat Web容器服務管理服務的啟動、停止、監控、配置和日誌，應用人員按照規範打包War

b、Spring Boot,將容器嵌入自動的Jar包中。Spring Boot啟動時，內部啟動嵌入的容器，例如Tomcat,Jetty,Nettry等。

2、Spring Clound Netfix

包含組件Eureka、容錯性組件Hystrix、智能路由組件Zuul和客戶端負載均衡組件Ribbon

Netflix交互流程

1、服務在Eureka伺服器實例上註冊

2、Zuul作為特殊服務在Eureka註冊並發現服務

3、Zuul作為網關，將發現服務給PC網站、APP和開放平臺使用

4、RestTemplate和FergnClient使用簡單服務調用方法調用服務1、服務2

相關焦點

  • Spring Cloud微服務——億級流量分布式系統核心架構設計
    Spring Cloud為開發人員提供了於快速構建分布式系統中某些常見模式的工具(例如，配置管理，服務發現，斷路器，智能路由，微代理，控制總線)。分布式系統的協調產生了樣板模式，並且使用Spring雲開發人員可以快速支持實現這些模式的服務和應用程式。它們可以在任何分布式環境中正常工作,包括開發人員自己的筆記本電腦，裸機數據中心和受管理的平臺。
  • 億級流量分布式系統核心架構設計——Spring Cloud微服務
    分布式/版本化配置服務註冊和發現路由服務到服務的呼叫負載均衡斷路器分布式消息傳遞作為新一代的服務框架，Spring Cloud提出的口號是開發「面向雲環境的應用程式」，它為微服務架構提供了更加全面的技術支持。
  • 微服務架構：介紹、分布式集群、架構四要素、設計模式、架構說明
    分布式與集群分布式分布式就是把一個系統拆分成多個服務節點，每個節點部署在不同的伺服器上，可以理解為串聯模式（多個電池串聯起來電壓增加電池容量不變）聚合器微服務設計模式這是一種最常用也最簡單的設計模式，目前學習的微服務系列都是選擇這種設計模式，如下圖所示：
  • 騰訊T4大佬推出，分布式服務架構：原理、設計與實戰.pdf
    分布式、微服務幾乎是現在的技術人員必須要了解的架構方向，從理論上來講確實解稿了很多結構，但另 方面，又會帶來更多衍生的複雜度及難點 如何保證事物的最終 致性？如何進行性能及容量預估？如何處理分布式系統的日誌？如何進行線上應急？如果你 曾有和我樣的困惑，那麼相信你一樣能從本書中得到非常寶貴的解答。
  • SpringCloud:分布式微服務架構
    概念微服務是一種架構風格，它是一種將一個單一應用程式開發為一組小型服務的方法，每個服務運行在自己的進程中，服務間通信採用輕量級通信機制（通常採用http）。特徵每個微服務可獨立運行在自己的進程中。一系列獨立運行的微服務共同構建起整個系統。每個服務為獨立的業務開發，一個微服務只關注某個特定的功能。
  • 太香了這份架構解密：從分布式到微服務（第二版），神仙進階指南
    有這樣一本神奇的架構書讀者可以在字裡行間見證微服務的發展脈絡大到分布式、微服務、雲原生、K8s、Service Mesh小到網絡、分布式系統、RPC、分布式存儲、分布式計算、全文檢索與消息隊列中間件等這就是《架構解密:從分布式到微服務(第2版)》解密架構發展脈絡和梳理原理之旅就等你啦!
  • 華為自爆宇宙級:基於SpringBoot+Cloud微服務分布式架構實戰手冊
    Spring Boot以及Spring Cloud作為現在最火的技術，同時也是面試過程中必然會被問到的點，小編今天開源的這份手冊就是以分布式架構結合微服務實例的方式，介紹Spring Boot+Spring Cloud的基礎知識、架構順序和操作方法。
  • JAVA高級開發-微服務架構下的分布式數據管理
    1.2 分布式數據管理之舉措在介紹分布式數據管理（CRUD）解決方案之前，有必要介紹下CAP原理和最終一致性相關概念。1.2.1 CAP原理和最終一致性1.2.1.1 CAP原理(CAP Theorem)在足球比賽裡，一個球員在一場比賽中進三個球，稱之為帽子戲法(Hat-trick)。
  • 20年資深架構師整理分享架構解密：從分布式到微服務第2版文檔
    前言本文凝聚了作者多年架構經驗，內容覆蓋網絡、分布式、微服務、存儲、計算等。深入淺出地講解了雲原生、Kubernetes和Service Mesh等熱門技術，並詳細剖析其原理，值得每個IT人士閱讀。不論你是有十幾年研發經驗及架構經驗的IT老手，還是剛入門系統架構的IT新手，本文都能對你理解分布式架構和微服務架構大有助益。
  • 阿里P8技術官總結698頁：分布式服務架構 原理+設計+實戰
    ，側重於講解高可用架構設計的核心要點:可伸縮和可擴展，從應用層、資料庫、緩存、消息隊列、大數據查詢系統、分布式定時任務調度系統、微服務等層面詳細講解如何設計可伸縮、可擴展的框架，並給出在各個領域解決特定問題的方法論和實踐總結。
  • ...模塊化、集中式、分布式、服務化、面向服務的架構、微服務架構
    集中式與分布式 　　要談微服務，那麼必須建立在分布式的基礎上，對於一個集中式系統也無需談微服務。並不是所有的SOA架構都需要ESB，ESB是SCA特有的。當然任何符合ESB特徵的解決方式都可以稱之為ESB，也不僅僅是SCA內部的。 　　因此，我們可以認為Echo並不太符合SOA的基本設計原則。
  • Github標星67.9k的微服務架構以及架構設計模式筆記我粉了
    最後，一般提到微服務都離不開DevOps和Docker，理解微服務架構是核心，devops和docker是工具，是手段。下面就一起通過兩份文檔來深入了解微服務架構與它的設計模式，如果各位大佬對微服務架構有什麼獨特的見解歡迎在評論區留言指正。
  • 架構師社區爆火的分布式微服務神仙筆記究竟有什麼魅力？
    微服務是架構設計方式，分布式是系統部署方式，兩者概念不同微服務是指很小的服務，可以小到只完成一個功能，這個服務可以單獨部署運行，不同服務之間通過rpc調用。兩者的關係是，系統應用部署在超過一臺伺服器或虛擬機上，且各分開部署的部分彼此通過各種通訊協議交互信息，就可算作分布式部署，生產環境下的微服務肯定是分布式部署的，分布式部署的應用不一定是微服務架構的，比如集群部署，它是把相同應用複製到不同伺服器上，但是邏輯功能上還是單體應用。總的來說:分布式一個服務可以提供一個或多個功能，微服務一個服務只提供一個功能。
  • Java高並發高性能分布式框架從無到有微服務架構設計
    微服務架構模式（Microservice Architect Pattern）。近兩年在服務的瘋狂增長與雲計算技術的進步，讓微服務架構受到重點關注微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。
  • 微服務是不是金科玉律？基於Spring Cloud如何構建分布式系統？
    微服務架構因為分布式非常複雜，所以一直以來都沒有權威的架構和設計,更多的只是前人的積累和實踐。前人總結出了許多有用的理念，積累了許多經驗，開發了很多實施分布式的軟體。微服務是一種特殊的分布式， 換句話說，微服務架構是分布式服務架構的子集。微服務架構通過更細粒度的服務切分，使得整個系統的迭代速度並行程度更高,但是運維的複雜度和性能會隨著服務的粒度更細而增加。微服務重在解耦合,使每個模塊都獨立。分布式重在資源共享與加快計算機計算速度。
  • 從分布式到微服務成長手冊，助我面試跳槽斬獲字節Offer
    分布式架構和微服務架構是網際網路架構的核心。我們通常理解分布式架構都是從常用的分布式軟體開始的，比如Spring Cloud、Kafka、 ZooKeeper、 HBase等，這些都離不開分布式網絡架構、分布式存儲和分布式計算等基礎理論。
  • 漫談Serverless、微服務、分布式和單體四種主流軟體架構
    漫談Serverless、微服務、分布式和單體四種主流軟體架構 如果一個軟體開發人員，不了解軟體架構的演進，會制約技術的選型和開發人員的生存、晉升空間。這裡我列舉了目前主要的四種軟體架構以及他們的優缺點，希望能夠幫助軟體開發人員拓展知識面。
  • 微服務分布式架構中，如何實現日誌鏈路跟蹤？
    ，這樣就很好的可以排查整個微服務的日誌鏈路，謝謝！！！10、不說「分布式事務」理論，直接上大廠阿里的解決方案，絕對實用11、女程式設計師問到這個問題，讓我思考了半天，Mysql的「三高」架構12、大廠二面：CAP原則為什麼只能滿足其中兩項？
  • 微服務架構下的分布式限流方案思考
    技術乾貨，第一時間推送1.微服務限流隨著微服務的流行，服務和服務之間的穩定性變得越來越重要。緩存、降級和限流是保護微服務系統運行穩定性的三大利器。比如當我們設計了一個函數，準備上線，這時候這個函數會消耗一些資源，處理上限是1秒服務3000個QPS，但如果實際情況遇到高於3000的QPS該如何解決呢？所以限流的目的應當是通過對並發訪問/請求進行限速或者一個時間窗口內的的請求進行限速來保護系統，一旦達到限制速率就可以拒絕服務、等待、降級。
  • 阿里微服務布道師：詳解微服務架構設計
    （設計系統的組織，其產生的設計和架構等價於組織間的溝通結構。)微服務也指一種種鬆耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那麼它們就不是微服務，因為它們緊耦合在一起；如果你需要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。