微服務(wù)

微服務(wù)的意義

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

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

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

    實(shí)際上，所謂的 微服務(wù)框架，是一種錯(cuò)誤的說法，微服務(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) 和 注冊(cè)中心。但是實(shí)際上，這僅僅是工具，真正的微服務(wù)，最核心的其實(shí)是 如何做好服務(wù)間的最小粒度切分，其實(shí)這個(gè) 服務(wù)切分 是屬于架構(gòu)規(guī)劃上的范疇。

服務(wù)限流

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

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

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

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

如何限流

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

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

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

熔斷保護(hù)

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

服務(wù)降級(jí)

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

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

延遲處理

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

特權(quán)處理

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