网上有很多介绍微服务架构***实践的指导手册和博客文章。虽然这些信息都很有用，但是关于如何扩展微服务的文章却不多。在一些研究和大量理论探讨下，本文介绍如何实现微服务的负载均衡。
关注边缘
当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并不是容器概念之上的唯一解决方案。
