【51CTO.com原創(chuàng)稿件】負(fù)載均衡是實(shí)現(xiàn)網(wǎng)絡(luò)就近接入的核心技術(shù)之一，它的作用是把海量涌入的流量相對(duì)均勻的調(diào)配到N個(gè)可完成相同任務(wù)的網(wǎng)絡(luò)節(jié)點(diǎn)或服務(wù)器，來規(guī)避載壓不均的狀況。負(fù)載均衡作為應(yīng)用流量的入口，直接影響應(yīng)用的性能和可靠性。
近日，51CTO 以“Tech Neo”為主題的第十五期技術(shù)沙龍?jiān)诒本┡e行，本次沙龍邀請(qǐng)了來自美團(tuán)云負(fù)載均衡網(wǎng)關(guān)MGW產(chǎn)品研發(fā)負(fù)責(zé)人王偉。他擁有多年負(fù)載均衡系統(tǒng)的一線實(shí)施經(jīng)驗(yàn)，主導(dǎo)并推進(jìn)MGW（美團(tuán)四層負(fù)載均衡）的技術(shù)選型以及性能優(yōu)化工作。本文中，我們可以了解到承載美團(tuán)點(diǎn)評(píng)數(shù)十 Gbps的流量、上千萬的并發(fā)連接的MGW、如何實(shí)現(xiàn)高性能、高可靠的詳盡優(yōu)化過程等。
互聯(lián)網(wǎng)初期階段，業(yè)務(wù)邏輯簡單、流量不大，單臺(tái)服務(wù)器就可滿足日常需求。隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)務(wù)不僅會(huì)流量爆發(fā)、邏輯越來越復(fù)雜且對(duì)可靠性的需求也逐步遞增。這時(shí)，就需要多臺(tái)服務(wù)器來應(yīng)對(duì)單臺(tái)服務(wù)器在性能、單點(diǎn)等方面凸顯出來的問題，進(jìn)行性能的水平擴(kuò)展和災(zāi)備。但客戶端的流量要如何順利訪問到這么多不同的服務(wù)器是個(gè)問題。
對(duì)于這個(gè)問題，可選擇使用DNS做負(fù)載，對(duì)客戶端不同IP地址進(jìn)行解析，使得流量直接到達(dá)不同的應(yīng)用服務(wù)器。但這個(gè)調(diào)度策略相對(duì)簡單卻不能很好的滿足業(yè)務(wù)需求，當(dāng)改變調(diào)度策劃后，DNS各級(jí)節(jié)點(diǎn)的緩存不能及時(shí)在客戶端生效，會(huì)導(dǎo)致很嚴(yán)重的延時(shí)性問題。這時(shí)可選擇使用負(fù)載均衡，如下圖：
如圖所示，客戶端的流量先到達(dá)負(fù)載均衡服務(wù)器，再由負(fù)載均衡服務(wù)器采用一些調(diào)度算法，把流量分發(fā)到不同的應(yīng)用服務(wù)器。與此同時(shí)，負(fù)載均衡服務(wù)器對(duì)應(yīng)用服務(wù)器進(jìn)行周期性健康檢查，一旦查出故障節(jié)點(diǎn)，直接剔除，進(jìn)而保證應(yīng)用的高可用。
負(fù)載均衡分為四層和七層兩種，如下圖：
四層負(fù)載均衡的核心是轉(zhuǎn)發(fā)，收到客戶端流量，對(duì)數(shù)據(jù)包地址信息進(jìn)行修改后，轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器，整個(gè)過程均在OSI模型的傳輸層完成。
七層復(fù)雜均衡的核心是代理，當(dāng)接收到客戶端的流量后，通過完整的TCP/IP協(xié)議棧對(duì)應(yīng)用層流量進(jìn)行解析。之后，基于調(diào)度算法選擇合適的應(yīng)用服務(wù)器，并與應(yīng)用服務(wù)器建立連接將請(qǐng)求發(fā)送，整個(gè)過程在OSI模型的應(yīng)用層完成。
轉(zhuǎn)發(fā)是四層負(fù)載均衡的主要工作，目前主要有四種轉(zhuǎn)發(fā)模式：DR模式、NAT模式、TUNNEL模式和FULLNAT模式。如下是四種轉(zhuǎn)發(fā)模式的優(yōu)缺點(diǎn)對(duì)比圖表：
從圖中可以直觀的看到四種轉(zhuǎn)發(fā)模式的優(yōu)缺點(diǎn)，DR模式（三角傳輸）的實(shí)現(xiàn)方式是修改數(shù)據(jù)包的目的MAC地址；NAT模式的實(shí)現(xiàn)方式是修改數(shù)據(jù)包的目的IP地址；TUNNEL模式的實(shí)現(xiàn)方式和DR相同，但要求應(yīng)用服務(wù)器必須支持TUNNEL功能。
美團(tuán)點(diǎn)評(píng)最終選擇FULLNAT作為MGW的轉(zhuǎn)發(fā)模式，它是在NAT模式的基礎(chǔ)上做一次源地址轉(zhuǎn)換（即SNAT）。此模式的優(yōu)勢(shì)在于可使應(yīng)答流量經(jīng)過正常三層路由回歸負(fù)載均衡，負(fù)載均衡就不需以網(wǎng)管的形式存在于網(wǎng)絡(luò)中，進(jìn)而降低了對(duì)網(wǎng)絡(luò)環(huán)境的要求。不足之處在于做SNAT，應(yīng)用服務(wù)器會(huì)出現(xiàn)丟失客戶端的真實(shí)IP地址的情況。
如下圖，是FULLNAT轉(zhuǎn)發(fā)模式的具體實(shí)現(xiàn)流程：
如圖在負(fù)載均衡上布設(shè)localip池，做SNAT的過程中，源IP取自其中。當(dāng)客戶端流量到達(dá)負(fù)載均衡設(shè)備，負(fù)載均衡依據(jù)調(diào)度策略在應(yīng)用服務(wù)器池中選擇一個(gè)應(yīng)用服務(wù)器，將數(shù)據(jù)包的目的IP改為應(yīng)用服務(wù)器IP。同時(shí)從localip池中選擇一個(gè)localip將數(shù)據(jù)包的源IP改為localip，這樣應(yīng)用服務(wù)器在應(yīng)答時(shí)，目的IP是localip，而localip是真實(shí)存在于負(fù)載均衡上的IP地址，因此可以經(jīng)過正常的三層路由到達(dá)負(fù)載均衡。
與NAT模式相比，F(xiàn)ULLNAT模式會(huì)多做一次SNAT，過程中還有選端口的操作，在性能方面要稍弱于NAT模式，但FULLNAT模式在網(wǎng)絡(luò)適應(yīng)性方面要占優(yōu)勢(shì)。
為什么美團(tuán)點(diǎn)評(píng)會(huì)選擇自研的四層負(fù)載均衡呢？主要有兩個(gè)原因：
LVS方面，美團(tuán)點(diǎn)評(píng)最初的方式是使用LVS做四層負(fù)載均衡、Nginx做七層負(fù)載均衡。如上圖所示，流量高速增長，LVS在性能上出現(xiàn)瓶頸，故障率增加。
在硬件負(fù)載均衡方面，凸顯出來的問題有三方面：異常高的硬件成本、人力成本和時(shí)間成本。
綜合這兩個(gè)原因，美團(tuán)點(diǎn)評(píng)決定自研四層負(fù)載均衡MGW來替換LVS，MGW需要滿足高性能、高可靠兩個(gè)特性。那么如何實(shí)現(xiàn)高性能、高可靠呢？
對(duì)比LVS的一些性能瓶頸，我們可以直觀了解MGW實(shí)現(xiàn)高性能的解決方法。這里主要涉及LVS遇到的中斷、過長的協(xié)議棧路徑、鎖和上下文切換這四大問題，MGW應(yīng)對(duì)這些問題的解決辦法分別是PMD驅(qū)動(dòng)、Kernelbypass、無鎖的設(shè)計(jì)和CPU綁定、隔離。
LVS是做在內(nèi)核中的，而內(nèi)核在設(shè)計(jì)時(shí)要兼顧通用性，所以采用中斷的方式感知流量的接收。中斷對(duì)LVS性能的影響非常大，如果每秒處理500萬數(shù)據(jù)包，每5個(gè)數(shù)據(jù)包產(chǎn)生一個(gè)硬件中斷，那么一秒會(huì)產(chǎn)生100萬個(gè)硬件中斷，每一次產(chǎn)生的硬件中斷都會(huì)打斷正在進(jìn)行密集計(jì)算的負(fù)載均衡程序，中間產(chǎn)生大量的cache miss，這對(duì)性能的影響非常大。
因?yàn)長VS是基于內(nèi)核netfilter開發(fā)的應(yīng)用程序，而netfilter是運(yùn)行在內(nèi)核協(xié)議棧的一個(gè)鉤子框架。當(dāng)數(shù)據(jù)包到達(dá)LVS時(shí)，要經(jīng)過一段很長的協(xié)議棧處理。實(shí)際情況是負(fù)載均衡在接到流量以后，只需對(duì)MAC、IP、端口進(jìn)行修改發(fā)出即可，并不需要這段處理來增加額外的消耗。
針對(duì)中斷和過長協(xié)議棧路徑這兩個(gè)問題的解決方法是采用由DPDK提供的用戶態(tài)PMD驅(qū)動(dòng)以及做Kernelbypass。DPDK在設(shè)計(jì)過程中，使用了大量硬件特性，如numa、 memory channel、 DDIO等對(duì)性能提升很大。同時(shí)提供網(wǎng)絡(luò)方面的庫，進(jìn)而減小開發(fā)難度，提升開發(fā)效率。這些都是美團(tuán)點(diǎn)評(píng)選擇DPDK作為MGW的開發(fā)框架的因素。
內(nèi)核是較通用的應(yīng)用程序，為了兼顧不同硬件，在設(shè)計(jì)過程中會(huì)加一些鎖。而自主研發(fā)只需對(duì)某些特定場景進(jìn)行定制設(shè)計(jì)，不用兼顧很多硬件，進(jìn)而通過一些方法去掉鎖，實(shí)現(xiàn)完全無鎖的狀態(tài)，方便后續(xù)擴(kuò)展。
先來看看什么情況需要進(jìn)行鎖的設(shè)計(jì)。首先介紹一下RSS（Receive Side Scaling），RSS是一個(gè)通過數(shù)據(jù)包的元組信息將數(shù)據(jù)包散列到不同網(wǎng)卡隊(duì)列的功能，這時(shí)不同CPU再去對(duì)應(yīng)的網(wǎng)卡隊(duì)列讀取數(shù)據(jù)進(jìn)行處理，就可充分利用CPU資源。
MGW使用的是FULLNAT模式，會(huì)將數(shù)據(jù)包的元組信息全部改變。這樣同一個(gè)連接，請(qǐng)求和應(yīng)答方向的數(shù)據(jù)包有可能會(huì)被RSS散列到不同的網(wǎng)卡隊(duì)列中，在不同的網(wǎng)卡隊(duì)列也就意味著在被不同的CPU進(jìn)行處理，這時(shí)在訪問session結(jié)構(gòu)就需要對(duì)這個(gè)結(jié)構(gòu)進(jìn)行加鎖保護(hù)。
解決這個(gè)問題，一般情況下有如下兩種方案：
由于第二種方法恰好可被網(wǎng)卡的flow director特性支持，因此MCW選擇第二種方法來去掉session結(jié)構(gòu)的鎖。
flow director可依據(jù)一定策略將指定的數(shù)據(jù)包送到指定網(wǎng)卡隊(duì)列，其在網(wǎng)卡中的優(yōu)先級(jí)要比RSS高，因此在做初始化的時(shí)候就為每個(gè)CPU分配一個(gè)localip：
這樣就可以在flow director下一條將目的IP為lip0的數(shù)據(jù)包發(fā)送到隊(duì)列0的規(guī)則，這樣應(yīng)答數(shù)據(jù)包就會(huì)被送到隊(duì)列0讓cpu0處理。這時(shí)CPU在對(duì)同一個(gè)連接兩個(gè)方向的數(shù)據(jù)包進(jìn)行處理的時(shí)候就是完全串行的一個(gè)操作，也就不需再對(duì)session結(jié)構(gòu)進(jìn)行加鎖保護(hù)。
針對(duì)上下文切換的問題，MGW設(shè)計(jì)有對(duì)CPU進(jìn)行分組，實(shí)現(xiàn)控制平面與數(shù)據(jù)平面完全分離的狀態(tài)，可以很好的避免數(shù)據(jù)平面做處理時(shí)被打斷的現(xiàn)象，如下圖所示：
同時(shí)，對(duì)數(shù)據(jù)平面CPU進(jìn)行隔離，實(shí)現(xiàn)控制平面進(jìn)程不會(huì)調(diào)度數(shù)據(jù)平面這組CPU；對(duì)數(shù)據(jù)平面線程進(jìn)行CPU綁定，實(shí)現(xiàn)每個(gè)數(shù)據(jù)線程獨(dú)占一個(gè)CPU?？刂破矫娴某绦蚓茉诳刂破矫娴腃PU上，如Linux kernel、 SSH等。
這里主要介紹在MGW集群、MGW單機(jī)及應(yīng)用服務(wù)器這三層實(shí)現(xiàn)高可靠的方法。
集群的高可靠主要涉及三部分：session同步、故障切換、故障恢復(fù)與擴(kuò)容。如下圖所示，MGW采用ECMP+OSPF的模式組成集群：
ECMP的作用是將數(shù)據(jù)包散列到集群中各個(gè)節(jié)點(diǎn)，再通過OSPF保證單臺(tái)機(jī)器故障以后將這臺(tái)機(jī)器的路由動(dòng)態(tài)的剔除出去，這樣ECMP就不會(huì)再給這臺(tái)機(jī)器分發(fā)流量，也就做到了動(dòng)態(tài)的failover。
session同步
傳統(tǒng)ECMP在算法方面存在一個(gè)嚴(yán)重問題，當(dāng)復(fù)雜均衡集群中節(jié)點(diǎn)數(shù)量發(fā)生變化時(shí)，會(huì)導(dǎo)致大部分流量的路徑發(fā)生改變，發(fā)生改變的流量到達(dá)其他MGW節(jié)點(diǎn)上，找不到自身的session結(jié)構(gòu)，就會(huì)導(dǎo)致大量的連接出現(xiàn)異常，對(duì)業(yè)務(wù)影響很大，且當(dāng)在對(duì)集群做升級(jí)操作時(shí)會(huì)將每個(gè)節(jié)點(diǎn)都進(jìn)行一次下線操作，這樣就加重了這個(gè)問題的影響。
傳統(tǒng)的解決方式是使用支持一致性hash的交換機(jī)，如下圖所示。
傳統(tǒng)的解決方式是使用支持一致性hash的交換機(jī)，當(dāng)節(jié)點(diǎn)發(fā)生變化的時(shí)候，只對(duì)發(fā)生變化的節(jié)點(diǎn)上面的連接會(huì)有影響，其他連接都會(huì)保持正常，但是支持這種算法的交換機(jī)比較少，并且也沒有完全實(shí)現(xiàn)高可用，因此需要做集群間的session同步功能，如下圖所示：
集群中每個(gè)節(jié)點(diǎn)都會(huì)全量的將自身session進(jìn)行同步，使集群中每個(gè)節(jié)點(diǎn)都維護(hù)一份全局session表。這樣一來，當(dāng)節(jié)點(diǎn)發(fā)生變化，流量路徑無論發(fā)生任何形式的改變，流量都可以找到自身的session結(jié)構(gòu)。
下面，故障切換與故障恢復(fù)及擴(kuò)容是在做集群間的session同步功能的整個(gè)過程中首要考慮的兩大問題。
故障切換
針對(duì)故障切換問題，當(dāng)機(jī)器發(fā)生故障后，交換機(jī)可立刻將流量切到其他機(jī)器，避免大量丟包的情況。經(jīng)過調(diào)研測試，MGW采用如下圖所示的操作方法，可做到升級(jí)操作0丟包，主程序故障0丟包，其他異常（網(wǎng)線等）會(huì)有一個(gè)最長500ms的丟包，因?yàn)檫@種異常需要靠自檢程序去檢測，而自檢程序的周期是500ms。
具體包括如下四方面內(nèi)容：
交換機(jī)側(cè)不使用虛擬接口。全部使用物理接口且服務(wù)器側(cè)對(duì)接口進(jìn)行斷電時(shí)，交換機(jī)會(huì)瞬間將流量切換到其他機(jī)器。通過100ms發(fā)兩個(gè)包的測試（客戶端和服務(wù)端各發(fā)一個(gè)），表明這種操作方法可實(shí)現(xiàn)0丟包。
半秒一次機(jī)器健康自檢。故障切換主要依賴于交換機(jī)的感知，當(dāng)服務(wù)器上出現(xiàn)異常，交換機(jī)感知不到時(shí)，交換機(jī)就無法進(jìn)行故障切換操作，因此需要一個(gè)健康自檢程序，每半秒進(jìn)行一次健康自檢，當(dāng)發(fā)現(xiàn)服務(wù)器存在異常時(shí)就對(duì)服務(wù)器執(zhí)行網(wǎng)口斷電操作，從而將流量立刻切走。
檢測到故障自動(dòng)給網(wǎng)口斷電。故障切換主要依賴于網(wǎng)口斷電操作且網(wǎng)卡驅(qū)動(dòng)是跑在主程序里面的，當(dāng)主程序掛掉以后，就無法再對(duì)網(wǎng)口執(zhí)行斷電操作。
主進(jìn)程會(huì)捕獲異常信號(hào)。針對(duì)主程序掛掉后，就無法再對(duì)網(wǎng)口執(zhí)行斷電操作的現(xiàn)象，主進(jìn)程會(huì)捕獲異常信號(hào)，當(dāng)發(fā)現(xiàn)異常時(shí)就對(duì)網(wǎng)卡進(jìn)行斷電操作，在斷電操作結(jié)束后再繼續(xù)將信號(hào)發(fā)給系統(tǒng)進(jìn)行處理。
故障恢復(fù)與擴(kuò)容
系統(tǒng)進(jìn)行故障恢復(fù)、擴(kuò)容操作時(shí)，會(huì)使得集群節(jié)點(diǎn)數(shù)量發(fā)生變化，進(jìn)一步導(dǎo)致流量路徑發(fā)生變化。
因?yàn)橐呀?jīng)發(fā)生變化的流量到達(dá)集群中原有節(jié)點(diǎn)時(shí)，原有節(jié)點(diǎn)都維護(hù)一個(gè)全局session表，所以這些流量是可以被正常轉(zhuǎn)發(fā)的；但當(dāng)流量到達(dá)一個(gè)新機(jī)器，這臺(tái)新機(jī)器由于沒有全局session表，這部分流量會(huì)全部被丟棄。
針對(duì)這個(gè)問題，MGW在上線后會(huì)經(jīng)歷預(yù)上線的中間狀態(tài)，此狀態(tài)下，MGW不會(huì)讓交換機(jī)感知到自己上線，所以交換機(jī)也就不會(huì)把流量切過來。
實(shí)現(xiàn)流程是首先MGW會(huì)對(duì)集群中其他節(jié)點(diǎn)發(fā)送批量同步的請(qǐng)求，其他節(jié)點(diǎn)收到請(qǐng)求以后會(huì)將自己的session全量同步到新上線的節(jié)點(diǎn)，新上線節(jié)點(diǎn)在收到全部session以后才會(huì)讓交換機(jī)感知到自己上線，這時(shí)交換機(jī)再將流量切入，就可正常被轉(zhuǎn)發(fā)。
這里需要提醒兩點(diǎn)：
其一：由于集群中并沒有一個(gè)主控節(jié)點(diǎn)來維護(hù)一個(gè)全局的狀態(tài)，如果request報(bào)數(shù)據(jù)丟失或者session同步的數(shù)據(jù)丟失的話，那么新上線節(jié)點(diǎn)就沒辦法維護(hù)一個(gè)全局的session狀態(tài)。但考慮到所有節(jié)點(diǎn)都維護(hù)著一個(gè)全局的session表，因此所有節(jié)點(diǎn)擁有的session數(shù)量都是相同的，那么就可以在所有節(jié)點(diǎn)每次做完批量同步以后發(fā)送一個(gè)finish消息，finish消息中帶著自己擁有的session數(shù)量。當(dāng)新上線節(jié)點(diǎn)收到finish消息以后，便會(huì)以自己的session數(shù)量與finish中的數(shù)量做對(duì)比。當(dāng)達(dá)到數(shù)量要求以后，新上線節(jié)點(diǎn)就控制自己進(jìn)行上線操作。否則在等待一定的超時(shí)時(shí)間以后，重新進(jìn)行一次批量同步操作，直到達(dá)到要求為止。
其二：在進(jìn)行批量同步操作時(shí)，如果出現(xiàn)新建連接，那么新建連接就不會(huì)通過批量同步同步到新上線的機(jī)器上。如果新建連接特別多，就會(huì)導(dǎo)致新上線機(jī)器一直達(dá)不到要求。因此，需要保證處于預(yù)上線狀態(tài)的機(jī)器能接收到增量同步數(shù)據(jù)，因?yàn)樾陆ㄟB接可以通過增量同步同步出來。通過增量同步和批量同步就可以保證新上線機(jī)器可以最終獲得一個(gè)全局的session表。
自動(dòng)化測試平臺(tái)
單機(jī)高可靠方面，MGW研發(fā)自動(dòng)化測試平臺(tái)，通過連通性和配置的正確性來判斷一個(gè)測試用例是否執(zhí)行成功，失敗的測試用例平臺(tái)可以通過郵件通知測試人員。在每次新功能迭代結(jié)束以后，都會(huì)將新功能的測試用例加到自動(dòng)化平臺(tái)里面，這樣在每次上線之前都進(jìn)行一次自動(dòng)化測試，可以大大避免改動(dòng)引發(fā)的問題。
在這之前，每次上線之前都需要進(jìn)行一次手動(dòng)的回歸測試，回歸測試非常耗時(shí)并且很容易遺漏用例，但是為了避免改動(dòng)引發(fā)新問題又不得不做，有了自動(dòng)化測試平臺(tái)以后，可提升回歸測試的效率和可靠性。
在應(yīng)用服務(wù)器靠性方面，MGW布設(shè)節(jié)點(diǎn)平滑下線和一致性源IP Hash調(diào)度器兩大功能。
節(jié)點(diǎn)平滑下線
節(jié)點(diǎn)平滑下線功能主要是為了解決當(dāng)用戶需要對(duì)RS進(jìn)行升級(jí)操作時(shí)，如果直接將需要升級(jí)的RS下線，那這個(gè)RS上存在的所有連接都會(huì)失敗，影響到業(yè)務(wù)。此時(shí)如果調(diào)用MGW的平滑下線功能，MGW就可以保證此RS已有連接正常工作，但不會(huì)往上面調(diào)度新的連接。
當(dāng)所有已有連接結(jié)束以后，MGW會(huì)上報(bào)一個(gè)結(jié)束的狀態(tài)，用戶就可以根據(jù)這個(gè)結(jié)束的狀態(tài)對(duì)RS進(jìn)行升級(jí)操作，升級(jí)后再調(diào)用上線接口讓這個(gè)RS器進(jìn)行正常的服務(wù)。如果用戶平臺(tái)支持自動(dòng)化應(yīng)用部署，那就可以通過接入云平臺(tái)使用平滑下線功能，實(shí)現(xiàn)完全自動(dòng)化且對(duì)業(yè)務(wù)無影響的升級(jí)操作。
一致性源IP Hash調(diào)度器
源IP Hash調(diào)度器主要是保證相同的客戶端的連接被調(diào)度到相同應(yīng)用服務(wù)器上，也就是說建立一個(gè)客戶端與應(yīng)用服務(wù)器一對(duì)一的映射關(guān)系。普通源IP Hash調(diào)度器在應(yīng)用服務(wù)器發(fā)生變化以后會(huì)導(dǎo)致映射關(guān)系發(fā)生改變，會(huì)對(duì)業(yè)務(wù)造成影響。
一致性源IP Hash調(diào)度器，保證在應(yīng)用服務(wù)器集群發(fā)生變化時(shí)，只有發(fā)生變化的應(yīng)用服務(wù)器與客戶端的映射關(guān)系發(fā)生改變，其他保持不變。
為了保證流量的均衡，首先在hash環(huán)上分配固定數(shù)量的虛擬節(jié)點(diǎn)，然后將虛擬機(jī)節(jié)點(diǎn)均衡的重分布到物理節(jié)點(diǎn)上，重分布算法需要保證：
未來，美團(tuán)點(diǎn)評(píng)將主要在這三方面發(fā)力：升級(jí)自動(dòng)化、集中式配置管理和降低運(yùn)維成本。
升級(jí)自動(dòng)化。最初自研MGW是為解決LVS的性能問題，在這些問題被解決之后，隨著業(yè)務(wù)的快速發(fā)展，IDC不斷增長，負(fù)載集群越來越多，像某個(gè)新IDC上線，一般都要上線兩套集群，分別用于IDC入口和內(nèi)部業(yè)務(wù)。
這樣的情況下，又涌現(xiàn)出更大的問題，如一個(gè)新功能發(fā)布時(shí)， 周期會(huì)非常長，所以需要實(shí)現(xiàn)自動(dòng)化升級(jí)。當(dāng)然，在完善監(jiān)控措施方面也要同步，對(duì)異常進(jìn)行監(jiān)控。
集中式配置管理。目前業(yè)務(wù)配置已經(jīng)實(shí)現(xiàn)集中式配置，未來希望機(jī)器的配置也能實(shí)現(xiàn)。
更低的運(yùn)維成本。實(shí)現(xiàn)自動(dòng)化升級(jí)，集中式配置最根本的目的就是降低運(yùn)維成本。
【嘉賓介紹】
王偉，美團(tuán)云技術(shù)專家。2015年加入美團(tuán)云，現(xiàn)任美團(tuán)云負(fù)載均衡網(wǎng)關(guān)MGW產(chǎn)品研發(fā)負(fù)責(zé)人，擁有多年負(fù)載均衡系統(tǒng)的一線實(shí)施經(jīng)驗(yàn)，主導(dǎo)并推進(jìn)了MGW的技術(shù)選型以及性能優(yōu)化工作。
聯(lián)系客服
