微服務(wù)架構(gòu)的演進(jìn)

隨著智能手機在移動互聯(lián)網(wǎng)中的快速普及，中國互聯(lián)網(wǎng)中心相關(guān)調(diào)查顯示，通過手機上網(wǎng)的用戶比例已達(dá)到93%以上； 而整個中國的互聯(lián)網(wǎng)普及率也已經(jīng)超過了60%。

因此，我們所處的移動互聯(lián)網(wǎng)時代的發(fā)展呈現(xiàn)出以下特點：

移動互聯(lián)網(wǎng)時代來臨

雖然我們在工作中仍然離不開電腦服務(wù)器運維，但我們使用手機上網(wǎng)的頻率更高了。

由于手機的計算能力有限，手機更多的是用于顯示或顯示內(nèi)容。 大量的函數(shù)計算過程顯然需要依賴云端。 所以我們實際上處于瘦客戶端時代。

隨著我們花在移動互聯(lián)網(wǎng)上的時間急劇增加，也產(chǎn)生了大量的數(shù)據(jù)，尤其是與傳統(tǒng)PC時代相比，增長了幾十倍甚至上百倍。

這些大量的數(shù)據(jù)也需要在云端進(jìn)行處理，所以我們對云服務(wù)的能力也有一定的要求。

硬件技術(shù)日新月異，服務(wù)器性能越來越大。 如今，硬件（尤其是GPU）的處理能力飛速發(fā)展，服務(wù)器的處理能力也得到了飛速的提升。

這就造成了單個應(yīng)用或者單個功能模塊很難消耗掉整個服務(wù)器的資源。 為了提高多臺服務(wù)器的資源利用率，我們需要在同一臺機器上部署多個服務(wù)。

容器技術(shù)興起，輕量級協(xié)議支撐成熟應(yīng)用

在軟件方面，新興技術(shù)包括：容器，以及諸如此類的輕量級協(xié)議加速了我們的開發(fā)和部署效率。

應(yīng)用云化正流行

為了將服務(wù)上云，我們不再需要購買各種機器，而是直接使用云上的各種資源來部署我們的服務(wù)。

這個領(lǐng)域不僅是互聯(lián)網(wǎng)公司的熱點，其他傳統(tǒng)公司，包括一些金融和醫(yī)療公司，也在尋求在云端探索方向。

發(fā)展模式轉(zhuǎn)變

傳統(tǒng)的單體集中式開發(fā)模式是：前端Web→管理系統(tǒng)→數(shù)據(jù)庫→操作系統(tǒng)→底層服務(wù)器。

這種自上而下的“垂直切割”方式必然導(dǎo)致對技術(shù)人才、硬件、網(wǎng)絡(luò)、軟件、技術(shù)的大量需求。

對于初創(chuàng)企業(yè)來說，會存在全能型人才招攬難、開發(fā)復(fù)雜、遷移擴張難、反應(yīng)不快等問題。

因此，我們需要在開發(fā)和運維方面轉(zhuǎn)變思路，通過“橫切”將底層資源和中間平臺分包給IaaS和PaaS平臺，只關(guān)注前端業(yè)務(wù)應(yīng)用。

精細(xì)化運營轉(zhuǎn)型

隨著越來越多的服務(wù)被云端處理，通過各種容器實現(xiàn)快速部署和擴展，我們必須通過細(xì)粒度的運維來實現(xiàn)資源的充分利用。

基于上述移動互聯(lián)網(wǎng)時代的發(fā)展特點，適應(yīng)快速變化需求的微服務(wù)架構(gòu)應(yīng)運而生，同時也催生了.NET的概念。

它是一種敏捷開發(fā)模型架構(gòu)，可以讓我們快速實現(xiàn)：編寫規(guī)劃→編寫代碼→構(gòu)建測試→發(fā)布上線→部署應(yīng)用。

近兩年，微服務(wù)這個詞逐漸成為一個流行詞匯，但它并不是一個新的架構(gòu)，更不是包治百病的架構(gòu)。

那么，微服務(wù)架構(gòu)相比單體架構(gòu)有哪些優(yōu)勢呢？ 這些優(yōu)勢給開發(fā)模式和運維帶來了哪些挑戰(zhàn)？

微服務(wù)架構(gòu)的特點和趨勢

微服務(wù)架構(gòu)的特點和趨勢如下：

為了在與其他微服務(wù)打交道時使用統(tǒng)一的接口，微服務(wù)也進(jìn)行了各種封裝。

另外，當(dāng)多個微服務(wù)共存時，同一個服務(wù)會有多個運行副本，因此具有很高的容錯性。

微服務(wù)架構(gòu)分析

微服務(wù)架構(gòu)分析：

微服務(wù)架構(gòu)的優(yōu)勢

微服務(wù)架構(gòu)具有以下明顯優(yōu)勢：

微服務(wù)架構(gòu)帶來的挑戰(zhàn)

下面談?wù)勗谝胛⒎?wù)架構(gòu)時會遇到的各種挑戰(zhàn)：

微服務(wù)架構(gòu)下的運維思維

