微服務

微服務的意義

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

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

什么是微服務框架

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

服務限流

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

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

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

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

如何限流

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

防火墻 --> API 網關  -> 服務

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

熔斷保護

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

服務降級

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

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

延遲處理

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

特權處理

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