SpringCloud 微服務(wù)(架構(gòu)篇)

SpringCloud 微服務(wù)(架構(gòu)篇)

軟件架構(gòu)的進化

什么是軟件架構(gòu)

  • 軟件架構(gòu)是在軟件的內(nèi)部，經(jīng)過<mark>綜合各種因素</mark>的考量、權(quán)衡，<mark>選擇特定的技術(shù)</mark>，將系統(tǒng)<mark>劃分成不同的部分</mark>并使這些部分相互分工，彼此協(xié)作，為用戶提供需要的價值

有哪些因素

  • 業(yè)務(wù)需求
  • 技術(shù)棧
  • 成本
  • 組織架構(gòu)
  • 可擴展性
  • 可維護性

架構(gòu)演進

image
  • 單一應(yīng)用架構(gòu)
    image
  • 垂直應(yīng)用架構(gòu)
    image
  • 分布式服務(wù)架構(gòu)
    image
  • 流動計算架構(gòu)
    image

單體架構(gòu)

  • 優(yōu)點
    • 容易測試
    • 容易部署
  • 缺點
    • 開發(fā)效率低
    • 代碼維護難
    • 部署不靈活
    • 穩(wěn)定性不高
    • 擴展性不強

分布式定義

  • 旨在支持應(yīng)用程序和服務(wù)的開發(fā)，可以利用物理架構(gòu)，由多個自治的處理元素，不共享主內(nèi)存，但通過網(wǎng)絡(luò)發(fā)送消息合作

什么是微服務(wù)

  • 在此引用 ThoughtWorks 公司的首席科學(xué)家 Martin Fowler 的一段話：
  • In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
  • 谷歌翻譯如下：
    • 簡而言之，微服務(wù)<mark>架構(gòu)風格</mark>是一種將單個應(yīng)用程序作為<mark>一套小型服務(wù)開發(fā)</mark>的方法，每種應(yīng)用程序都在<mark>自己的進程</mark>中運行，并與<mark>輕量級機制</mark>（通常是HTTP資源API）進行通信。 這些服務(wù)是<mark>圍繞業(yè)務(wù)功能</mark>構(gòu)建的，可以通過全自動部署機制<mark>獨立部署</mark>。 這些服務(wù)的集中管理最少，可以用不<mark>同的編程語言</mark>編寫，并使用<mark>不同的數(shù)據(jù)存儲</mark>技術(shù)。
  • 微服務(wù)是一種架構(gòu)風格
  • 一系列微小的服務(wù)共同組成
  • 跑在自己的進程里
  • 每個服務(wù)為獨立的業(yè)務(wù)開發(fā)
  • 獨立部署
  • 獨立數(shù)據(jù)
  • 服務(wù)間可以是不同語言

微服務(wù)的特征

  • 單一職責
  • 輕量級通訊
  • 隔離性
  • 有自己的數(shù)據(jù)
  • 技術(shù)多樣性

微服務(wù)興起的原因

  • 互聯(lián)網(wǎng)行業(yè)的快速發(fā)展
  • 敏捷開發(fā)，精益方式深入人心
  • 容器技術(shù)的成熟

微服務(wù)架構(gòu)的優(yōu)勢和不足

  • 優(yōu)勢
    • 獨立性
    • 敏捷性
    • 技術(shù)棧靈活
    • 高效團隊
  • 不足
    • 額外的工作（DDD【Domain-Driven Design 領(lǐng)域驅(qū)動設(shè)計】可以做微服務(wù)拆分的學(xué)習(xí)）
    • 數(shù)據(jù)一致性
    • 溝通成本

微服務(wù)如何拆分

微服務(wù)拆分的起點

  • 起點

    • 既有架構(gòu)的形態(tài)

  • 終點

    • 好的架構(gòu)不是設(shè)計出來的，而是進化出來的
    • 一直在演進ing

適合上微服務(wù)么？

  • 業(yè)務(wù)形態(tài)不適合的
    • 系統(tǒng)中包含很多很多強事務(wù)場景的
    • 業(yè)務(wù)相對穩(wěn)定，迭代周期長
    • 訪問壓力不大，可用性要求不高
    • ...

