14、服務化：微服務架構，究竟解決什么問題？

• no14：在服務化前后的互聯網的常見架構示意圖
  • 服務化前
  • 服務化后
• no14：沒有服務化前的痛點
  • 1.代碼到處拷貝
  • 2.底層復雜性擴散
  • 3.公共庫耦合
  • 4.SQL 質量無法保障
  • 5.不易擴展，數據庫耦合
• no14：服務化的好處
  • 1.復用性，消除代碼拷貝
  • 2.專注性，防止復雜性擴散
  • 3.解耦合，消除公共庫耦合
  • 4.高質量，SQL 穩定性有保障
  • 5.易擴展，消除數據庫解耦合
  • 6.(最重要)高效，對業務調用方的研發效率提升了
• no14：服務化后的潛在問題有哪些？
  • 1.系統復雜性上升
  • 2.層次間依賴關系變得復雜
  • 3.運維，部署更麻煩
  • 4.監控變得更復雜
  • 5.定位問題更麻煩

15、服務化：微服務架構，粒度多少合適？

• no15：微服務化架構粒度拆分實踐一：統一服務層
  • 業務不是特別復雜的時候，統一整個服務層，所有數據都通過一個統一的服務層來進行訪問
  • 缺點：一旦代碼出故障，就將影響整個服務
• no15：微服務化架構粒度拆分實踐二：一個子業務一個服務(最佳實踐)
  • 在服務層進行垂直拆分，一個子業務抽象出一個服務，數據層也按照子業務垂直拆分
  • 當業務連接關系變得復雜時，加入網關分發層來消除這個網狀關系，并在協議設計的時候加入一個協議號服務號，分發層通過協議號服務號將請求路由到相關的子業務服務
• no15：微服務化架構粒度拆分實踐三：一個數據庫一個服務
• no15：微服務化架構粒度拆分實踐四：一個接口一個服務
  • 需要語言特性的支持，如 go 可以這么使用
• no15：微服務化架構拆成細粒度優缺點
  • 優點
    • 服務能夠獨立部署，擴容縮容相對方便
    • 能更有效地提高資源利用率
    • 耦合度相對減小
    • 容錯性相對更好
    • 擴展性也會更好
  • 缺點
    • 服務數量變多
    • 系統復雜性增加
    • 依賴關系復雜性增加
    • 運維復雜性增加
    • 監控更復雜
    • 定位問題更復雜

16、服務化：微服務架構，必須搞定高可用！

• no16：高可用是什么？
  • 減少系統不能提供服務的時間
• no16：如何判斷是否高可用？
  • 隨機關停一臺線上服務器，如果對用戶的服務不受影響，那么系統就是高可用的
• no16：如何保障系統的高可用
  • 1.集群化(冗余)
  • 2.故障自動轉移
• no16：常見微服務分層架構？
• no16：微服務分層架構如何保證「端」到「反向代理」的高可用
  • 通過 keepalived + 虛 IP 來實現
• no16：微服務分層架構如何保證「反向代理」到「站點應用」的高可用
  • 通過站點層的冗余來實現
• no16：微服務分層架構如何保證「站點應用」到「微服務」的高可用
  • 通過服務層的冗余來實現，上游有服務連接池
• no16：微服務分層架構如何保證「微服務」到「緩存」的高可用(memcache)
• no16：微服務分層架構如何保證「微服務」到「緩存」的高可用(redis)
  • 但很多時候緩存不需要保證高可用，只要不「雪崩」壓垮數據庫就行
    • 將緩存進行水平切分，這也是個集群，但只是用來做分片，并不做數據冗余，在上游設置代理，即進行完水平切分的入口
• no16：微服務分層架構如何保證「微服務」到「數據庫」的高可用
  • 如果做了讀寫分離，必須保證
  • 「微服務」到「讀庫」的高可用
    • 通過讀庫的冗余化集群實現的
  • 「微服務」到「寫庫」的高可用
    • 通過寫庫的冗余化集群實現的，如 MySQL 可通過設置雙主相互同步

17、服務化：微服務架構，必須搞定高并發！

• no17：什么是高并發？
  • 通過設計方案，保證系統能夠同時并行的處理很多用戶的很多請求
• no17：高并發相關的常見指標有哪些？
  • 1.響應時間(Response Time)
  • 2.吞吐量(Throughput)
  • 3.每秒查詢率 QPS(Query Per Second)
  • 4.并發用戶數
• no17：提升系統并發處理能力的方法論？
  • 1.垂直擴展(Scale Up)
    • 1.提升單機硬件性能
    • 2.提升單機架構性能
    • 業務早期建議使用，因為速度最快
  • 2.水平擴展(Scale Out)
• no17：常見微服務分層架構
  • 要想做到整體的性能無限，就必須做到每一層都能夠實現水平擴展性能無限
• no17：常見微服務分層架構的反向代理層的水平擴展
  • 之前都是通過 lvs 和 f5 的垂直擴展的方式，這都是有性能上限的，反向代理的水平擴展是通過 DNS 輪詢實現的，DNS server 對于同一個域名配置不同的 nginx 外網 IP
• no17：常見微服務分層架構的站點應用層的水平擴展
  • 通過反向代理層實現
• no17：常見微服務分層架構的微服務的水平擴展
  • 通過服務連接池去實現的，站點層通過 rpc client 調用下層的服務層 rpc server，rpc client 會建立多個服務連接，當服務稱為瓶頸的時候，只要增加服務節點的數量，rpc client 會建立新的連接
