偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

騰訊IT老兵:云端微服務(wù)架構(gòu)下的運(yùn)維思考

原創(chuàng)
運(yùn)維 系統(tǒng)運(yùn)維
本文圍繞微服務(wù)架構(gòu)的特點(diǎn)與發(fā)展趨勢(shì),結(jié)合微信業(yè)務(wù)在微服務(wù)架構(gòu)上的探索、應(yīng)用、改進(jìn)與提升,闡述運(yùn)維如何應(yīng)對(duì)業(yè)務(wù)在微服務(wù)架構(gòu)環(huán)境下的各種挑戰(zhàn)。

【51CTO.com原創(chuàng)稿件】互聯(lián)網(wǎng)技術(shù)一直在快速演進(jìn)當(dāng)中,同時(shí)移動(dòng)互聯(lián)網(wǎng)與云時(shí)代的來(lái)臨,讓微服務(wù)架構(gòu)應(yīng)運(yùn)而生。

[[226446]]

2017 年 12 月 1 日-2 日,由 51CTO 主辦的 WOTD 全球軟件開發(fā)技術(shù)峰會(huì)在深圳中州萬(wàn)豪酒店隆重舉行。

本次峰會(huì)以軟件開發(fā)為主題,熊普江先生在“微服務(wù)與容器技術(shù)”專場(chǎng)與來(lái)賓分享了"云端微服務(wù)架構(gòu)的運(yùn)維思考"的主題演講。

本文圍繞微服務(wù)架構(gòu)的特點(diǎn)與發(fā)展趨勢(shì),結(jié)合微信業(yè)務(wù)在微服務(wù)架構(gòu)上的探索、應(yīng)用、改進(jìn)與提升,闡述運(yùn)維如何應(yīng)對(duì)業(yè)務(wù)在微服務(wù)架構(gòu)環(huán)境下的各種挑戰(zhàn)。

如今互聯(lián)網(wǎng)技術(shù)呈現(xiàn)出兩方面的發(fā)展趨勢(shì):云化的趨勢(shì)和微服務(wù)。兩者相結(jié)合則更富挑戰(zhàn)性,本次我將以微信為例和大家一起探討。

本次分享分為三個(gè)方面:

  • 微服務(wù)架構(gòu)的演進(jìn)
  • 微服務(wù)架構(gòu)的特點(diǎn)與趨勢(shì)
  • 微服務(wù)架構(gòu)運(yùn)維的解決之道

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

智能手機(jī)在移動(dòng)互聯(lián)網(wǎng)中的快速普及,中國(guó)互聯(lián)網(wǎng)中心的相關(guān)調(diào)查表明:通過(guò)手機(jī)上網(wǎng)的用戶比例已經(jīng)高達(dá) 93% 以上;而整個(gè)中國(guó)的互聯(lián)網(wǎng)滲透比例也已超過(guò)六成。

因此,我們所處的移動(dòng)互聯(lián)網(wǎng)時(shí)代的開發(fā)呈現(xiàn)出如下的特征:

移動(dòng)互聯(lián)時(shí)代全面來(lái)臨

雖然在工作時(shí)仍然離不開電腦,但是我們使用手機(jī)來(lái)連接互聯(lián)網(wǎng)的場(chǎng)景更為頻繁。

由于手機(jī)的運(yùn)算能力有限,手機(jī)更多地被用于展示或顯示內(nèi)容。大量功能化的計(jì)算處理顯然需要依賴于云端。所以我們實(shí)際上處于一個(gè)瘦客戶端的時(shí)代。

隨著我們停留在移動(dòng)互聯(lián)網(wǎng)上的時(shí)間劇增,大量的數(shù)據(jù)也隨之產(chǎn)生,特別是相較于傳統(tǒng) PC 時(shí)代,增長(zhǎng)了數(shù)十倍、乃至數(shù)百倍。

這些大量的數(shù)據(jù)同樣也需要在云端進(jìn)行處理,因此我們對(duì)于云服務(wù)的能力也會(huì)有一定的要求。

硬件技術(shù)發(fā)展迅速,服務(wù)器性能越來(lái)越大。如今硬件的處理能力(特別是 GPU)發(fā)展迅速,服務(wù)器的處理能力也得到了迅速提升。

