负载均衡在微服务架构中的典型应用场景
这里介绍两个负载均衡在微服务架构中的典型应用场景：
- 微服务的负载均衡
- API Gateway的负载均衡
微服务的负载均衡
首先，我们看一个简单的图：
图中主要包含三个部分：API Gateway、Service Registry Server、微服务。一般来说，为了提高并发处理能力，API Gateway和微服务都需要有多个instance。
基于上面的架构图，设想两个典型的场景：
- API Gateway收到一个请求，在完成认证和授权校验之后，需要把请求转发到微服务A去处理，而微服务A有多个instance，那么API Gateway应该以及如何把请求转发到微服务A的哪个instance呢？
- 微服务A收到一个请求，处理这个请求时它需要发一个同步请求给微服务B以获取一些数据，那么这时微服务A应该以及如何把请求发送到微服务B的哪个instance呢？
对于这两个问题，我们可以利用服务注册和服务发现模块（比如说zookeeper、eureka等）来实现。一般来说，服务注册和服务发现是微服务架构里面非常重要的一个模块，它主要是用于解决微服务架构内部大量微服务之间相互依赖的问题。通过这个模块，可以使微服务之间的相互依赖变得简单和容易维护；同时，也可以实现微服务的负载均衡。
这里的负载均衡属于客户端负载均衡（client side load balance），相比于服务器端负载均衡（server side load balancer），它有一个显著的优点，就是可以一定程度避免load balancer单点故障。
服务注册和服务发现模块是如何应用到上面两个场景的呢？
服务注册的角度：每个微服务的instance在启动阶段就自动地把自己的IP和端口注册到Service Registry Server；当shutdown的时候，Service Registry Server就自动地把这个instance的IP和端口删除掉。
服务发现的角度：
针对场景1，API Gateway首先去Service Registry Server获取微服务A所有的instance列表（IP+端口），然后利用某种负载均衡策略选择一个instance，这时就可以直接把请求转发到微服务A的这个instance。
针对场景2，流程也是类似，微服务A首先去Service Registry Server获取微服务B所有的instance列表（IP+端口），然后利用某种负载均衡策略选择一个instance，这时就可以直接把请求转发到微服务B的这个instance。
从负载均衡角度可以看到，负载均衡的逻辑是运行在客户端的，顾名思义，这就是一种典型的客户端负载均衡。回到上面提到的，客户端负载均衡可以避免load balancer的单点故障，如何实现呢？以上面场景2为例，微服务A获取到微服务B的所有instance列表之后可以缓存的内存中，接下来当微服务A请求微服务B时，都直接从内存中获取微服务B的所有instance列表，这样即使Service Registry Server挂了，也不影响微服务A和微服务B正常通讯。
API Gateway的负载均衡
同样的，我们先看一个图：
其实，虽然这里说的是API Gateway的负载均衡，但也同样适用于传统的monolith应用。
关于如何设计这一层面的负载均衡，推荐大家阅读下面几篇文章，个人觉得介绍非常好。
这里只着重聊聊下面几点：
1. sticky session
对于传统的monolith应用，当遇到性能瓶颈时，常常采取的方案就是水平扩展（往往也是最直接有效的方式），直接增加instance的数量，一般来说monolith应用都是把session信息维护在内存中，所有当一个用户登录了之后，load balancer就需要把同一用户的后续请求转发到之前维护了session的instance，否则就会出现用户重新登陆的情况，这就是sticky session。
sticky session有时候会有一些问题，就是当某个instance挂掉时，load balancer没有办法failover。cloud foundry的cf-router也是这个原理。
所以在很多微服务架构中，就会把session信息存在session store（比如redis）里面，比如redis，这样就不需要依赖sticky session。
2. 高可用
server side load balance，相比上面提到的client side load balance，一个非常重要的点，就是要避免单点故障，保证load balancer的高可用。上面推荐的文章（关于负载均衡的一切）非常全面的介绍了如何实现load balancer的高可用，包括nginx、keepalived、lvs/f5、DNS轮询等方案。
基于此，那么有人要问了，如何保证DNS服务的高可用呢？其实，DNS服务本身就不是一个单点系统，它是一个分布式系统，某个域名的信息会分布到各级DNS服务器上（尽管可能会有更新时延），这样客户端的域名解析请求就分流了。
另外，针对微服务架构中的某一个微服务，可以通过水平扩展来实现高并发；但是对于某一个微服务的数据库，如何实现高并发呢？通常来讲就是分库，把数据按某种策略切分，存放在不同的数据库中，以达到分流的作用。