記一篇微服務架構的總結筆記
序言
服務發現是 RPC 框架的核心功能，服務消費者通過精準地址 (IP+PORT) 獲取服務信息，不能滿足微服務常出現的業務重啓、業務更新等頻繁變動的業務場景。服務發現機制通過提供服務標識信息，來獲取服務的精確地址(IP+PORT)，很好的提高了系統的容錯能力和易用性。RPC 作爲解決服務間通信的常用技術手段，通過梳理微服務架構的業務場景，更有利於理解 RPC 功能所解決的業務痛點，建立更立體的業務認知。
微服務架構擁有良好的容錯性、擴展性、技術兼容性、快速開發 / 部署等諸多優點，其所涉及到的軟件棧更是數不勝數。本文從負載均衡、流量管理、測試、版本管理、線上問題跟蹤等幾個角度，做簡單的梳理和總結。
淺述微服務架構
隨着互聯網融入生活的各行各業，網絡直播、雙十一、搶購火車票等，是大家生活中常見的大流量高併發的業務場景，業務邏輯複雜、實時性要求高。以單點部署軟件服務的方式，已無法適應當前的業務需求，分佈式集羣化的部署方式已成爲互聯網業務的主流技術。互聯網業務邏輯相對複雜，微服務架構相對於傳統架構形式，將複雜的業務邏輯拆分成多個擁有獨立功能的微服務，以獨立的功能形式進行部署，獨立的微服務如樂高積木一般，根據自定義規則組合成相應的功能集合。微服務架構是分而治之思想，在當今複雜業務邏輯場景中的實踐。簡而言之，微服務架構之所以成爲互聯網大廠的主流技術，主要由兩個原因：①單臺服務器的計算能力，已遠遠無法滿足大流量的業務訴求，跨地域多機房集羣化部署才能滿足業務的需求；②將所有業務邏輯集成到一個軟件中，技術上不可行，同時也嚴重影響開發效率。結合自身的工作經驗從以下方面介紹相關的技術挑戰：
-
版本兼容：業務功能快速迭代是微服務架構的特點，針對業務場景的定製化功能，同一個服務會同時共存多個業務版本，上下游服務之間需要兼容該類場景。
-
系統測試：微服務架構的業務邏輯複雜，業務調用鏈條長，線上業務流量特徵複雜等特徵。測試環境很難模擬線上真實環境，需要系統擁有精細化的流量管理和調度能力，支持灰色發佈，用於功能及業務性能的驗證。
-
業務性能問題：性能是當今業務系統繞不開的話題，也是在降本增效的大環境下，非常具有吸引力的議題。在電商搜廣推等實時業務場景，性能意味着用戶體驗，對公司來講是真金白銀。微服務架構業務調用鏈條變長，對服務間的通信提出更大的技術挑戰。通信問題是業務系統中的最大的技術挑戰，其涉及到複雜的內核協議棧、硬件、系統調度等多個方面，通信問題也一直是業界熱議的話題。其相關的解決方案也可謂百花齊放，如 DPDK/xdp 旁路內核的軟件方案，也有 RDMA 硬件方案，還有 "軟硬兼施" 的技術方案。
-
線上問題定位：根據問題場景，找到問題觸發條件，確認代碼邏輯漏洞是定位問題的一般邏輯。微服務架構將系統功能拆分成獨立的功能，服務間採用異步的方式進行通信，其調用邏輯複雜。需要從日誌、系統指標、系統跟蹤等多個維度挖掘信息，找到問題現場的調用棧與業務數據。異步程序的定位的難點在於，關聯整個事件完整流程。隨着雲原生技術的發展，集羣規模越來越大，業務邏輯複雜，爲了解決集羣穩定性問題，越來越多的雲廠商研發可觀測性系統，關聯事件流程是其技術落地的關鍵難點。ebpf 作爲 linux kernel 具有革命意義的技術，可編程事件跟蹤機制爲解決集羣複雜問題，提供了強有力的工具支撐。
淺談微服務架構
服務發現的本質是通過資源標識符，來獲取準確的服務信息 (IP+PORT)，起到電話本的作用。在微服務架構中，自動擴縮容、服務重啓、服務銷燬是常見的業務場景，相對於傳統服務器部署方式，IP 和 PORT 是靜態資源，而在微服務架構中這些均是動態變動的。在動態變化的微服務架構環境中，實時感知到服務的運行狀態，縮短服務不可用時延，是服務發現機制的技術難點。
服務發現有兩種場景的實現形式，client-side 和 server-side，彼此的優點就是彼此的缺點，兩者沒有絕對的好壞，需要根據業務的實際需求來選擇具體的技術方案。
-
client-side 服務發現
-
優點：
①客戶端可以感知服務提供者信息，可根據自身需求獲取服務器信息；
②業務請求無需中間轉發層 (如 API 網關)，直接與服務提供者進行交互；
-
缺點：
①對於不同語言版本的客戶端，均需要重新實現相同邏輯，不利於後期功能的統一升級與維護；
②不利於對集羣流量進行精細化管理，如流量染色、流量調度等功能；
-
server-side 服務發現
-
優點：
①向服務消費者提供了中間抽象層，利於功能的橫向擴展和功能的升級；
②有利於對請求流量進行精細化管理，使服務消費者無感知上層業務的調度流程；
③支持跨平臺，跨多種語言特性，向業務提供統一接口，減少業務邏輯的重複開發。
-
缺點：
①增加了中間層，如 API 網關，可能成爲系統性能的瓶頸點；
淺談 RPC
RPC 用於解決兩臺設備之間的通信問題，相對於普通的 socket 編程來講，通常使用 RPC 來實現服務治理，將服務發現、負載均衡、協議序列化的功能封裝到框架內部。讓用戶專注於業務邏輯的開發，降低技術門檻，提高工作效率。
RPC 框架主要由通信、序列化、服務治理三大核心功能組成，通常在服務治理中需要滿足業務的測試功能，需要擁有流量錄製、壓測管理等功能。
-
作爲通信框架有以下技術難點：①支持異步處理機制；②在高併發場景，系統吞吐及響應時延；
-
支持序列化協議：支持不同種類的序列化協議；
-
服務治理：支持在線業務流量錄製；
RPC 框架作爲微服務架構中關鍵技術，每個公司內部使用的框架都有其特製 “配方”，但其出發點均是圍繞着提升軟件穩定性、擴展性及開發效率而展開的。以 BRPC 爲例，其提供的性能分析及壓測功能，其本質圍繞着微服務架構中的痛點問題而展開的。
參考資料：https://middleware.io/blog/service-discovery/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8ZdF3XD2SRsStXxO3urMfQ