這都導(dǎo)致了單個(gè)應(yīng)用或者單個(gè)功能模塊很難消耗掉整臺(tái)服務(wù)器的資源。為了提高多臺(tái)服務(wù)器的資源利用率,我們需要將多個(gè)服務(wù)部署到同一臺(tái)機(jī)器之上。

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

在軟件方面,新興的技術(shù)包括:容器、Docker 和諸如 restful 之類的輕量協(xié)議,都加快了我們的開發(fā)與部署效率。

應(yīng)用的云化逐漸普及

為了將服務(wù)放到云端,我們不再需要去買各種機(jī)器,而直接在云上運(yùn)用各種資源來(lái)部署我們的服務(wù)。

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

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

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

這種從上到下的“縱切”方式勢(shì)必導(dǎo)致了對(duì)于技術(shù)人才、硬件、網(wǎng)絡(luò)、軟件、以及技術(shù)的大量需求。

這些對(duì)于初創(chuàng)型企業(yè)來(lái)說(shuō),會(huì)存在全能人才難招、開發(fā)復(fù)雜、遷移與擴(kuò)容難度大、無(wú)法快速的響應(yīng)等困難。

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

精細(xì)化運(yùn)營(yíng)轉(zhuǎn)變

由于越來(lái)越多的服務(wù)都要經(jīng)由云端處理,以通過(guò)各種容器來(lái)實(shí)現(xiàn)快速部署與擴(kuò)展,因此我們必需使用精細(xì)運(yùn)維,來(lái)實(shí)現(xiàn)對(duì)于資源的充分利用。

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

它是一種敏捷的開發(fā)模式架構(gòu),能夠讓我們迅速地實(shí)現(xiàn):編寫規(guī)劃→編寫代碼→構(gòu)建測(cè)試→發(fā)布上線→部署應(yīng)用。

近兩年,微服務(wù)這個(gè)術(shù)語(yǔ)漸成熱門詞匯,但它不是一個(gè)全新架構(gòu),更不是一個(gè)包治百病的架構(gòu)。

