一个可快速落地的微服务网关架构实现

随着应用与技术越来越复杂，无论研发过程或者是运维过程都面临更多困难，为了应对上述困难，马丁提出了微服务概念，这几年微服务应用逐渐流行开来。微服务应用建设，应当是先建设微服务基础设施，然后在这个基础上拆分应用，可见微服务基础设施建设是实施微服务的核心，而微服务网关就是其中最重要的微服务基础设施之一。

传统网络层的网关主要作用是链接和协议转换，而微服务网关处于应用层，其主要功能是路由转发，当然在微服务环境中，网关作为外部请求和内部系统的桥梁（外部网关）或者内部系统之间转发的桥梁（内部网关），一定会面临很多新的挑战。比如：

1. 请求流量挑战，流量随着时间推移不断增长，或者流量的峰值超出系统处理极

2. 系统稳定性，由于网关关联了多个系统，无论哪个系统出现延迟或者异常都可能导致网关不稳定

3. 微服务网关职责划分，正确的职责划分可以优化整个微服务体系，使得整个系统最优雅

微服务网关分析

从外部环境看微服务网关面对上述挑战，因此需要深入分析。首先面对流量的挑战，导致流量变化可能是正常请求也可能是异常请求，这时需要系统自动感知到，如果是异常流量而且接近峰值时，能自动降级或者限制该类请求，如果是正常请求则应该自动扩容，当流量下降后能自动缩容。

其次面对稳定性挑战，导致网关不稳定可能是网关自身问题，也可能是网关依赖的其他系统，因此在网关设计中要加入异常处理、熔断、监控以及故障转移，从程序到运维多个层面解决稳定性问题。

最后面对职责划分挑战，需要从多个视角收集网关的功能点，其核心功能是路由，辅助功能有：数据安全加解密、业务无关数据验证，另外网关还可以实现通用业务功能例如计费、用户验证等。

架构设计原则与方法

微服务网关设计与其他系统设计一样，需要按照关注点不同进行分层、分离，关注点分离技术是人们广泛使用的解决复杂问题的一种系统思维方法。通过上面的分析可知微服务网关包含了核心功能还包含了大量的其他功能，涉及到运维和开发过程，既包含功能要求也包含非功能要求，因此是个复杂的系统。

为了使系统清晰，把微服务网关分成四层，从下往上分别是运维层、服务治理层层、非核心功能层、核心功能层。在每一层内部再根据不同的关注点分离，例如在服务治理层又分离成限流、降级、监控三个部分。

微服务网关的架构设计方法，根据微服务网关面对的并发性，以及为了维持自身的高可用性，所以采用以下的方法：监控、负载均衡、限流与降级、故障转移、集群、自动扩缩容、熔断，才能满足系统设计要求。

架构设计与实现

网关总体架构设计，如上图。上面两层给出了微服务网关的路由功能和路由表管理，下面两层从运维和服务治理指出了如何实现高可用高性能的微服务网关，微服务网关的部署图如下，包括了注册中心，网关、消息队列和网关后台管理系统，图的下面部分是网关的下游微服务，接下来分别就主要技术点进行阐述。

负载均衡

在当前微服务技术体系中 springcloud 是最成熟的，ribbon 是其实现客户端负载均衡的组件，其原理是服务提供者和服务消费者都注册到注册中心，当服务消费者发起向服务提供者的请求时，先从注册中心拿到一组服务提供者列表，然后利用 ribbon 实现的负载均衡策略，访问某个服务提供者。

1、引入 jar

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>

</dependency>

2、在启动类中添加注解 @LoadBalanced、@RibbonClient 等

3、创建 ribbon 的负载均衡策略类，可以实现随机策略、顺序策略等 7 中策略，可以根据业务需要选择实现方式。

策略名 策略描述 BestAvailableRule 选择一个最小的并发请求的 server AvailabilityFilteringRule 过滤掉那些因为一直连接失败的被标记为 circuit tripped 的后端 server，并过滤掉那些高并发的的后端 server（active connections 超过配置的阈值） WeightedResponseTimeRule 根据响应时间分配一个 weight，响应时间越长，weight 越小，被选中的可能性越低。 RetryRule 对选定的负载均衡策略机上重试机制 RoundRobinRule roundRobin 方式轮询选择 server RandomRule 随机选择一个 server ZoneAvoidanceRule 复合判断 server 所在区域的性能和 server 的可用性选择 server 熔断器

在微服务网关应用场景中，可能由于硬件、软件等造成网关依赖的服务不可用，一般刚开始是局部的，小规模的，如果不加处理，故障影响的范围越来越大，最终导致了全局性的后果，在网关应用中，网关会出现同步等待，最终网关资源被占用耗尽。针对这类依赖服务不可用问题，一般采用熔断机制解决这类问题。Hystrix 是 Netflix 公司设计的针对交互时超时处理和容错的类库，它具有保护系统的能力。

Hystrix 是由熔断器和线程池组成，用户请求是先到熔断器，熔断器根据开关状态，如果开关是打开状态，则不调用线程池，而调用降级服务, 熔断器的三个状态根据调用情况进行转换，熔断器根据状态产生对应的动作。

关闭：熔断器关闭状态，调用失败次数积累，到了阈值（或一定比例）则启动熔断机制；

