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