那么,微服務(wù)架構(gòu)與單體式架構(gòu)相比優(yōu)勢(shì)體現(xiàn)在哪?這些優(yōu)勢(shì)又給開發(fā)模式、運(yùn)維帶來(lái)哪些挑戰(zhàn)?

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

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

  • 一種架構(gòu)風(fēng)格。微服務(wù)架構(gòu)實(shí)際上并非一種新的技術(shù)或能力,而只是一種架構(gòu)的風(fēng)格。它大約出現(xiàn)在 2014 年,但是微信早在 2011 年就開始使用該架構(gòu)風(fēng)格和思路進(jìn)行開發(fā)與運(yùn)維了。
  • 強(qiáng)調(diào)服務(wù)的顆粒度、敏捷性和健壯性。微服務(wù)能夠?qū)崿F(xiàn)快速地開發(fā)、部署、和穩(wěn)健地運(yùn)行。
  • 單一、獨(dú)立。微服務(wù)專注于解決單一問(wèn)題,因此非常獨(dú)立。該獨(dú)立性體現(xiàn)在完成某個(gè)功能不依賴其他的服務(wù),即如果該服務(wù)出錯(cuò),并不會(huì)影響到其他服務(wù)。
  • 解耦,去中心化,組件化封裝。既然相對(duì)獨(dú)立,那么業(yè)務(wù)之間就是一種解耦的關(guān)系??v觀整個(gè)應(yīng)用之中的各個(gè)服務(wù),雖然重要程度有所區(qū)別,但是沒有一個(gè)服務(wù)必須以微服務(wù)為中心,因此它具有去中心化的特點(diǎn)。

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

  • 多個(gè)微服務(wù)組合完成相對(duì)復(fù)雜的業(yè)務(wù)系統(tǒng)。我們能夠快速地將各個(gè)微服務(wù)組合到一起,構(gòu)建出一個(gè)能夠達(dá)到特定需求且相對(duì)復(fù)雜的業(yè)務(wù)系統(tǒng)。
  • 高性能,高容錯(cuò)。由于每個(gè)服務(wù)都相對(duì)獨(dú)立,就能夠在保持系統(tǒng)穩(wěn)定的前提下,***地追求每個(gè)微服務(wù)的性能。在分布式的結(jié)構(gòu)中,單個(gè)微服務(wù)的出錯(cuò)(比如硬件出現(xiàn)問(wèn)題)不會(huì)影響到其他的微服務(wù)。

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

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

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

  • 適用于構(gòu)建復(fù)雜的應(yīng)用,通過(guò)運(yùn)用微服務(wù),可以將各種模塊如搭積木一般組合成相對(duì)復(fù)雜的應(yīng)用。
  • 分布式,由于各個(gè)微服務(wù)之間都遵守相同的協(xié)議,可以實(shí)現(xiàn)多個(gè)微服務(wù)的分布式部署。
  • 分別部署,由于每個(gè)微服務(wù)都具有單一且獨(dú)立的功能,因此服務(wù)模塊的數(shù)量顯然是龐大的,光靠人工完全無(wú)法實(shí)現(xiàn)分開部署。隨著微服務(wù)的數(shù)量呈幾何基數(shù)增長(zhǎng),我們需要用一套自動(dòng)化的工具來(lái)進(jìn)行快速地部署。
  • 服務(wù)組件,微服務(wù)一般分為兩種不同的類別:一是基礎(chǔ)模塊或稱公共模塊。如:用戶登錄、推送(Push)服務(wù)模塊;另一是功能性模塊,如:實(shí)現(xiàn)發(fā)消息或發(fā)朋友圈的模塊。
  • 微服務(wù)的邊界,雖然用的是同一種語(yǔ)言,但是可以進(jìn)行獨(dú)立地開發(fā)與測(cè)試,因此每個(gè)微服務(wù)在被發(fā)布的時(shí)候不會(huì)跟其他的微服務(wù)共享數(shù)據(jù)存儲(chǔ)或內(nèi)存空間。每個(gè)微服務(wù)都有自己的獨(dú)立空間。
  • API 層,如上圖所示,微服務(wù)與外界有一個(gè)接口層,它們遵守共同的協(xié)議進(jìn)行通信,如 RPC 或 Restful 等,大家可以自由選擇各種技術(shù)。
  • 微服務(wù)架構(gòu)的擴(kuò)展,為了應(yīng)對(duì)未來(lái)可能對(duì)現(xiàn)有微服務(wù)的功能性增加,或是要增加其他業(yè)務(wù)場(chǎng)景,我們一般不在原有微服務(wù)上著手增加,而是新建另一個(gè)微服務(wù),并獨(dú)立部署。

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

