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

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

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

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

雖然我們?cè)诠ぷ髦腥匀浑x不開電腦服務(wù)器運(yùn)維，但我們使用手機(jī)上網(wǎng)的頻率更高了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

微服務(wù)架構(gòu)的特點(diǎn)和趨勢(shì)

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

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

另外，當(dāng)多個(gè)微服務(wù)共存時(shí)，同一個(gè)服務(wù)會(huì)有多個(gè)運(yùn)行副本，因此具有很高的容錯(cuò)性。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了使一切都具有可擴(kuò)展性，這里強(qiáng)調(diào)兩個(gè)方面：

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

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

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

我們?cè)谖⑿胖卸x了各個(gè)微服務(wù)應(yīng)用場(chǎng)景：

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

服務(wù)布局

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

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

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

過載保護(hù)

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

它由三個(gè)層次組成：

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

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

容量管理

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

容量管理是為了更好的支持業(yè)務(wù)，所以我們?cè)谛枰С值臉I(yè)務(wù)和容量之間建立模型關(guān)系，從而有效的評(píng)估那些有效的微服務(wù)對(duì)應(yīng)的容量。

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

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

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

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

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

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

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

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

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

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

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

因?yàn)橐坏┮粋€(gè)服務(wù)崩潰了，要重新啟動(dòng)它是需要時(shí)間和精力的。 所以我們?cè)谧稣嬲膲簻y(cè)時(shí)，會(huì)特別注意上圖中列出的三點(diǎn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們?cè)诤芏鄨?chǎng)景下都會(huì)用到離線計(jì)算，比如：各種日志分析、應(yīng)用數(shù)據(jù)分析、人工智能訓(xùn)練等。

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

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

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

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

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