康威定律和微服務(wù)

  • 傳統(tǒng)和微服務(wù)


    傳統(tǒng)和微服務(wù)

  • 康威定律

    • 任何組織在設(shè)計一套系統(tǒng)(廣義概念上的系統(tǒng))時，所交付的設(shè)計方案在結(jié)構(gòu)上都與該組織的溝通結(jié)構(gòu)保持一致
    • 溝通的問題會影響系統(tǒng)的設(shè)計

    所以，上不上微服務(wù)已經(jīng)不是使用某個技術(shù)棧的技術(shù)問題了，已經(jīng)上升到一個團隊結(jié)構(gòu)有關(guān)的管理問題了

服務(wù)拆分的方法論

擴展立方模型（Scale Cube）

image
X軸 水平復(fù)制
  • 通過將應(yīng)用程序水平復(fù)制，通過負載均衡運行多個完全一樣的副本，來實現(xiàn)應(yīng)用程序的伸縮性，提高應(yīng)用程序的容量和可用度
Z軸 數(shù)據(jù)分區(qū)
  • 每個服務(wù)器負責的一個數(shù)據(jù)子集，每個服務(wù)器運行的代碼是一樣的
Y軸 功能解耦
  • 將不同職等的模塊分成不同的服務(wù)

如何拆“功能”

  • 單一職責，松耦合、高內(nèi)聚
  • 關(guān)注點分離
    • 按職責
    • 按通用性
    • 按粒度級別

服務(wù)和數(shù)據(jù)的關(guān)系

  • 先考慮業(yè)務(wù)功能，再考慮數(shù)據(jù)
  • 無狀態(tài)服務(wù)
    image

如何拆"數(shù)據(jù)"

  • 每個微服務(wù)都有單獨的數(shù)據(jù)存儲
  • 依據(jù)服務(wù)特點選擇不同結(jié)構(gòu)的數(shù)據(jù)庫類型
  • 難點在于確定邊界
    • 針對邊界設(shè)計API
    • 依據(jù)邊界權(quán)衡數(shù)據(jù)冗余

微服務(wù)核心組件

微服務(wù)帶來的問題

  • 微服務(wù)間如何發(fā)現(xiàn)彼此
  • 服務(wù)間如何通訊
  • 微服務(wù)容錯處理
  • 微服務(wù)的配置問題

SpringCloud核心組件

  • Eureka(注冊中心)
  • Ribbon(負載均衡)
  • Hystrix(斷路器)
  • Zuul(服務(wù)網(wǎng)關(guān))
  • Config(配置中心)

Eureka(注冊中心)

  • 在分布式系統(tǒng)里，必須要有一個角色對所有微服務(wù)的狀態(tài)、地址、及實例數(shù)進行集中管理和收集，并能定期的監(jiān)控所有微服務(wù)的狀態(tài)，這就是Eureka，能提供服務(wù)注冊和注冊中心功能


    image
  • 兩個組件組成
    • Eureka Server 注冊中心
    • Eureka Client 服務(wù)注冊
      • 服務(wù)端發(fā)現(xiàn)和客戶端發(fā)現(xiàn)
        image

Ribbon(負載均衡)

  • Ribbon是SpringCloudNetfilix微服務(wù)套件中的一部分，提供負責均衡、容錯、異步和多協(xié)議(HTTP,TCP,UDP)支持、緩存、批處理功能 .


    image

Hystrix(斷路器)

  • 在一個分布式系統(tǒng)里，許多依賴不可避免的會調(diào)用失敗，比如超時、異常等，如何能夠保證在一個依賴出問題的情況下，不會導(dǎo)致整體服務(wù)失敗，這個就是Hystrix需要做的事情。Hystrix提供了熔斷、隔離、Fallback、cache、監(jiān)控等功能，能夠在一個、或多個依賴同時出現(xiàn)問題時保證系統(tǒng)依然可用。
