网上有很多介绍微服务架构最佳实践的指导手册和博客文章。虽然这些信息都很有用，但关于怎样扩展微服务的文章却不多。在一些研究和大量理论探讨下，本文介绍怎样实现微服务的负载均衡。

　　关注边缘

　　当web应用程序前端客户端和基于微服务的后台服务器通信的时候，前端是不是需知道所有可用的微服务实例?比如，客户端真的需知道提供web页面数据的所有的五个服务么?

　　答案当然是不需要!Sudhir Tonse，之前在Netflix工作，现在在Uber工作，在Scalable Mocroservices at Netflix大会上讲述了边缘服务的概念。边缘服务作为微服务基础架构的门户而存在。因此对于前端客户端需知道哪个微服务，这个问题，根据Sudhir的方案，每个客户端只需要和一个边缘服务直接通信即可。每个客户端可有独占的边缘服务。如Netflix服务于上千种设备类型 -- 每种设备类型都有独占的边缘服务作为其接入点。

　　类似Netflix和Riot Games这样的大厂商，他们都运行在Amazon AWS上，使用弹性负载均衡(ELB)来确保边缘服务随时在线。

　　不要害怕边缘服务

　　既然边缘服务这么重要，那么边缘服务发生故障就麻烦了，不是么?实际上，不会有问题。原因之一，边缘服务当然也必须负载均衡。这意味着访问者根本就不会注意到边缘服务的故障。其次，替代方案是什么?在monolithic应用程序环境里，每个服务都像是一个边缘服务，因此任何中央服务的故障 -- 没配置负载均衡的时候 -- 都意味着整个系统的故障，对吧?

　　尽管这样，边缘服务处于最为精妙的服务之中，因此的确需特别的关注。

　　边缘服务之外

　　每个进入的请求都需分析。多个fan-out请求被发送到构成生态系统的微服务里。一个进站请求平均会生成大概十个fan-out请求。Netflix每天会接收到近20亿请求，会生成大概200亿次内部的API调用。

　　Netflix怎样确保其微服务能够处理这么大的压力，且保持24/7的可用性呢?再说一次，负载均衡是解决之道。但这次并非通过ELB。有 500个不同的微服务，你就需要配置500个ELB!这正是Netflix的工具内置负载均衡能力的原因。Netflix创建了很多库和工具，它们可以很容易得互相集成。通过将所需库直接集成到每个微服务里，就能将其自身注册到所有受管理的服务里。

　　重中之重

　　必须要认真考虑运行边缘服务来处理进站流量。并且一定要对边缘服务做负载均衡，无论你的云提供商(如阿里云)的机制怎样。所有内部流量必须由自己的工具处理，因为这样允许你使用最少的额外配置来运行环境。所以最终，微服务高效扩展所要求的最重要的工具，不出意外，是负载均衡。