微服務(wù)架構(gòu)有如下幾個(gè)明顯的優(yōu)勢(shì):

  • 單個(gè)微服務(wù)更易理解,方便開發(fā)與維護(hù)。相比以往,只要定義好了一個(gè)微服務(wù),我們?cè)陂_發(fā)、維護(hù)和部署時(shí)就能方便地理解其功能意圖。
  • 應(yīng)用解耦、對(duì)應(yīng)用整體應(yīng)用交付而言,開發(fā)迭代更敏捷。我們可以單獨(dú)對(duì)一個(gè)微服務(wù)進(jìn)行升級(jí),而不會(huì)影響其他微服務(wù)的功能。
  • 技術(shù)選擇更加自由,微服務(wù)不再需要限定某個(gè)統(tǒng)一的技術(shù)實(shí)現(xiàn)。每個(gè)程序員都有自己的技術(shù)偏好,有人喜歡 Java,也有人喜歡 PHP 或是 C。
  • 以往大家不得不根據(jù)統(tǒng)一技術(shù)框架,遵循一致的開發(fā)語(yǔ)言。如今每個(gè)微服務(wù)都可以用不同的語(yǔ)言來(lái)實(shí)現(xiàn)。
  • 微服務(wù)獨(dú)立部署,應(yīng)用更穩(wěn)定。由于每個(gè)微服務(wù)都不影響其他的微服務(wù),因此單獨(dú)部署會(huì)給整體應(yīng)用帶來(lái)更好的穩(wěn)定性。
  • 架構(gòu)擴(kuò)展更容易、更快速。如右圖所示,我們從三個(gè)維度進(jìn)行架構(gòu)設(shè)計(jì)。其中 X 軸表示可以放置多個(gè)副本;Y 軸是通過(guò)分層來(lái)擴(kuò)容服務(wù);而 Z 軸是對(duì)服務(wù)進(jìn)行數(shù)據(jù)分區(qū)。
  • 這說(shuō)明我們的微服務(wù)能從 X、Y、Z 三個(gè)方向去擴(kuò)展整體架構(gòu)。

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

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

  • 開發(fā)模式需要相應(yīng)調(diào)整,首先要從“縱切”的開發(fā)思維轉(zhuǎn)變成“橫切”的思維。
  • 跟以往相比,微服務(wù)的數(shù)量會(huì)大幅增加。
  • 數(shù)據(jù)增多導(dǎo)致了容器的編排、配置與資源的管理更為復(fù)雜。相對(duì)于過(guò)去只需管幾臺(tái)機(jī)器而言,如今如何搭配和配置各種微服務(wù)會(huì)變得更復(fù)雜。
  • 業(yè)務(wù)的容量管理變得更加困難,資源利用效率難以提升。以前我們只需要監(jiān)控某幾臺(tái)機(jī)器的使用率。
  • 如今,由于容器存在多臺(tái)服務(wù)器上,就需要對(duì)容器里各種服務(wù)的資源利用率和容量進(jìn)行綜合管理,同時(shí)對(duì)它們的提升難度也更大了。
  • 監(jiān)控的顆粒度增多,依賴及關(guān)聯(lián)關(guān)系更加復(fù)雜。由于微服務(wù)的增多,監(jiān)控的顆粒也相應(yīng)有所增加。如上圖右側(cè)所示,顆粒之間的關(guān)聯(lián)關(guān)系也會(huì)變得更加復(fù)雜。
  • 在微服務(wù)出現(xiàn)故障時(shí),我們要有快速調(diào)度的能力,因此調(diào)度需要更精細(xì)化。

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

下面是我在微服務(wù)架構(gòu)下的一些運(yùn)維思考:

  • 容量管理,即:如何在細(xì)粒度的狀態(tài)下,更有效地管理數(shù)量龐大的微服務(wù)。
  • 容器編排與配置管理,如何合理地實(shí)現(xiàn)容器編排和配置管理?
  • 服務(wù)監(jiān)控,如何有效地監(jiān)控?cái)?shù)量龐大的微服務(wù)?
  • 故障恢復(fù)與業(yè)務(wù)調(diào)度,出現(xiàn)故障時(shí)如何進(jìn)行業(yè)務(wù)調(diào)度?
  • 快速擴(kuò)展,由于春節(jié)紅包或直播所導(dǎo)致的業(yè)務(wù)爆炸式增長(zhǎng)或觸發(fā)時(shí),如何快速擴(kuò)容?
  • 資源的利用效率,運(yùn)維人員需要思考如何在保障業(yè)務(wù)穩(wěn)定發(fā)展的同時(shí),控制好成本不會(huì)大幅增長(zhǎng),資源不會(huì)出現(xiàn)簡(jiǎn)單堆砌。

微服務(wù)架構(gòu)運(yùn)維的解決之道

下面先以微信為例,講解它使用到微服務(wù)架構(gòu)的地方,接著介紹我們?cè)谖⒎?wù)容量管理方面的具體工作,然后給大家分享在監(jiān)控部署調(diào)度上值得參考的地方,***探討我們?cè)谫Y源利用率上的精細(xì)化運(yùn)營(yíng)。

微信為什么要微服務(wù)云化

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

在微信內(nèi)部有四個(gè)“法器”,分別是:

  • 大系統(tǒng)小做
  • 讓一切可擴(kuò)展
  • 有基礎(chǔ)的組件
  • 能夠輕松地上線

大系統(tǒng)小做,不僅涉及到將海量系統(tǒng)中的模塊變得更清晰,而且在物理環(huán)境中實(shí)現(xiàn)分開獨(dú)立的部署,以便快速發(fā)現(xiàn)問(wèn)題。

例如:一些公共服務(wù)的注冊(cè)登錄、LBS 的邏輯、和類似微信的搖一搖等方面,我們都將這些邏輯獨(dú)立了出來(lái)。

