category: Guides
redirect_from:
- /docs/v0.4.0/guides/usages/
- /docs/latest/guides/usages/
title: “使用场景”
sort_title: “2”
Orange是基于插件设计的，基本思想是通过实现各种插件灵活的在Nginx的各个执行阶段进行逻辑处理。
Orange提供的默认插件功能如下：
-
全局的监控插件，可统计API访问情况、Nginx连接情况、流量统计、QPS等
-
自定义监控，可根据配置的规则筛选监控项，统计其各个指标
-
rewrite插件，可通过UI配置各种rewrite策略，省去手写nginx rewrite，然后重启的麻烦
-
redirect插件，实现请求重定向功能
-
HTTP Basic Authorization，为API动态配置鉴权
-
简单地WAF应用防火墙，可提取各个请求参数，通过各种匹配规则甄别需要禁止的流量
-
分流插件，可分为三个使用场景：
- 作为proxy，如代理后端的多个HTTP应用
- 用于AB测试
- 用于动态分流，API版本控制等
其它插件，用户可根据具体需要按规范编写即可。
典型使用案例
以下使用案例对于成体系、各职责/配置比较健全的团队来说可能并不存在，但仍可能具有一些参考意义。
Case 1
想象下面的场景：
-
原来的Nginx配置文件中包含大量的rewrite语句，每次更改需要重启
-
有时候rewrite特别难写，比如我需要把来自于某个Host并且uri以
/user开头的请求rewrite到以/some_host/user开头，如果是在Nginx里写，一般要通过if判断Host，再rewrite，可能需要多次调试和reload才能成功。这对于有经验的运维或是开发可能并不是难事，但对刚接手的新人或是不熟悉Nginx的运维人员来说，就是一件头疼事儿了 -
再想像一下，如果再加上几个限制条件，比如需要来自某些IP访问某个Host并且Header里含有某个标识变量的请求执行某个rewrite，Orz…
-
原来对于某个移动端API，客户端已经发布了很多个版本，每个版本的该API内部实现可能都不太一样，如果需要后端去兼容这个更改，可能就需要在代码中添加大量的
if/else，或者给同一个职责的API取不同的名字(其它更好的实践暂且不表)。长此以往，API的版本管理可能就是一团乱麻
这时，通过Orange的rewrite/redirect插件就能很方便的解决这个问题，并且实时生效无需重启或是reload：
-
orange的rewrite/redirect规则配置非常简单，基本上只需要了解一些Nginx/lua正则表达式的知识即可解决上述场景中提到的问题，无须更改Nginx配置文件
-
orange可以提取请求中的各个变量或是标识，比如URI、Header、QueryString、Referer、Host等等，然后根据这些提取出来的值做匹配规则运算，匹配成功的就可以执行各种rewrite、redirect操作将uri变得更有条理，也更好管理。
Case 2
在内部系统中，大量模块或者异构的子系统之间都是通过HTTP交互的，这时不可避免的要引入一个七层负载，选型最多的基本上也就是Nginx了。对于内部网关的管理，可能存在的问题：
-
由于是内部使用，运维对外网隔离比较严格，但内网隔离性可能就会略差，这是就可能发生内部服务API被调用者误调用或者乱调用的问题
-
为了使用方便，内部的一些通用API是不需要鉴权的，但当需要排查问题的时候，如果有多个使用方，很难甄别到底是谁调用的
Orange提供的WAF插件可以解决这个问题：
-
如对API请求做白名单限制，白名单可以以比较常用的IP、Header作为判断条件
-
Orange提供的默认插件都有Log功能，可将某条匹配规则的Log开启，这样出现问题时就可以根据匹配规则的Log，然后结合Nginx本身的访问日志来甄别流量来源了
Case 3
应用的AB测试或者流量切分，虽然业界已经有很多方案可供参考，各个公司或团队也有相应实现，Orange给出了另一种动态解决方案
-
由自定义的条件表达式选择出某部分流量，动态分流到指定的upstream server，结束后只需要关闭这条规则即可
-
线上问题排查，如果某个API出了问题，可临时添加一条规则，将测试账户的流量打到某台机器或者某个新的bug fix的upstream server，待排查完后清除规则、升级bug fix版本