转载

拍拍信微服务网关实践分享

背景：

拍拍信作为一家专业的数据服务公司，承载着百亿级数据量，每天支撑着千万级的调用量，对数据的安全、用户需求响应时效、系统的稳定都有着极其严格的要求，在此大前提下，拍拍信踏入微服务化之路。

截止发稿，拍拍信在微服务的道路上已经走过一年有余，90%以上的服务已经投产，整个微服务生态体系也逐渐发挥出不凡的表现，比如快速自动化水平扩展、无值守升级、流量零损耗发布等。

拍拍信网关概述

拍拍信微服务基于Spring Cloud实施落地，由于其已经集成了Netflix Zuul，也符合拍拍信的技术栈, 能满足快速应用和二次开发，其官方对Zuul的定义如下：

Zuul is the front door for all requests from devices and web sites to the backend of the Netflix streaming application. As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency and security. It also has the ability to route requests to multiple Amazon Auto Scaling Groups as appropriate.

简单来说，Zuul是所有请求的前端入口，并转发到后端服务，作为一个边缘服务应用，Zuul支持动态路由、监控、弹性和安全。它类似于 Servlet 中过滤器（Filter）的概念，提供了四种过滤器的 API，分别为前置（Pre）、后置（Post）、路由（Route）和错误（Error）四种处理方式，附上标准流程，如下图：

拍拍信微服务网关实践分享

但是Zuul的天生不足也比较明显，需二次开发才可应用于生产环境，首先，它只是一个框架，并不具有运营能力，投产的系统往往都需要一个管控后台，其次因为它是边缘服务应用，所以必须做到稳定、持续服务，也就意味着它是长驻服务，不能因为内部业务升级、新开业务等因素重启网关等。不足之处具体表现为：

● ZUUL自身提供的Monitor&Tracer功能薄弱，无法需足业务需要；

● Spring Cloud虽然集成了ZUUL，但路由表为静态配置，需要运行时增加、修改；

● 不具有http报文拦截、过滤、转换功能；

● 网络属性配置（如：Socket Timeout）没有灵活的API，且是静态配置（这个是Ribbon的锅）；

● 本身并没有提供鉴权认证机制、数据安全等功能；

● 运行指标监控、告警功能缺失，虽然可以配套Turbine使用，但也需要二次开发。

最终，经二次开发改进之后的功能模块包括如下：

拍拍信微服务网关实践分享

整体架构如下：

拍拍信微服务网关实践分享

从业务角度出发

拍拍信网关研发之初，实际业务中的一些痛点问题及需求：

● 服务通讯协议多样化，需要业务各自实现，导致代码重复写；

● 接口缺少完善的监控，发现不及时，问题排查慢等，造成业务受损；

● 接口调用记账收费无统一入口，会产生多记、漏记、错记等问题；

● 接口流量突增，影响其他客户的调用，导致用户满意度下降；

● 内部接口的发版等变更时会导致外部接口的调用失败，接口稳定性下降；

● 接口还会受到一些DDoS及漏洞扫描及爬虫等非法访问对网关安全提出新的要求。

Zuul二次开发&业务支撑

● 路由配置管理：

当业务团队数量增多，业务系统数量增加，不断的持续开发、升级、发版、新业务线的开通上生产，完全无法控制API数量，假如每改动一个API、新增一个API都需要配置路由并重启生效，而此时用户的调用还没有结束，强制重启会导致用户方异常，即使可以采用Nginx、Haproxy负载方案解决问题，那么也要配置路由、重启网关，可想系统得多么糟糕。

我们采用将路由信息持久化到数据库中的方案，系统启动时将路由配置加载到内存中，并采用推拉结合的方式，运行时更新内存中数据，达到真正的动态路由。

拍拍信微服务网关实践分享

需注意：系统启动和加载路由配置的先后顺序，要保证系统启动成功时，配置信息已经加载完成，否则因为路由配置不全，用户请求已经到达，会导致部分请求失败。

● 路由配置发布：

很多公司在服务升级发版时，都非常小心谨慎，如履薄冰，即使在线下经过充分测试，也难免到生产环境出事故，为了降低影响面，拍拍信网关提供了路由配置灰度发布、一波流发布、版本回滚功能，可以分批次通过RocketMQ消息通知的方式发布，指定某几个服务节点生效，一旦发现监控指标异常，可以利用版本回滚功能回退到之前版本。

拍拍信微服务网关实践分享

● 协议适配&报文检查、过滤、转换：

做为一家数据服务公司，接口协议类型也是多样化的，如：JSON、XML、HTTP，为了简化业务开发，数据在网关层利用Zuul Filter对报文统一处理，格式化为key/value对后再转发到下游，使内部业务开发标准化。

提供边缘服务，要确保数据正确性，拍拍信网关提供了严格的数据校验配置，比如：数据类型、数据长度、值大小、枚举、时间区间、正则表达式、脚本化支持等，可以滤掉非正常请求，避免内部业务受到冲击。

此外，即便用户传入数据都正确，一些特定业务场景下，仍不能直接将数据转到下游，比如用户传入的参数叫idCard，但是下游需要的参数名是idNumber，这就需要用到参数名称转换功能，甚至可以调用Groovy脚本运算产生参数值，或者添加、修改HTTP请求头信息等。除非下游需要的参数及参数值就是用户传入的数据，这种情况下，我们支持一种面向接口维度的“透传”工作模式。同请求报文处理一样，响应报文也具有“透传”和“转换”功能，以达到接口标准化目的。

● 网络属性配置管理：

Spring Cloud集成的Zuul，提供了socket-timeout-millis配置项，Ribbon提供了ReadTimeout配置项，如果要面向API且可以运行时动态调整，原生静态配置达不到需求。

拍拍信微服务网关实践分享