讓一切可擴(kuò)展,此處強(qiáng)調(diào)兩個(gè)方面:

  • 網(wǎng)絡(luò)協(xié)議的擴(kuò)展。通過(guò)向前兼容,以應(yīng)對(duì)將來(lái)可能出現(xiàn)的升級(jí)。
  • 數(shù)據(jù)存儲(chǔ)的擴(kuò)展。傳統(tǒng)的 MySQL 之類的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ),對(duì)于后期頻繁增加字段的擴(kuò)展性并不方便。因此微信采用的是 Key-Value 的非結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu),以方便存儲(chǔ)上的擴(kuò)展。

在 2013 年到 2014 年間,微信的微服務(wù)模塊數(shù)已超過(guò)了 5000 個(gè),我們碰到過(guò)兩個(gè)問(wèn)題:

  • 如果在一臺(tái)硬件能力超強(qiáng)的服務(wù)器上只部署一個(gè)模塊,則勢(shì)必造成資源浪費(fèi)。因此我們采用了混合部署,在一個(gè)服務(wù)器上部署多個(gè)服務(wù)。
  • 多個(gè)服務(wù)在一臺(tái)服務(wù)器上搶資源,從而影響了服務(wù)的穩(wěn)定性。因此我們采用了容器隔離。

有基礎(chǔ)的組件,把復(fù)雜的邏輯固化下來(lái),成為基礎(chǔ)性軟件。在微信的后臺(tái)會(huì)有幾種不同的基礎(chǔ)組件,大致包括:

  • Svrkit,Client/Server自動(dòng)代碼生成框架,實(shí)現(xiàn) 10 分鐘搭建內(nèi)部服務(wù)器。
  • LogicServer,邏輯容器:隨時(shí)添加新邏輯。
  • OssAgent,監(jiān)控/統(tǒng)計(jì)框架:所見即所得的監(jiān)控報(bào)表。
  • 存儲(chǔ)組件,屏蔽容災(zāi)/擴(kuò)容等復(fù)雜問(wèn)題。

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

我們對(duì)微信里的各個(gè)微服務(wù)應(yīng)用場(chǎng)景進(jìn)行了定義:

  • 服務(wù)布局,就是將用戶運(yùn)用不同的方法與服務(wù)維度進(jìn)行“切割”和布局。
  • 引入各種容錯(cuò)機(jī)制,如:當(dāng)服務(wù)訪問(wèn)中斷時(shí),可自動(dòng)重試;當(dāng)服務(wù)運(yùn)能不夠時(shí),有過(guò)載保護(hù)和負(fù)載均衡;在必要時(shí),可隨時(shí)關(guān)閉服務(wù),實(shí)現(xiàn)柔性可用。
  • 容量管理與監(jiān)控。
  • 部署管理與調(diào)度。
  • 精細(xì)化運(yùn)營(yíng)。

我們對(duì)微服務(wù)也進(jìn)行了技術(shù)分層:

  • 接入層,主要實(shí)現(xiàn)對(duì)用戶的切分,以識(shí)別不同的運(yùn)營(yíng)商和不同的地域。
  • 邏輯層,在微信中,微服務(wù)被更多地應(yīng)用在邏輯層。
  • 存儲(chǔ)層,主要應(yīng)對(duì)海量數(shù)據(jù),以及獨(dú)占資源的情況。

服務(wù)布局

微信采用多地自治、園區(qū)互備的架構(gòu),城市之間的數(shù)據(jù)是相對(duì)獨(dú)立的。除了少數(shù)賬號(hào)全球同步以外,大部分業(yè)務(wù)都以電子郵件式的服務(wù),各自有自身的環(huán)境在流轉(zhuǎn)和通信。城市間的后備則使用公網(wǎng)的 UDP 通道。

在城市內(nèi),使用三園區(qū)的架構(gòu),每個(gè)園區(qū)都是一套獨(dú)立的系統(tǒng),從接入、邏輯、存儲(chǔ)每一層都是完全獨(dú)立的,并且可以互相為對(duì)方提供備份,多園區(qū)形成整體服務(wù)規(guī)模。

