微服務(wù)

微服務(wù)的意義

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

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

什么是微服務(wù)框架

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

服務(wù)限流

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

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

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

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

如何限流

在實(shí)際的應(yīng)用當(dāng)中，流量入口應(yīng)該是：

防火墻 --> API 網(wǎng)關(guān)  -> 服務(wù)

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

熔斷保護(hù)

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

服務(wù)降級

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

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

延遲處理

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

特權(quán)處理

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