如何在web范圍內(nèi)實現(xiàn)微服務(wù)負載均衡
網(wǎng)上有很多介紹微服務(wù)架構(gòu)***實踐的指導手冊和博客文章。雖然這些信息都很有用，但是關(guān)于如何擴展微服務(wù)的文章卻不多。在一些研究和大量理論探討下，本文介紹如何實現(xiàn)微服務(wù)的負載均衡。
關(guān)注邊緣
當web應(yīng)用程序前端客戶端和基于微服務(wù)的后臺服務(wù)器通信時，前端是否需要知道所有可用的微服務(wù)實例?比如，客戶端真的需要知道提供web頁面數(shù)據(jù)的所有的五個服務(wù)么?答案當然是不需要!
Sudhir Tonse，之前在Netflix工作，現(xiàn)在在Uber工作，在Scalable Mocroservices at Netflix大會上講述了邊緣服務(wù)的概念。邊緣服務(wù)作為微服務(wù)基礎(chǔ)架構(gòu)的門戶而存在。因此，對于前端客戶端需要知道哪個微服務(wù)，這個問題，根據(jù)Sudhir的方案，每個客戶端只需要和一個邊緣服務(wù)直接通信就可以了。每個客戶端可以有獨占的邊緣服務(wù)。比如，Netflix服務(wù)于上千種設(shè)備類型 -- 每種設(shè)備類型都有獨占的邊緣服務(wù)作為其接入點。
類似Netflix和Riot Games這樣的大廠商，他們都運行在Amazon AWS上，使用彈性負載均衡(ELB)來確保邊緣服務(wù)隨時在線。
邊緣服務(wù)之外
每個進入的請求都需要分析。多個fan-out請求被發(fā)送到構(gòu)成生態(tài)系統(tǒng)的微服務(wù)里。一個進站請求平均會生成大概十個fan-out請求。Netflix每天會接收到近20億請求，會生成大概200億次內(nèi)部的API調(diào)用。
Netflix如何確保其微服務(wù)能處理這么大的壓力，并且保持24/7的可用性呢?再說一次，負載均衡是解決之道。但是這次并不是通過ELB。有 500個不同的微服務(wù)，你就需要配置500個ELB!這正是Netflix的工具內(nèi)置負載均衡能力的原因。Netflix創(chuàng)建了很多庫和工具，它們可以很容易得互相集成。通過將所需庫直接集成到每個微服務(wù)里，就能將其自身注冊到所有受管理的服務(wù)里。
不要害怕邊緣服務(wù)
既然邊緣服務(wù)如此重要，那么邊緣服務(wù)發(fā)生故障就麻煩了，不是么?實際上，不會有問題。原因之一，邊緣服務(wù)當然也必須負載均衡。這意味著訪問者根本就不會注意到邊緣服務(wù)的故障。其次，替代方案是什么?在monolithic應(yīng)用程序環(huán)境里，每個服務(wù)都像是一個邊緣服務(wù)，因此任何中央服務(wù)的故障 -- 沒有配置負載均衡時 -- 都意味著整個系統(tǒng)的故障，對吧?
盡管如此，邊緣服務(wù)處于最為精妙的服務(wù)之中，因此的確需要特別的關(guān)注。
重中之重
必須要認真考慮運行邊緣服務(wù)來處理進站流量。并且一定要對邊緣服務(wù)做負載均衡，無論你的云提供商的機制如何。所有內(nèi)部流量必須由自己的工具處理，因為這樣允許你使用最少的額外配置來運行環(huán)境。因此，最終，微服務(wù)高效擴展所要求的最重要的工具，不出意外，是負載均衡。
請保持關(guān)注
我會在下一篇博客里處理容器化的問題。需要了解的是，Docker并不是容器概念之上的唯一解決方案。