在園區(qū)內(nèi),由多機(jī)組成的 set,互為容錯(cuò),包含它們的網(wǎng)絡(luò)與電力也是獨(dú)立的。這樣的服務(wù)布局,不僅滿足微服務(wù)架構(gòu),也考慮了容災(zāi)能力。

過(guò)載保護(hù)

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

它包括三個(gè)層次:

  • 服務(wù)要有輕重分離。即一個(gè)服務(wù)里不能既有重的操作,又有輕的操作。
  • 隊(duì)列控制。我們通過(guò)監(jiān)控,來(lái)了解一個(gè)請(qǐng)求在隊(duì)列中等待的平均時(shí)間,從而決定是否要啟動(dòng)拒絕或是限流。例如:對(duì)超過(guò)設(shè)定閥值的流量進(jìn)行限制,確保服務(wù)可用。
  • 組合命令式。由于微服務(wù)的調(diào)用鏈以及層次的增多,后端服務(wù)也會(huì)有多種。假定后端有兩個(gè)服務(wù)(A 服務(wù)與 B 服務(wù)),而前端調(diào)用需要依賴于 A、B 服務(wù)的組合結(jié)果,那么單個(gè) A 或者單個(gè) B 的輕微過(guò)載,就可能導(dǎo)致前端服務(wù)不可用。

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

回到剛才前端調(diào)用 A、B 服務(wù)的例子,使用這樣一種重要程度的傳遞,就可以直接拒絕那些相同用戶的 20% 的請(qǐng)求,有效地解決單個(gè)服務(wù)輕微過(guò)載的問(wèn)題。

容量管理

為了在微服務(wù)架構(gòu)下實(shí)行較好的容量關(guān)系,微信做到了三個(gè)前提:

  • 微服務(wù)間資源進(jìn)行隔離管理
  • 微服務(wù)的過(guò)載有自我保護(hù)能力
  • 服務(wù)的快速伸縮操作

容量管理是為了更好地進(jìn)行業(yè)務(wù)支撐,因此我們構(gòu)建了需要支撐的業(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)容量。綠色線則表示***容量,它比現(xiàn)網(wǎng)容量要高出 20%,以保證只是偶爾被觸發(fā)。

當(dāng)業(yè)務(wù)需求超過(guò)現(xiàn)有容量時(shí),業(yè)務(wù)就可能出現(xiàn)不穩(wěn)定或者無(wú)法提供服務(wù)的情況。而擴(kuò)容則往往涉及到復(fù)雜的數(shù)學(xué)運(yùn)算。

因此由于現(xiàn)實(shí)中資源的采購(gòu)、部署與上架存在周期,不大可能完全達(dá)到該綠色曲線。

隨著公有云被廣泛地運(yùn)用,我們基本上能夠?qū)崿F(xiàn)及時(shí)獲取容量資源。當(dāng)然要保證具有較好的業(yè)務(wù)支撐的話,應(yīng)當(dāng)具有容量的發(fā)現(xiàn)能力和適當(dāng)?shù)奶幚硇省?/p>

在實(shí)際進(jìn)行容量評(píng)估的時(shí)候,可能會(huì)碰到如上圖所示的“坑點(diǎn)”:我們可能會(huì)將容量誤解為左邊的線性關(guān)系。

在某些時(shí)候,使用量上升到 60% 之前還是處于線性,可一旦升至 65% 或 80% 時(shí),就會(huì)維持那么多且再也上不去了,如右邊的容量模型所示。

所以說(shuō)容量評(píng)估的困難之處就在于:一個(gè)應(yīng)用或一個(gè)微服務(wù)在使用資源時(shí)會(huì)受到諸如:CPU、內(nèi)存、網(wǎng)絡(luò)、以及磁盤 I/O 等多種因素的制約。

因此,我們應(yīng)當(dāng)去熟悉某個(gè)微服務(wù)主要消耗資源的關(guān)鍵點(diǎn),以及它與其他資源之間的關(guān)系。

