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