微服務架構的演進

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

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

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

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

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

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

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

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

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

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

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

應用云化正流行

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

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

發(fā)展模式轉變

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

這種自上而下的“垂直切割”方式必然導致對技術人才、硬件、網絡、軟件、技術的大量需求。

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

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

精細化運營轉型

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

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

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

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

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

微服務架構的特點和趨勢

微服務架構的特點和趨勢如下：

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

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

微服務架構分析

微服務架構分析：

微服務架構的優(yōu)勢

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

微服務架構帶來的挑戰(zhàn)

下面談談在引入微服務架構時會遇到的各種挑戰(zhàn)：

微服務架構下的運維思維

以下是我對微服務架構下運維的一些思考：

微服務架構運維解決方案

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

微信為什么要用云端的微服務？

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

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

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

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

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

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

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

微信微服務架構應用與管理

我們在微信中定義了各個微服務應用場景：

我們還有分層的微服務：

服務布局

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

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

在校園里，多臺機器組成的集合是相互容錯的，包括它們在內的網絡和電源也是獨立的。 這樣的服務布局，既滿足了微服務架構，又考慮了容災能力。

過載保護

過載保護是一個非常核心的微服務架構特性，用來保證核心服務可用。

它由三個層次組成：

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

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

容量管理

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

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

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

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

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

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

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

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

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

因此，容量評估的難點在于應用程序或微服務在使用資源時會受到CPU、內存、網絡、磁盤I/O等多種因素的制約。

因此，我們應該熟悉微服務主要消耗資源的關鍵點以及它與其他資源的關系。

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

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

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

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

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

微服務監(jiān)控

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

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

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

業(yè)務部署和調度

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

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

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

雖然容器編排架構是微信自研，尚未對外開放，但其調度能力已經逐步向騰訊云開放。

騰訊云提供集群管理、資源調度、鏡像倉庫的組合。 其對應產品包括CCS（容器管理）、API網關、分布式微服務架構管理等。

微服務精細化運營

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

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

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

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

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

微服務的未來演進

在我們采用微服務架構之后，有一些問題是值得我們認真思考的：

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

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