針對(duì)容量的評(píng)估,同樣在微信中引入了壓測(cè)。如圖所示,我們有四種模擬測(cè)試的方案:

  • 模擬流量到測(cè)試環(huán)境,它對(duì)現(xiàn)網(wǎng)不產(chǎn)生影響。這往往由測(cè)試團(tuán)隊(duì)來(lái)操作。
  • 真實(shí)流量到測(cè)試環(huán)境,即運(yùn)用 TCP 協(xié)議復(fù)制一份流量到測(cè)試環(huán)境。許多電商經(jīng)常在一些大促之前,會(huì)把一些真實(shí)的流量引到測(cè)試環(huán)境之中,以檢驗(yàn)系統(tǒng)到底能支撐多久。這往往由運(yùn)維和開發(fā)協(xié)同執(zhí)行。
  • 模擬流量到現(xiàn)網(wǎng)環(huán)境,這種并不常見。
  • 真實(shí)流量到真實(shí)環(huán)境,這是在微信中使用最多主要的現(xiàn)網(wǎng)壓測(cè)方式。該方法雖然最真實(shí)、且對(duì)容量的評(píng)估也最準(zhǔn)確,但也會(huì)有***的風(fēng)險(xiǎn)。它可能會(huì)引發(fā)故障,并考驗(yàn)我們及時(shí)發(fā)現(xiàn)故障點(diǎn)的能力。

壓測(cè)具有雙面性,好的一面在于:有助于我們發(fā)現(xiàn)過(guò)去未曾注意的底層問(wèn)題;不好的一面,則是在出現(xiàn)問(wèn)題之后,我們可能無(wú)法快速地恢復(fù),有時(shí)甚至并非將流量撤掉那么簡(jiǎn)單。

因?yàn)橐坏┠硞€(gè)服務(wù)崩潰了,則需要花時(shí)間和精力重新啟動(dòng)它。因此我們?cè)谧稣鎸?shí)壓測(cè)時(shí),會(huì)特別注意上圖所列的三點(diǎn)。

上圖展示了過(guò)載保護(hù)的機(jī)制。當(dāng)有更多的流量抵達(dá)時(shí),過(guò)剩的流量會(huì)被直接拒絕掉,顯然我們也可籍此測(cè)算出其真實(shí)的流量大小。

可見過(guò)載保護(hù),或稱快速拒絕是在微服務(wù)架構(gòu)下做好容量管理的重要前提。如果沒有該保護(hù),將很難評(píng)估現(xiàn)網(wǎng)容量的門限。

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

微信實(shí)現(xiàn)了對(duì)于微服務(wù)的立體化監(jiān)控,監(jiān)控的內(nèi)容包括:

  • 常規(guī)指標(biāo),如 CPU、內(nèi)存、網(wǎng)卡等。
  • 快速拒絕的數(shù)量級(jí),通過(guò)該數(shù)量級(jí),可以進(jìn)一步評(píng)估受影響的用戶量。
  • 耗時(shí)方面的精確數(shù)據(jù)。
  • 調(diào)用失敗的次數(shù)、重試的次數(shù)。

這些在監(jiān)控上都有一些數(shù)據(jù)來(lái)上報(bào)及展現(xiàn)。由于我們監(jiān)控指標(biāo)非常多,同時(shí)伴隨著微服務(wù)的增多,其產(chǎn)生的報(bào)警數(shù)量也會(huì)呈爆炸式增長(zhǎng)。因此需要有智慧化的運(yùn)維,通過(guò) AI 應(yīng)用去收斂各種報(bào)警。

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

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

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

微信的容器調(diào)度系統(tǒng)叫做 yard。如上圖下方所示,它分為兩層架構(gòu):

  • Resource Manager 和 Node Manager,負(fù)責(zé)資源管理。
  • Application Master 和 API/Query Server,負(fù)責(zé)作業(yè)管理。

資源管理的監(jiān)控能夠決定出:在哪個(gè)容器中將哪個(gè)應(yīng)用“拉起來(lái)”,而在哪個(gè)容器里將其“下線”。

雖然該容器編排架構(gòu)屬于微信自研、且尚未對(duì)外開放,但是其調(diào)度能力已逐步開放到了騰訊云之上。

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

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

精細(xì)化運(yùn)營(yíng)要做到對(duì)資源進(jìn)行“削峰填谷”。通過(guò)了解業(yè)務(wù)的特性,掌握每個(gè)業(yè)務(wù)峰值的不同時(shí)間,從而將資源盡可能控制在上圖的藍(lán)色線條附近。