打开：熔断器打开状态，此时对下游的调用都内部直接返回错误，不走网络，但设计了一个时钟选项，默认的时钟达到了一定时间（这个时间一般设置成平均故障处理时间，也就是 MTTR），到了这个时间，进入半熔断状态；

半开：半熔断状态，允许定量的服务请求，如果调用都成功（或一定比例）则认为恢复了，关闭熔断器，否则认为还没好，又回到熔断器打开状态；

Hystrix 的线程隔离作用：Hystrix 在用户请求和服务之间加入了线程池，用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，则会进行降级处理，用户的请求不会被阻塞，至少可以看到一个执行结果（例如返回友好的提示信息），而不是无休止的等待或者看到系统崩溃。

限流

网关总会面临高并发，限流就是在高并发情况下，限制请求总数，对于超出限流阈值的请求采用拒绝服务、降级服务手段，保证负荷不超过系统处理的上限。限流采用的算法包括计数器、漏斗桶和令牌桶。算法比较如下：

算法 优缺点 原理 滑动窗口计数器 不能满足波动处理 滑动窗口时间内发送数量 - 滑动窗口时间内接受数量<= 滑动窗口大小 漏斗桶 只能按固定速率处理请求 发送到漏斗中的请求不受限制，但是从漏斗中获取请求的速率是固定的 令牌漏斗桶 可以处理突发流量，放入令牌的速率可以调整 令牌桶大小固定，以一定速率产生令牌放入桶中，如果消耗令牌速率小于放入令牌速率，则填满令牌桶后的令牌会被丢弃

Bucket4j 是一款优秀的限流组件，他可以实现针对某个维度在集群中限流，例如，针对某个客户的一个特定接口请求限流，该客户的该接口请求可能被路由到集群中不同节点上，利用 Bucket4j 可以计算在集群中的总请求，进而实现限流。它还有其他优点例如可以通过插件实现日志和监控，有同步和异步接口，可以实现多个维度限流。

监控

网关系统是所有业务系统的门户，是核心系统，网关系统可靠运行是衡量网关系统建设成败的关键因素，通过系统监控可以及时了解系统运行状态，以及可以及时发现系统运行异常，因而系统监控可以提升网关的可用性。系统监控功能主要包括：监控数据采集、监控数据分析展现、监控报警等。

在网关系统中监控数据采集主要包括：接口成功、失败情况，为了使监控功能和网关核心功能松耦合，采用 metris 异步埋点技术或者用通过日志文件埋点等，数据分析可以采用 flume 收集日志 +kafka+storm（flink）等技术进行实时计算分析，通过计算分析可以了解系统运行状态，发现系统异常情况并进行报警。

安全

由于网关是和外部客户交换数据，在公网上传输数据，因此需要保证数据安全传输，在网关中采用数据加密和签名机制，加密保证数据不会泄密，签名保证数据交互双方身份不可抵赖以及数据的完整性。数据加密和签名的过程和原理如下。

签名过程：

• 发送者：提取消息 m 的消息摘要 h(m)，并使用自己的私钥对摘要 h(m) 进行加密，生成签名 s。

• 发送者将签名 s 和消息 m 一起，使用接收者发过来的公钥进行加密，获得密文 c，发送给接收者。

验签过程：

• 接收者接受到密文后，用自己的私钥对其解密，获得明文消息 m 和签名 s。

• 接收者使用 client 的公钥解密数字签名 s，获得消息摘要 h(m)。

• 接收者使用相同的方法提取消息 m 的消息摘要 h(m) 与上一步解密得到的 h(m) 进行比较，如果相同则验签成功。

故障转移

网关访问下游服务集群，例如下游某个服务，分别部署在两个节点，如果其中一个节点服务异常，那么是希望网关能否发现有一个节点异常，并且能够不再请求异常节点，而是全部访问正常节点服务，这就是希望实现的故障转移。

由于微服务网关是采用 springcloud 的技术体系，所以可供选择的故障转移技术有 erueka 或者 consul。

总结

本文从问题出发，从系统高可用性和高性能出发，系统的总结了微服务网关架构的技术要点，并且对相关技术点的原理和应用做了概要描述，限于篇幅和个人技术水平没有给出详细描述，希望给研究应用网关的同学起到抛砖引玉的作用。

作者介绍

徐进，武汉大学计算机硕士，近 20 年从业经验，近 10 年一直从事软件架构和系统架构，热爱技术，现就职于拍拍信数据服务公司，从事架构师工作，前期对软件复用有设计有兴趣和和应用经验，最近几年对分布式架构和大数据架构有兴趣和应用经验。

喜欢技术总结和分享，之前在中文核心期刊《计算机应用》和省级优秀科技《电脑知识与技术》上发表过架构设计类文章。

---

当前分布式系统是大势所趋，Google、Facebook 等大型系统架构也是以分布式系统架构为基础。过去二十年，整个分布式系统架构演进史是从 C/S→B/S→分布式系统→网格计算→云计算，包括目标、定位、场景，影响深远。未来，如何从全球多域的角度去规划分布式架构呢？

下个月深圳 ArchSummit 架构师峰会邀请了 Pinterest 武永胜、百度王耀、菜鸟网络黄浩、美团宋斌来分享他们的一手分布式系统设计经验，这些内容一定可以助你一臂之力。