微服務

微服務的意義

    例如我們在開發(fā)一個基礎的商場系統(tǒng)時，可能分為 用戶模塊、商品模塊、訂單模塊、活動模塊 等，系統(tǒng)建設初期，我們也許為了快速上線和節(jié)約成本，那么就會采用直接把一整套的模塊代碼，全部寫在一個項目代碼中。 而在后期流量上來后，我們會發(fā)現(xiàn)，經(jīng)常因為某個模塊的的功能模塊失效，導致整個服務癱瘓。例如 活動模塊 和 商品模塊 是最容易在高流量下癱瘓的模塊。 舉個例子，在 2018 年的雙十一活動中，某商場系統(tǒng)花了很多錢去做廣告，導致很高流量直接進入到商場系統(tǒng)當中，而在此之前，也沒做服務拆分，那么 活動模塊 的高流量導致 數(shù)據(jù)庫 和 帶寬 完全無法支撐，最終整個商場系統(tǒng)全部進入黑洞狀態(tài)，用戶既無法進入活動頁面，就連正常的商場首頁也無法打開。 后面，在 EasySwoole 項目組 的建議下，將商場系統(tǒng)進行了 模塊化服務拆分，例如，活動系統(tǒng) 就是一個獨立的服務，用戶參與活動的時候，直接從客戶端調(diào)用活動服務接口，活動服務需要驗證商品和用戶數(shù)據(jù)的時候，又通過 RPC 調(diào)用 進行服務間的數(shù)據(jù)交互。 從而實現(xiàn)壓力的分攤，不再讓全部的服務壓力都堆積到 單臺服務器 或 數(shù)據(jù)庫 上，且在最糟糕的情況下，即使活動模塊癱瘓，也不會導致整個商場系統(tǒng)不可用。

因此微服務的主要意義在于：流量分壓、模塊高度自治、服務隔離保護。

什么是微服務框架

    實際上，所謂的 微服務框架，是一種錯誤的說法，微服務是一種架構(gòu)性上的概念，與框架無關。例如，在上述的案例當中，我們服務間的互相調(diào)用，可以用 HTTP 協(xié)議 或者是 原生 TCP 協(xié)議 來實現(xiàn)，因此實際上，微服務和框架沒有一點關系。而如果真的要牽強地說是微服務框架的話，那其實無非是類似某些框架做了一些組件的封裝，讓你更加方便的實現(xiàn) RPC 調(diào)用。例如 EasySwoole 就提供了 RPC 封裝、基礎的服務發(fā)現(xiàn) 和 注冊中心。但是實際上，這僅僅是工具，真正的微服務，最核心的其實是 如何做好服務間的最小粒度切分，其實這個 服務切分 是屬于架構(gòu)規(guī)劃上的范疇。

服務限流

再舉一個我們生活中的例子：一些熱門的旅游景點，往往會對每日的旅游參觀人數(shù)有嚴格的限制，比如廈門的鼓浪嶼、北京的故宮等，每天只會賣出固定數(shù)目的門票，如果你去的晚了，可能當天的票就已經(jīng)賣完了，當天就無法進去游玩了。 為什么旅游景點要做這樣的限制呢？多賣一些門票多賺一些錢豈不是更好？

其實對于旅游景點而言，他們也很無奈，因為景點的服務資源有限，每日能服務的人數(shù)是有限的，一旦放開限制了，景點的工作人員就會不夠用，衛(wèi)生情況也得不到保障，安全也有隱患，超密集的人群也會嚴重影響游客的體驗。 但由于景區(qū)名氣大，來游玩的旅客絡繹不絕，遠超出了景區(qū)的承載能力，因此景區(qū)只好做出限制每日人員流量的舉措。

同理，在 IT 軟件行業(yè)中，系統(tǒng)服務也是這樣的。如果你的系統(tǒng)理論上單位時間內(nèi)可服務 100W 用戶，但是今天卻突然來了 300W 用戶，由于用戶流量的隨機性，如果不加以限流，很有可能這 300W 用戶一下子就壓垮了系統(tǒng)，導致所有人都得不到服務。 因此為了保證系統(tǒng)至少還能為 100W 用戶提供正常服務，我們需要對系統(tǒng)進行限流設計。

有的人可能會想，既然會有 300W 用戶來訪問，那么為什么系統(tǒng)不干脆設計成能足以支撐這么大用戶量的集群呢？ 這是個好問題。如果系統(tǒng)是長期有 300W 的用戶來訪問，肯定是要做上述升級的，但是常常面臨的情況是，系統(tǒng)的日常訪問量就是 100W，只不過偶爾由于一些不可預知的特定原因?qū)е碌亩虝r間的流量激增，這個時候，公司往往出于節(jié)約成本的考慮，不會為了一個不常見的尖峰來把我們的系統(tǒng)擴容到最大的尺寸。

如何限流

在實際的應用當中，流量入口應該是：

防火墻 --> API 網(wǎng)關  -> 服務

因此，實際上我們是有三個地方可以進行限流。那么，防火墻 和 API 網(wǎng)關 我們則不再進行講解，那是運維做的事情。我們要說的是 API 網(wǎng)關 的自我保護。在 EasySwoole 中，有提供了一個基礎的 AtomicLimit 組件，原理與令牌桶差不多，有興趣的同學可以去看下。當然 EasySwoole 也支持其他方式的限流，你可以在流量入口的 onRequest 方法中進行攔截。

熔斷保護

這個模式是需要系統(tǒng)在設計之初，就要把 熔斷措施 考慮進去。當系統(tǒng)出現(xiàn)問題時，如果短時間內(nèi)無法修復，系統(tǒng)要自動做出判斷，開啟熔斷開關，拒絕流量訪問，避免大流量對后端的過載請求。系統(tǒng)也應該能夠動態(tài)監(jiān)測后端程序的修復情況，當程序已恢復穩(wěn)定時，可以關閉熔斷開關，恢復正常服務。

服務降級

將系統(tǒng)的所有功能服務進行一個分級，當系統(tǒng)出現(xiàn)問題，需要緊急限流時，可將不是那么重要的功能進行降級處理，停止服務，這樣可以釋放出更多的資源提供給核心功能去使用。

例如在電商平臺中，如果突發(fā)流量激增，可臨時將商品評論、積分等非核心功能進行降級，停止這些服務，釋放出機器和 CPU 等資源來保障用戶正常下單，而這些降級的功能服務可以等整個系統(tǒng)恢復正常后，再來啟動，進行補單/補償處理。 除了功能降級以外，還可以采用不直接操作數(shù)據(jù)庫，而全部讀緩存、寫緩存的方式作為臨時降級方案。

延遲處理

這個模式需要在系統(tǒng)的前端設置一個流量緩沖池，將所有的請求全部緩沖進這個池子，不立即處理。然后后端真正的業(yè)務處理程序從這個池子中取出請求依次處理，常見的可以用隊列模式來實現(xiàn)。這就相當于用異步的方式去減少了后端的處理壓力，但是當流量較大時，后端的處理能力有限，緩沖池里的請求可能處理不及時，會有一定程度延遲。

特權(quán)處理

這個模式需要將用戶進行分類，通過預設的分類，讓系統(tǒng)優(yōu)先處理需要高保障的用戶群體，其它用戶群體的請求就會延遲處理或者直接不處理。