例如:微信的游戲里有一個(gè)功能模塊,在凌晨零點(diǎn)的時(shí)候開始新發(fā)禮品。此時(shí)該模塊對(duì)于資源的需求會(huì)劇增,而同一時(shí)刻其他模塊的資源消耗并不多。

因此我們就可以把該游戲發(fā)禮品的微服務(wù)部署到其他模塊服務(wù)器資源之上,從而削除它的峰值,達(dá)到了錯(cuò)峰服務(wù)的效果。

我們?cè)谠S多場(chǎng)景中會(huì)用到離線計(jì)算,如:各種日志分析、應(yīng)用數(shù)據(jù)分析、以及人工智能方面的訓(xùn)練。

這些都是可以使用到離線計(jì)算的業(yè)務(wù),多數(shù)不需要實(shí)時(shí),它們都可以被部署在資源谷底的時(shí)候。

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

我們采用微服務(wù)架構(gòu)之后,有些問(wèn)題也值得我們?nèi)フJ(rèn)真思考:

  • 微服務(wù)這么多,我們能否延用以往的 CMDB 方式進(jìn)行有效地管理呢?特別是那些放在公有云端的微服務(wù),如何將它們納入現(xiàn)有的 CMDB 呢?
  • 是否有更好的微服務(wù)管理工具,來(lái)實(shí)現(xiàn)服務(wù)可視化、消息跟蹤和智能故障檢測(cè)?
  • 是否有微服務(wù)的應(yīng)用商店,來(lái)幫助我們快速地開發(fā)各種應(yīng)用?

[[226451]]

熊普江,騰訊公司資深架構(gòu)師 ,負(fù)責(zé)公司騰訊云技術(shù)、解決方案布道與技術(shù)架構(gòu)評(píng)審等工作。騰訊公司級(jí)課程講師,GITC 專家顧問(wèn),WOT 特約講師,GOPS 金牌講師。自 1997 年涉足互聯(lián)網(wǎng),曾服務(wù)美國(guó) Supreme、太平洋網(wǎng)絡(luò)、PPTV 等互聯(lián)網(wǎng)公司,任網(wǎng)絡(luò)運(yùn)營(yíng)總監(jiān)、運(yùn)維總監(jiān)等職務(wù)。近 20 年互聯(lián)網(wǎng)從業(yè)背景,對(duì)大型網(wǎng)絡(luò)架構(gòu)規(guī)劃與建設(shè),海量用戶平臺(tái)規(guī)劃與運(yùn)營(yíng)技術(shù)支持,超大規(guī)模業(yè)務(wù)資源規(guī)劃與技術(shù)架構(gòu)管理優(yōu)化有豐富的經(jīng)驗(yàn)。

【51CTO原創(chuàng)稿件,合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】

責(zé)任編輯:武曉燕 來(lái)源: 51CTO技術(shù)棧
相關(guān)推薦

2017-06-02 10:17:57

騰訊運(yùn)維

2016-06-14 10:03:45

運(yùn)維 架構(gòu)

2017-07-10 10:21:51

微服務(wù)架構(gòu)運(yùn)維管理運(yùn)維平臺(tái)架構(gòu)

2018-05-10 08:18:12

無(wú)服務(wù)器運(yùn)維服務(wù)器

2017-03-17 19:28:36

深信服

2017-03-20 21:00:50

超融合云計(jì)算IT運(yùn)維

2013-08-08 09:16:38

IT運(yùn)維信息化

2018-10-24 05:14:11

2013-10-17 10:58:17

IT運(yùn)維管理運(yùn)維管理

2015-12-01 14:51:43

2012-08-31 14:00:40

IT運(yùn)維

2021-07-27 11:31:29

運(yùn)維架構(gòu)技術(shù)

2025-04-30 05:00:00

批量運(yùn)維系統(tǒng)

2016-04-15 00:43:13

2020-12-28 12:22:12

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

2017-07-17 15:50:17

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

2021-06-22 18:00:09

微服務(wù)架構(gòu)系統(tǒng)

2012-01-16 13:55:23

2020-10-20 10:46:10

DevOps運(yùn)維體系

2022-03-02 09:00:00

微服務(wù)架構(gòu)開發(fā)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)