做网站绿标,中国纪检监察网官网,免费asp网站源码,仿简书WordPress背景 Oceanus是美团基础架构部研发的统一HTTP服务治理框架#xff0c;基于Nginx和ngx_lua扩展#xff0c;主要提供服务注册与发现、动态负载均衡、可视化管理、定制化路由、安全反扒、session ID复用、熔断降级、一键截流和性能统计等功能。本文主要讲述Oceanus如何通过策略抽… 背景 Oceanus是美团基础架构部研发的统一HTTP服务治理框架基于Nginx和ngx_lua扩展主要提供服务注册与发现、动态负载均衡、可视化管理、定制化路由、安全反扒、session ID复用、熔断降级、一键截流和性能统计等功能。本文主要讲述Oceanus如何通过策略抽象、查询、渲染和分组动态更新实现HTTP请求的定制化路由。 随着公司业务的高速发展路由场景也越来越复杂。比如 团购秒杀要灵活控制压测流量实现线上服务单节点、各机房、各地域等多维度的压测。外卖业务要做流量隔离把北方地域的流量转发到分组a南方地域的流量转发到分组b。酒旅业务要对App新版本进行灰度让千分之一的用户试用新版本其他用户访问老版本。QA部门要通过请求的自定义参数指定转发分组构建稳定且高可用的测试环境。由于公司早期的业务场景相对比较简单所以均通过Nginx if指令支持。比如某业务要把来源IP为10.4.242.16的请求转发到后端节点10.4.232.110其它请求转发到后端节点10.4.232.111和10.4.232.112就可以进行如下配置 upstream backend_aaa {server 10.4.232.110:8080 weight10;
}
upstream backend_bbb {server 10.4.232.111:8080 weight10;server 10.4.232.112:8080 weight10;
}
location /abc {if($remote_ip 10.4.242.16) {proxy_pass http://backend_aaa; #路由到backend_aaa集群}proxy_pass http://backend_bbb; #路由到backend_bbb集群
}上述方式虽然不需要额外开发性能方面也接近原生的Nginx框架但是使用场景比较受限因为if指令仅支持比较简单的condition类型官方描述如下 如果该业务要把IP段10.4.242.16/34的请求转发到10.4.232.110时if指令勉强还可以支持。但对于上述的复杂业务场景if指令均无法支持。除此之外这种方式还存在以下两点不足 规则调整不支持动态化如果要把客户端10.4.242.16调整为10.4.242.17需要对Nginx进行reload而reload操作会使Nginx的并发能力下降业务高峰时甚至会导致请求504或502。指令坑太多if指令和set、rewrite指令等一起使用时很多时候会出现不符合预期的行为严重时甚至会导致段错误最好的方法就是避免使用。为了解决上述问题Oceanus开始探索如何实现HTTP流量的定制化路由。 业界调研 通过初步调研发现业界有一套开源的ABTestingGateway以下简称AB框架 由上图所示AB框架使用Redis存储策略数据key是Host字段value是策略对象包括策略类型、匹配区间和要分发的Upstream。策略的增删改查可以通过基于Nginx搭建的Web服务的API实现运行时根据请求的Host字段从lua-shared-dict或Redis获取关联的策略根据策略类型iprange/uidrange/uidsuffix/uidappoint选择对应的Lua脚本从请求中获取相关参数IP、UID查询是否匹配策略若匹配就修改请求的Upstream上下文完成分流的目的。 相比if指令的方式AB框架有下面两个优点 策略调整动态生效已有策略类型中的策略变更均可以通过HTTP API进行动态管理。分流策略丰富支持IP段、UID段等策略也可以通过新增策略类型对策略库进行扩展。由于AB框架只支持4种策略类型对于业务要根据请求Cookie、自定义header控制转发的情况均需要开发新的策略类型和发布上线。另外策略类型和业务场景紧密相关导致AB系统的扩展性极差很难快速支持新业务的路由需求。 无论是Nginx if指令还是AB框架要么需要reload重新加载才能生效要么无法支持某些业务场景下的分流需求所以都很难作为解决公司级分流框架的有效手段。针对它们所存在的不足Oceanus开发了一套应用级、高可扩展的动态分流框架不仅动态支持各种业务场景的分流需求而且保证了请求转发的性能下文将阐述我们如何解决分流机制的几个核心问题。 Oceanus定制化路由的核心设计实现 关于分流机制我们主要从以下四个方面来讲述 策略抽象合理定义策略结构适用尽可能多的业务场景。策略的高效查询接口粒度关联应用维度管理。运行时策略渲染渲染策略模板判断是否匹配策略实现动态路由。分组动态更新分组数据增删改均不需要reload。策略的结构定义 以AB框架为例只支持iprange、uidrange、uidsuffix、uidappoint四种场景对策略类型和匹配方式太具体化导致无法支持更多普适性的业务场景。从分流的本质出发即根据请求特征完成流量的定制化路由。结合Nginx if指令的几个组成部分条件判断依赖的变量、条件判断要匹配的value、条件表达式、匹配后要执行的proxy_pass一个策略必须要包含请求特征描述、定制化路由描述以及两者的关系描述。其中请求特征描述包含特征关键字、关键字的上下文传输方式定制化路由描述通过Upstream表示Upstream可以预先设置也可以动态指定两者的关系通过泛型表达式表示。那么一个策略就需要包含下面几个属性 name策略名没有实际意义可以根据业务场景进行定义。key分流时依赖的关键字比如要根据城市地域进行分发路由时key就是regionid。passway关键字在HTTP协议中的传输方式可以是Parameter、Cookie、header、body中的一种。condition表达式模板支持四则运算/取模、关系运算符、逻辑运算符等。group后端服务集群即匹配策略后转发请求的目标节点一般是策略所属应用集群中的部分节点。category策略类型如果为1表示某个服务的私有策略如果为2表示公共策略主要用于策略数据管理。switch策略开关用于控制当前策略是在线还是离线。graylist灰度列表用于策略变更的线上灰度校验。其中switch、graylist字段主要用于策略的上下线操作这里不做过多讨论。下面重点介绍上面的策略定义是如何表述业务场景的 备注应用apk1和apk2分别配置2个私有策略apk3使用公共策略。 如上图所示无论业务根据请求的哪些特征进行分流策略结构均可以支持。 以私有策略gray-deploy为例在Oceanus管理平台进行添加如下图所示 备注这里省略了策略的非核心字段比如switch、graylist等。 如何实现策略的高效查询 策略拓扑关系 分流策略分为私有策略和公共策略。私有策略是面向服务的而且和该服务创建的分组紧密相关。不同服务的私有策略完全独立可以相同也可以不同。一个服务可以配置多个私有策略也可以关联多个Host的LocationLocation之间的策略使用完全独立一个Location可以启用该服务的一个或者多个私有策略。如果通过Hostlocation_path直接关联策略数据不同Location关联同一个私有策略时会存在大量的数据冗余。所以我们通过服务标识appkey唯一标识一个应用服务关联具体的策略数据Hostlocation_path只关联当前Location使用的策略名列表策略之间支持指定顺序。 公共策略与具体服务无关策略名全局唯一可以使用策略名关联策略数据即可。综上策略的拓扑关系描述如下 如上图所示以应用apk1为例关联了两个Location接口分别为/api和/list总共部署了8个节点创建了2个分组ups-cq和ups-gray其中节点10.5.23.6和10.5.24.72属于分组ups-cq节点10.7.46.32和10.7.72.232属于分组ups-gray。应用配置了两个私有策略stress-testing和gray-deploy其中策略stress-testing被接口/api启用匹配策略的流量路由到分组ups-cq策略gray-deploy被接口/list启用匹配策略的流量路由到ups-gray。 运行时获取Location path Nginx在解析Location配置时通过不同的字段区分不同类型的Location没有记录配置中的Location path。如果要运行时获取一般有两种方式一种是根据相关字段逆向还原path另一种是为框架新增变量。由于Nginx在处理正则Location时对于是否忽略大小写的情况并没有做标记即解析的过程是不可逆的所以我们选择了第二种方式。在核心模块的变量数组ngx_http_core_variables中新增了内置变量记录下原始的Location path变量属性定义如下 {ngx_string(loc_mod), NULL, ngx_http_variable_loc_mod,0, NGX_HTTP_VAR_NOCACHEABLE, 0},
{ngx_string(loc_name), NULL, ngx_http_variable_loc_name,0, NGX_HTTP_VAR_NOCACHEABLE, 0}loc_mod和loc_name之间用一个空格符连接格式和Oceanus管理平台保持一致。 异步更新机制 为了保证运行时获取策略数据的高效性我们通过异步定时拉取把策略数据全量同步到本地的共享内存中。基于稳定性和灵活性的考虑我们采用了关系型数据库MySQL存储策略。 更新机制如下图所示 Oceanus在init_worker阶段随机选择某个worker进程嵌入timer。被选中的worker会异步非阻塞地从MySQL定时拉取策略数据。timer worker把拉取到的策略数据解析按照策略的拓扑关系更新到当前共享内存中的写缓存区完成更新后切换读写缓存区保证最新的策略立即生效。worker进程在处理请求时从当前共享内存中的读缓存区获取策略数据。为了解决timer worker和其它worker在读写策略数据时的竞态关系我们采用了双buffer机制实现了业务层策略数据的无锁读写。另外通过设置timer的时间为0保证在所有worker处理请求前策略数据已经在共享内存中完成初始化。 策略查询机制 查询算法如下图所示 worker进程从request上下文中获取请求的Host以及所匹配Location的location_path。根据Hostlocation_path到共享内存中查询所开启的策略名。如果是公共策略直接根据策略名去查询策略数据。如果是私有策略从request上下文获取Location关联的Upstream即应用标识appkey到共享内存读缓存区获取具体的策略数据。备注公共策略以”oceanus”开头区别于私有策略的命名。 运行时策略渲染 查询到请求开启的策略后Oceanus需要运行时判断是否匹配以私有策略为例执行流如下图所示 在rewrite phaseOceanus通过rewrite_by_lua_file嵌入回调触发请求处理进入分流框架的主流程。通过上面的策略查询机制获取请求的策略进行解析获取策略的key和passway。根据passway从请求对应的上下文获取key的value。用3获取到的value渲染策略的condition把condition中的占位符替换为value。基于Lua VM通过load计算condition的结果即true或false。从策略中获取condition的value和group数据。如果condition为true就用group覆盖请求的Upstream上下文否则不做处理。分组动态更新 分组列表的动态化是分流框架的重要一环。更新机制如下图所示 分组数据使用ZooKeeper存储变更通过watcher机制实现增量同步。Oceanus也会定时拉取进行全量同步。Oceanus把所有变更都通过本地的HTTP调用同步到Nginx内存。worker处理变更请求前会先抢锁读取共享内存中的消息队列同步其它worker进行的历史变更。把这次变更同步到当前worker的Upstream main上下文中完成当前worker的更新。把变更封装成消息加入到共享内存中的队列。其它worker通过timer或者自己处理变更消息前读取消息队列完成更新。总结 通过Oceanus分流机制在美团外卖、酒旅、到店餐饮等多个业务线的广泛使用基础架构部帮助业务同胞解决了多个定制化路由的需求比如服务set化、链路压测、灰度发布、泳道环境建设等等。目前Oceanus分流机制只关注了流量转发方向还不支持更复杂的转发动作比如根据策略调整请求的Parameter、header、Cookie也不支持根据请求的URL实现动态路由等未来我们还将逐一完善这些问题当然也欢迎大家跟我们一起交流共同进步。 作者简介 周峰美团高级工程师2015年7月加入美团基础架构部先后负责统一密钥管理服务、智能反爬服务和HTTP负载均衡目前主要负责HTTP服务治理Oceanus的相关工作致力于探索和研究服务的自动化、智能化、和高性能等方向。招聘信息 如果你对大规模分布式环境下的HTTP服务治理、分布式会话链路追踪等系统感兴趣诚挚欢迎投递简历至zhangzhitong#meituan.com。 参考文献 ngx_http_rewrite_modulehttps://nginx.org/en/docs/http/ngx_http_rewrite_module.htmlAB框架https://github.com/CNSRE/ABTestingGateway