image
  • 熔斷
    • 當Hystrix Command請求后端服務(wù)失敗數(shù)量超過一定比例(默認50%), 斷路器會切換到開路狀態(tài)(Open). 這時所有請求會直接失敗而不會發(fā)送到后端服務(wù).
  • 斷路器保持在開路狀態(tài)一段時間后(默認5秒), 自動切換到半開路狀態(tài)(HALF-OPEN). 這時會判斷下一次請求的返回情況,如果請求成功, 斷路器切回閉路狀態(tài)(CLOSED), 否則重新切換到開路狀態(tài)(OPEN).
  • Hystrix的斷路器就像我們家庭電路中的保險絲, 一旦后端服務(wù)不可用, 斷路器會直接切斷請求鏈, 避免發(fā)送大量無效請求影響系統(tǒng)吞吐量, 并且斷路器有自我檢測并恢復(fù)的能力.
  • 隔離
    • 在Hystrix中, 主要通過線程池來實現(xiàn)資源隔離. 通常在使用的時候我們會根據(jù)調(diào)用的遠程服務(wù)劃分出多個線程池.
      • image
  • Fallback
    • Fallback相當于是降級操作. 對于查詢操作, 我們可以實現(xiàn)一個fallback方法, 當請求后端服務(wù)出現(xiàn)異常的時候, 可以使用fallback方法返回的值. fallback方法的返回值一般是設(shè)置的默認值或者來自緩存.告知后面的請求服務(wù)不可用了，不要再來了。
  • cahce
    • 比如一個請求過來請求我userId=1的數(shù)據(jù)，你后面的請求也過來請求同樣的數(shù)據(jù)，這時我不會繼續(xù)走原來的那條請求鏈路了，而是把第一次請求緩存過了，把第一次的請求結(jié)果返回給后面的請求。
  • 監(jiān)控
    • HyStrix自身提供了監(jiān)控系統(tǒng)，可以對接口狀態(tài)進行監(jiān)控，但是實時性的，沒有持久化存儲，我們后期是可以用第三方系統(tǒng)監(jiān)控數(shù)據(jù)的采集與報警

Zuul(服務(wù)網(wǎng)關(guān))

  • API網(wǎng)關(guān)可以提供一個單獨且統(tǒng)一的API入口用于訪問內(nèi)部一個或多個API。簡單來說嘛就是一個統(tǒng)一入口，比如現(xiàn)在的支付寶或者微信的相關(guān)api服務(wù)一樣，都有一個統(tǒng)一的api地址，統(tǒng)一的請求參數(shù)，統(tǒng)一的鑒權(quán)。
服務(wù)網(wǎng)關(guān)

服務(wù)網(wǎng)關(guān)

  • Zuul的核心一系列的過濾器：
    • 身份認證與安全：識別每個資源的驗證要求，并拒絕那些與要求不符的請求。
    • 審查與監(jiān)控：在邊緣位置追蹤有意義的數(shù)據(jù)和統(tǒng)計結(jié)果，從而帶來精確的生產(chǎn)視圖。
    • 動態(tài)路由：動態(tài)地將請求路由到不同的后端集群。
    • 壓力測試：逐漸增加指向集群的流量，以了解性能。
    • 負載分配：為每一種負載類型分配對應(yīng)容量，并啟用超出限定值的請求。
    • 靜態(tài)響應(yīng)處理：在邊緣位置直接建立部分相應(yīng)，從而避免其轉(zhuǎn)發(fā)到內(nèi)部集群。

Config(配置中心)

  • 在分布式系統(tǒng)中，由于服務(wù)數(shù)量巨多，為了方便服務(wù)配置文件統(tǒng)一管理，實時更新，所以需要分布式配置中心組件。
    • 核心功能
    • 提供服務(wù)端和客戶端支持
    • 集中管理各環(huán)境的配置文件
    • 配置文件修改之后，可以快速的生效
    • 可以進行版本管理
    • 支持大的并發(fā)查詢
    • 支持各種語言
image
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容