網(wǎng)上有很多介紹微服務(wù)架構(gòu)***實(shí)踐的指導(dǎo)手冊(cè)和博客文章。雖然這些信息都很有用，但是關(guān)于如何擴(kuò)展微服務(wù)的文章卻不多。在一些研究和大量理論探討下，本文介紹如何實(shí)現(xiàn)微服務(wù)的負(fù)載均衡。

關(guān)注邊緣

當(dāng)web應(yīng)用程序前端客戶(hù)端和基于微服務(wù)的后臺(tái)服務(wù)器通信時(shí)，前端是否需要知道所有可用的微服務(wù)實(shí)例?比如，客戶(hù)端真的需要知道提供web頁(yè)面數(shù)據(jù)的所有的五個(gè)服務(wù)么?答案當(dāng)然是不需要!

Sudhir Tonse，之前在Netflix工作，現(xiàn)在在Uber工作，在Scalable Mocroservices at Netflix大會(huì)上講述了邊緣服務(wù)的概念。邊緣服務(wù)作為微服務(wù)基礎(chǔ)架構(gòu)的門(mén)戶(hù)而存在。因此，對(duì)于前端客戶(hù)端需要知道哪個(gè)微服務(wù)，這個(gè)問(wèn)題，根據(jù)Sudhir的方案，每個(gè)客戶(hù)端只需要和一個(gè)邊緣服務(wù)直接通信就可以了。每個(gè)客戶(hù)端可以有獨(dú)占的邊緣服務(wù)。比如，Netflix服務(wù)于上千種設(shè)備類(lèi)型 -- 每種設(shè)備類(lèi)型都有獨(dú)占的邊緣服務(wù)作為其接入點(diǎn)。

類(lèi)似Netflix和Riot Games這樣的大廠商，他們都運(yùn)行在Amazon AWS上，使用彈性負(fù)載均衡(ELB)來(lái)確保邊緣服務(wù)隨時(shí)在線(xiàn)。

邊緣服務(wù)之外

每個(gè)進(jìn)入的請(qǐng)求都需要分析。多個(gè)fan-out請(qǐng)求被發(fā)送到構(gòu)成生態(tài)系統(tǒng)的微服務(wù)里。一個(gè)進(jìn)站請(qǐng)求平均會(huì)生成大概十個(gè)fan-out請(qǐng)求。Netflix每天會(huì)接收到近20億請(qǐng)求，會(huì)生成大概200億次內(nèi)部的API調(diào)用。

Netflix如何確保其微服務(wù)能處理這么大的壓力，并且保持24/7的可用性呢?再說(shuō)一次，負(fù)載均衡是解決之道。但是這次并不是通過(guò)ELB。有 500個(gè)不同的微服務(wù)，你就需要配置500個(gè)ELB!這正是Netflix的工具內(nèi)置負(fù)載均衡能力的原因。Netflix創(chuàng)建了很多庫(kù)和工具，它們可以很容易得互相集成。通過(guò)將所需庫(kù)直接集成到每個(gè)微服務(wù)里，就能將其自身注冊(cè)到所有受管理的服務(wù)里。

不要害怕邊緣服務(wù)

既然邊緣服務(wù)如此重要，那么邊緣服務(wù)發(fā)生故障就麻煩了，不是么?實(shí)際上，不會(huì)有問(wèn)題。原因之一，邊緣服務(wù)當(dāng)然也必須負(fù)載均衡。這意味著訪問(wèn)者根本就不會(huì)注意到邊緣服務(wù)的故障。其次，替代方案是什么?在monolithic應(yīng)用程序環(huán)境里，每個(gè)服務(wù)都像是一個(gè)邊緣服務(wù)，因此任何中央服務(wù)的故障 -- 沒(méi)有配置負(fù)載均衡時(shí) -- 都意味著整個(gè)系統(tǒng)的故障，對(duì)吧?

盡管如此，邊緣服務(wù)處于最為精妙的服務(wù)之中，因此的確需要特別的關(guān)注。

重中之重

必須要認(rèn)真考慮運(yùn)行邊緣服務(wù)來(lái)處理進(jìn)站流量。并且一定要對(duì)邊緣服務(wù)做負(fù)載均衡，無(wú)論你的云提供商的機(jī)制如何。所有內(nèi)部流量必須由自己的工具處理，因?yàn)檫@樣允許你使用最少的額外配置來(lái)運(yùn)行環(huán)境。因此，最終，微服務(wù)高效擴(kuò)展所要求的最重要的工具，不出意外，是負(fù)載均衡。

請(qǐng)保持關(guān)注

我會(huì)在下一篇博客里處理容器化的問(wèn)題。需要了解的是，Docker并不是容器概念之上的唯一解決方案。

原文鏈接：http://www.dockone.io/article/781