以下是我對微服務(wù)架構(gòu)下運維的一些思考：

微服務(wù)架構(gòu)運維解決方案

下面我們以微信為例，說明它在哪些地方使用了微服務(wù)架構(gòu)，然后介紹了我們在微服務(wù)容量管理方面的具體工作，然后分享給大家監(jiān)控部署調(diào)度的參考點，最后討論一下我們的資源利用。 精細(xì)化運營，提質(zhì)增效。

微信為什么要用云端的微服務(wù)？

自2011年誕生以來，微信一直強調(diào)采用快速迭代、試錯、修正的敏捷開發(fā)模式，也就是我們常說的“小步快跑”。

微信里有四大“神器”，分別是：

大系統(tǒng)的小工作，不僅要讓龐大系統(tǒng)中的模塊更加清晰，還要在物理環(huán)境中實現(xiàn)分離獨立部署，快速發(fā)現(xiàn)問題。

比如：一些公共服務(wù)的注冊登錄，LBS的邏輯，微信的搖一搖等，我們把這些邏輯分離了。

為了使一切都具有可擴展性，這里強調(diào)兩個方面：

2013年到2014年，微信微服務(wù)模塊數(shù)量超過5000個。 我們遇到了兩個問題：

有基礎(chǔ)的組件，將復(fù)雜的邏輯固化，成為基礎(chǔ)軟件。 微信后臺會有幾個不同的基礎(chǔ)組件，大致包括：

微信微服務(wù)架構(gòu)應(yīng)用與管理

我們在微信中定義了各個微服務(wù)應(yīng)用場景：

我們還有分層的微服務(wù)：

服務(wù)布局

微信采用多區(qū)域自治、園區(qū)互為備份的架構(gòu)，城市間數(shù)據(jù)相對獨立。 除了少數(shù)賬戶的全球同步外，大部分業(yè)務(wù)都是以郵件服務(wù)為主，各有各的流通和交流環(huán)境。 城市之間的備份使用公網(wǎng)的UDP通道。

在城市中，采用三個園區(qū)的架構(gòu)，每個園區(qū)都是一個獨立的系統(tǒng)，每一層在接入、邏輯、存儲上完全獨立，可以相互備份服務(wù)器運維，多個園區(qū)形成一個整體的服務(wù)規(guī)模。

在校園里，多臺機器組成的集合是相互容錯的，包括它們在內(nèi)的網(wǎng)絡(luò)和電源也是獨立的。 這樣的服務(wù)布局，既滿足了微服務(wù)架構(gòu)，又考慮了容災(zāi)能力。

過載保護(hù)

過載保護(hù)是一個非常核心的微服務(wù)架構(gòu)特性，用來保證核心服務(wù)可用。

它由三個層次組成：

在這種情況下，需要有一個反饋機制。 如上圖所示，整個系統(tǒng)基于反饋，整個拒絕信息在整個過程中傳遞。 上圖右側(cè)是幾個典型的服務(wù)。 從一個CGI調(diào)用一個后臺服務(wù)，然后調(diào)用另一個后臺服務(wù)，系統(tǒng)會在CGI層面?zhèn)鬟f它的重要性。

回到前端調(diào)用服務(wù)A和B的例子，使用這樣的重要性轉(zhuǎn)移可以直接拒絕20%的相同用戶的請求，有效解決了單個服務(wù)輕微過載的問題。

容量管理

為了在微服務(wù)架構(gòu)下實現(xiàn)更好的容量關(guān)系，微信做到了三個前提：

容量管理是為了更好的支持業(yè)務(wù)，所以我們在需要支持的業(yè)務(wù)和容量之間建立模型關(guān)系，從而有效的評估那些有效的微服務(wù)對應(yīng)的容量。

如上圖所示，下方灰色線表示實際業(yè)務(wù)容量，即業(yè)務(wù)量，如：請求量、調(diào)用量、用戶數(shù)。

紅線表示機器擴容或升級后的現(xiàn)有網(wǎng)絡(luò)容量。 綠線代表最優(yōu)容量，比現(xiàn)有網(wǎng)絡(luò)容量高出20%，保證只是偶爾觸發(fā)。

當(dāng)業(yè)務(wù)需求超過現(xiàn)有容量時，可能會導(dǎo)致業(yè)務(wù)不穩(wěn)定或無法提供服務(wù)。 另一方面，縮放通常涉及復(fù)雜的數(shù)學(xué)運算。

因此，由于現(xiàn)實中資源的采購、部署和上市存在周期性，完全達(dá)到綠色曲線的可能性不大。

隨著公有云的廣泛使用，我們基本上可以及時獲取容量資源。 當(dāng)然，如果要保證良好的業(yè)務(wù)支撐，就應(yīng)該具備容量發(fā)現(xiàn)能力和合適的處理效率。

在實際評估容量時，可能會遇到如上圖所示的一個“坑點”：我們可能會將容量誤認(rèn)為是左邊的線性關(guān)系。

在某些時候，使用率在上升到 60% 之前是線性的，但一旦達(dá)到 65% 或 80%，它就會保持不變，再也不會上升，如右側(cè)的容量模型所示。