• no17：常見微服務分層架構的數據層(緩存，數據庫)的水平擴展
  • 需求
    • 1.存儲容量的擴展，無限容量
    • 2.處理能力的擴展，無限讀性能，無限寫性能
  • 根據數據的范圍水平切分
    • 優點
      • 規則簡單
      • 數據的均衡性比較好
      • 容易擴展
    • 缺點
      • 雖然保證數據層是均衡的，但讀寫請求不一定是均衡的
  • 按照哈希水平切分
    • 優點
      • 規則簡單
      • 數據均衡性非常好
      • 請求均衡性非常好
    • 缺點
      • 不容易擴展，擴展可能需要進行數據遷移

18、服務化：微服務架構，必須搞定負載均衡！

• no18：什么是負載均衡
  • 將請求或者數據均勻地分攤到多個操作單元上執行
    • 1.同構，重點在于「均勻」
    • 2.異構，重點在于「負載與能力匹配」
• no18：常見微服務分層架構，保證負載均衡的思路
  • 實現每個上游都實現對下游的均勻訪問，即可實現系統整體的均勻分攤
• no18：常見微服務分層架構，反向代理層的負載均衡
  • DNS 服務器使用 DNS 輪詢的方式，即可實現 Nginx 的負載均衡
• no18：常見微服務分層架構，站點應用層的負載均衡
  • nginx 使用輪詢的方式，將請求路由到多個站點應用的后端
• no18：常見微服務分層架構，微服務的負載均衡
  • 通過連接池實現的，可使用隨機或輪詢等方式保證多個微服務的下游的請求是均勻的
• no18：常見微服務分層架構，數據層(緩存，數據庫)的負載均衡
  • 1.數據，均衡
  • 2.請求，均衡
  • 按照數據范圍水平切分
    • 數據負載是均衡的，水平負載未必均衡，如新用戶可能更活躍
  • 哈希水平切分
    • 數據、請求的負載都比較均衡，同構節點的服務器的均衡比較容易
• no18：常見微服務分層架構，異構服務器負載均衡，方案一：靜態權重
  • 為下游每個微服務節點設置一個靜態權重，表示微服務的處理能力，來調配連接池
  • 優點
    • 簡單粗暴
  • 缺點
    • 無法自適應地去調節
• no18：常見微服務分層架構，異構服務器負載均衡，方案二：動態權重
  • 1.如何標識服務的處理能力？(下游的處理能力是由調用方決定的)
  • 2.如何設計動態權重？
  • 對每一個微服務的連接使用一個權重來標識，這個權重決定分配給每個微服務請求的概率，獲得相應連接的概率，當下游每成功處理一個請求的時候，就認為下游的微服務的處理能力足夠，增加權重(緩慢)，當微服務超時處理一個請求的時候，就認為下游的處理能力，可能要跟不上了，權重就減少(快速)
  • 可把權重的范圍設置為[0，100]之間，初始值設置為 60，
• no18：什么是過載保護？
  • 如果不對微服務實施過載保護，隨著上游的負載越來越高，在微服務的處理能力范圍內，每秒處理的請求是越來越高的
  • 但是達到一個負載的極限時，外部負載持續的增加，它的處理能力會掉底，瞬間降為 0，即「雪崩」
  • 如果實施了過載保護，那么隨著外部負載的增加，處理能力到達一個 max 值后，會保持相對穩定的一個值，系統不會被完全壓垮
• no18：如何實施過載保護？
  • 1.靜態權重(粗暴，不優雅)
    • 給微服務的處理能力設置一個閾值，如果負載超過這個閾值，就將后續的請求全部拋棄
  • 2.動態權重
    • 1.連接表示服務，分值代表服務(連接)
    • 2.處理成功加小分，處理失敗扣大分
    • 3.到達臨界編譯時，如有請求超時的時候，可判斷快要處理不過來了，讓它有請求處理失敗的時候休息一會，再接下來 10 秒內不再給這個超時的服務器進行負載分配
    • 4.如果仍然連續地超時，可能判定這個服務器完全處理不過來了，如 fullGC，根據經驗，fullGC 差不多一分鐘之后能回過神，則一分鐘后給它分配請求
    • 但如果整體負載超過了微服務集群的整體負載，最終還是要拋棄部分請求

20、服務化：連接池，高可用可擴展負載均衡都離不開他

• no20：微服務分層架構中，連接池的位置
• no20：高可用，故障轉移，在連接池中是如何實現的？
  • 當有節點失效時，連接池重試也連接不上，則連接池會把失敗的連接剔除出去
• no20：擴展性，服務發現，在連接池的實現
  • 1.自動載入新服務節點的配置
    • 方案一：監控配置文件，并重新載入
      • 具體實現可以是啟動一個進程，監控文件變化，循環檢測文件 md5是否變化，如果變化則讀取新服務節點的配置
    • 方案二：配置中心回調，并重新載入
      • 每當調用方站點集群向配置中心注冊了下游所依賴的微服務集群的配置，如果微服務集群的節點發生了變化配置中心會給調用方的站點集群進行回調，會將變化后的節點通知站點集群，再實施連接池自動增刪節點
  • 2.動態連接池
• no20：負載均衡，連接池的實現的三個方案
  • 方案一：隨機/輪詢(同構服務器)
  • 方案二：靜態權重法(異構服務器)
  • 方案二：動態權重法(異構服務器)

總結

以上是生活随笔為你收集整理的《沈剑架构师训练营》第4章 - 微服务架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。