微服務
微服務的意義
例如我們在開發一個基礎的商場系統時,可能分為 用戶模塊
、商品模塊
、訂單模塊
、活動模塊
等,系統建設初期,我們也許為了快速上線和節約成本,那么就會采用直接把一整套的模塊代碼,全部寫在一個項目代碼中。
而在后期流量上來后,我們會發現,經常因為某個模塊的的功能模塊失效,導致整個服務癱瘓。例如 活動模塊
和 商品模塊
是最容易在高流量下癱瘓的模塊。
舉個例子,在 2018
年的雙十一活動中,某商場系統花了很多錢去做廣告,導致很高流量直接進入到商場系統當中,而在此之前,也沒做服務拆分,那么 活動模塊
的高流量導致 數據庫
和 帶寬
完全無法支撐,最終整個商場系統全部進入黑洞狀態,用戶既無法進入活動頁面,就連正常的商場首頁也無法打開。
后面,在 EasySwoole 項目組
的建議下,將商場系統進行了 模塊化服務拆分
,例如,活動系統
就是一個獨立的服務,用戶參與活動的時候,直接從客戶端調用活動服務接口,活動服務需要驗證商品和用戶數據的時候,又通過 RPC 調用
進行服務間的數據交互。
從而實現壓力的分攤,不再讓全部的服務壓力都堆積到 單臺服務器
或 數據庫
上,且在最糟糕的情況下,即使活動模塊癱瘓,也不會導致整個商場系統不可用。
因此微服務的主要意義在于:流量分壓
、模塊高度自治
、服務隔離保護
。
什么是微服務框架
實際上,所謂的 微服務框架
,是一種錯誤的說法,微服務是一種架構性上的概念,與框架無關。例如,在上述的案例當中,我們服務間的互相調用,可以用 HTTP 協議
或者是 原生 TCP 協議
來實現,因此實際上,微服務和框架沒有一點關系。而如果真的要牽強地說是微服務框架的話,那其實無非是類似某些框架做了一些組件的封裝,讓你更加方便的實現 RPC 調用
。例如 EasySwoole
就提供了 RPC 封裝
、基礎的服務發現
和 注冊中心
。但是實際上,這僅僅是工具,真正的微服務,最核心的其實是 如何做好服務間的最小粒度切分
,其實這個 服務切分
是屬于架構規劃上的范疇。
服務限流
再舉一個我們生活中的例子:一些熱門的旅游景點,往往會對每日的旅游參觀人數有嚴格的限制,比如廈門的鼓浪嶼、北京的故宮等,每天只會賣出固定數目的門票,如果你去的晚了,可能當天的票就已經賣完了,當天就無法進去游玩了。 為什么旅游景點要做這樣的限制呢?多賣一些門票多賺一些錢豈不是更好?
其實對于旅游景點而言,他們也很無奈,因為景點的服務資源有限,每日能服務的人數是有限的,一旦放開限制了,景點的工作人員就會不夠用,衛生情況也得不到保障,安全也有隱患,超密集的人群也會嚴重影響游客的體驗。 但由于景區名氣大,來游玩的旅客絡繹不絕,遠超出了景區的承載能力,因此景區只好做出限制每日人員流量的舉措。
同理,在 IT
軟件行業中,系統服務也是這樣的。如果你的系統理論上單位時間內可服務 100W
用戶,但是今天卻突然來了 300W
用戶,由于用戶流量的隨機性,如果不加以限流,很有可能這 300W
用戶一下子就壓垮了系統,導致所有人都得不到服務。
因此為了保證系統至少還能為 100W
用戶提供正常服務,我們需要對系統進行限流設計。
有的人可能會想,既然會有 300W
用戶來訪問,那么為什么系統不干脆設計成能足以支撐這么大用戶量的集群呢?
這是個好問題。如果系統是長期有 300W
的用戶來訪問,肯定是要做上述升級的,但是常常面臨的情況是,系統的日常訪問量就是 100W
,只不過偶爾由于一些不可預知的特定原因導致的短時間的流量激增,這個時候,公司往往出于節約成本的考慮,不會為了一個不常見的尖峰來把我們的系統擴容到最大的尺寸。
如何限流
在實際的應用當中,流量入口應該是:
防火墻 --> API 網關 -> 服務
因此,實際上我們是有三個地方可以進行限流。那么,防火墻
和 API 網關
我們則不再進行講解,那是運維做的事情。我們要說的是 API 網關
的自我保護。在 EasySwoole
中,有提供了一個基礎的 AtomicLimit 組件
,原理與令牌桶差不多,有興趣的同學可以去看下。當然 EasySwoole
也支持其他方式的限流,你可以在流量入口的 onRequest
方法中進行攔截。
熔斷保護
這個模式是需要系統在設計之初,就要把 熔斷措施
考慮進去。當系統出現問題時,如果短時間內無法修復,系統要自動做出判斷,開啟熔斷開關,拒絕流量訪問,避免大流量對后端的過載請求。系統也應該能夠動態監測后端程序的修復情況,當程序已恢復穩定時,可以關閉熔斷開關,恢復正常服務。
服務降級
將系統的所有功能服務進行一個分級,當系統出現問題,需要緊急限流時,可將不是那么重要的功能進行降級處理,停止服務,這樣可以釋放出更多的資源提供給核心功能去使用。
例如在電商平臺中,如果突發流量激增,可臨時將商品評論、積分等非核心功能進行降級,停止這些服務,釋放出機器和 CPU
等資源來保障用戶正常下單,而這些降級的功能服務可以等整個系統恢復正常后,再來啟動,進行補單/補償處理。
除了功能降級以外,還可以采用不直接操作數據庫,而全部讀緩存、寫緩存的方式作為臨時降級方案。
延遲處理
這個模式需要在系統的前端設置一個流量緩沖池,將所有的請求全部緩沖進這個池子,不立即處理。然后后端真正的業務處理程序從這個池子中取出請求依次處理,常見的可以用隊列模式來實現。這就相當于用異步的方式去減少了后端的處理壓力,但是當流量較大時,后端的處理能力有限,緩沖池里的請求可能處理不及時,會有一定程度延遲。
特權處理
這個模式需要將用戶進行分類,通過預設的分類,讓系統優先處理需要高保障的用戶群體,其它用戶群體的請求就會延遲處理或者直接不處理。
當然,微服務還有很多東西,本文只是進行基礎的概念科普,具體可以請教架構師。