因此，容量評估的難點在于應(yīng)用程序或微服務(wù)在使用資源時會受到CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤I/O等多種因素的制約。

因此，我們應(yīng)該熟悉微服務(wù)主要消耗資源的關(guān)鍵點以及它與其他資源的關(guān)系。

對于容量評估，微信也引入了壓力測試。 如圖所示，我們有四種場景進(jìn)行mock測試：

壓力測試有兩個方面。 好的一面是它可以幫助我們發(fā)現(xiàn)過去沒有注意到的潛在問題； 不好的一面是出現(xiàn)問題后，我們可能無法快速恢復(fù)，有時甚至連撤回流量都沒有那么簡單。

因為一旦一個服務(wù)崩潰了，要重新啟動它是需要時間和精力的。 所以我們在做真正的壓測時，會特別注意上圖中列出的三點。

上圖顯示了過載保護(hù)的機制。 當(dāng)更多的流量到達(dá)時，會直接拒絕多余的流量。 顯然，我們也可以以此來衡量真實的流量大小。

可見，過載保護(hù)，或者說快速拒絕，是微服務(wù)架構(gòu)下進(jìn)行容量管理的重要前提。 如果沒有這種保護(hù)，將很難評估現(xiàn)有網(wǎng)絡(luò)容量的閾值。

微服務(wù)監(jiān)控

微信實現(xiàn)微服務(wù)的立體監(jiān)控，監(jiān)控內(nèi)容包括：

這些都有一些數(shù)據(jù)要在監(jiān)控中上報和顯示。 由于我們的監(jiān)控指標(biāo)非常多，隨著微服務(wù)的增多，它們產(chǎn)生的告警也會爆發(fā)式增長。 因此需要智能運維，通過AI應(yīng)用匯聚各種告警。

就監(jiān)控能力而言，我們?yōu)槊颗_機器都部署了Agent。 這些Agent的監(jiān)控粒度比較密集，可以做到秒級監(jiān)控。 同時，他們的數(shù)據(jù)上報能力也比較迅速。

業(yè)務(wù)部署和調(diào)度

容器編排是微服務(wù)的一個重要方面。 與微信采用自研架構(gòu)不同的是，它參考了borg/yarn/k8s/mesos等主流調(diào)度系統(tǒng)的特性。 容器調(diào)度微服務(wù)覆蓋率超過80%。 %。

微信的集裝箱調(diào)度系統(tǒng)叫做堆場。 如上圖底部所示，分為兩層架構(gòu)：

資源管理的監(jiān)控可以判斷：哪個應(yīng)用在哪個容器中被“拉起”，哪個應(yīng)用在哪個容器中“下線”。

雖然容器編排架構(gòu)是微信自研，尚未對外開放，但其調(diào)度能力已經(jīng)逐步向騰訊云開放。

騰訊云提供集群管理、資源調(diào)度、鏡像倉庫的組合。 其對應(yīng)產(chǎn)品包括CCS（容器管理）、API網(wǎng)關(guān)、分布式微服務(wù)架構(gòu)管理等。

微服務(wù)精細(xì)化運營

精細(xì)化運營要實現(xiàn)資源“削峰填谷”。 通過了解業(yè)務(wù)的特點，把握每個業(yè)務(wù)高峰的不同時間點，可以將資源控制在盡可能接近上圖藍(lán)線的位置。

比如：微信小游戲里有個功能模塊，半夜發(fā)新禮物。 這時候模塊對資源的需求會急劇增加，而同時其他模塊的資源消耗并不多。

因此，我們可以將游戲送禮的微服務(wù)部署到其他模塊服務(wù)器資源中，從而切斷其峰值，達(dá)到錯峰服務(wù)的效果。

我們在很多場景下都會用到離線計算，比如：各種日志分析、應(yīng)用數(shù)據(jù)分析、人工智能訓(xùn)練等。

這些都是可以做離線計算的服務(wù)，大部分不需要實時，都可以在資源最低點的時候部署。

微服務(wù)的未來演進(jìn)

在我們采用微服務(wù)架構(gòu)之后，有一些問題是值得我們認(rèn)真思考的：

整理/夏立成 上海藍(lán)夢創(chuàng)始人兼CEO，湖北IT公司副總裁，致力于以IT外包網(wǎng)絡(luò)維護(hù)服務(wù)賦能企業(yè)客戶發(fā)展，幫助企業(yè)客戶創(chuàng)新、迭代、進(jìn)化。

藍(lán)夢成立于上海，致力于提供IT外包、弱電工程（網(wǎng)絡(luò)布線、機房建設(shè)、門禁考勤、視頻監(jiān)控、電話交換機、多媒體會議室）、系統(tǒng)集成（建網(wǎng)、網(wǎng)絡(luò)改造、WIFI覆蓋）企業(yè)客戶、數(shù)據(jù)備份、病毒防護(hù)、文件權(quán)限、虛擬化等）、云服務(wù)（微軟云、阿里云、企業(yè)郵箱等）“一站式”IT外包解決方案。 ， 咨詢。