fix doc

ReadMe.md

@@ -1,44 +1,44 @@
-# WupProxyServer简介
+# TarsGateway简介
 ---
 # 简介
-WupProxyServer是基于taf框架开发的一套通用api网关，请求为http协议，后端同时支持taf-wup&tars-jce协议、tars-json协议、http协议。
+TarsGateway是基于tars框架开发的一套通用api网关，请求为http协议，后端同时支持tars-tup&tars-tars协议、tars-json协议、http协议。
 
 # 功能介绍
 ## 1. 代理类型的判断
-WupProxyServer 是根据请求host+url 判断当前请求是什么类型的请求，具体host和url通过配置设定。配置及对应逻辑说明如下：
+TarsGateway 是根据请求host+url 判断当前请求是什么类型的请求，具体host和url通过配置设定。配置及对应逻辑说明如下：
 
 [comment]: <***配置说明***：>
 * 配置所在域： /main/base
-* wup_host: wup请求对应的host，如果请求host在wup_host列表中，那么会进行后面的wup&&json请求的判断。如果列表配置为空，那么也会判断，这里支持前通配符。
-* wup_path: wup或jce请求的基础path，默认为 /wup ;
+* tup_host: tup请求对应的host，如果请求host在tup_host列表中，那么会进行后面的tup&&json请求的判断。如果列表配置为空，那么也会判断，这里支持前通配符。
+* tup_path: tup或tars请求的基础path，默认为 /tup ;
 * json_path: json 请求的基础path，默认为 /json ;
-* monitor_url: WupProxyServer 的监控地址，用来远程判断服务是否存活。
+* monitor_url: TarsGateway 的监控地址，用来远程判断服务是否存活。
 * 配置举例：
 ```
     <main>
         <base>
-            #wup_host 如果不配置，那么所有host开头的，且没有path或者path为 / ， 也判断为 wup 请求
-            wup_host=prx.wup.whup.com|prx2.wup.whup.com|*.prx.upchina.com
-            wup_path=/wup
+            #tup_host 如果不配置，那么所有host开头的，且没有path或者path为 / ， 也判断为 tup 请求
+            tup_host=prx.tup.whup.com|prx2.tup.whup.com|*.prx.upchina.com
+            tup_path=/tup
             json_path=/json
             monitor_url=/monitor/monitor.jsp
         </base>
     </main>
 ```
 
-## 2. TARS-WUP && TARS-JCE 协议代理
-TARS-WUP协议代理，必须为post请求类型，路径为/wup，body内容为BasePacket包Jce序列化的内容。WupProxyServer收到包后，去反序列化body的内容解析出BasePacket包，然后根据其中的sServantName在配置中查找真是的taf服务的obj。如果配置auto_proxy=1，那么客户端调用时 sServantName 可以填真实的obj地址。这里建议：直接对C外网暴露的WupProxyServer，建议配置auto_proxy=0，避免内网的服务都直接对外暴露。另外，proxy的配置还可以支持 sServerName:sFuncName 的配置，会优先根据, 这种类型配置优先级高于只配置sServerName 类型的配置。 proxy配置如下：
+## 2. TARS-tup && TARS-tars 协议代理
+TARS-tup协议代理，必须为post请求类型，路径为/tup，body内容为BasePacket包tars序列化的内容。TarsGateway收到包后，去反序列化body的内容解析出BasePacket包，然后根据其中的sServantName在配置中查找真是的tars服务的obj。如果配置auto_proxy=1，那么客户端调用时 sServantName 可以填真实的obj地址。这里建议：直接对C外网暴露的TarsGateway，建议配置auto_proxy=0，避免内网的服务都直接对外暴露。另外，proxy的配置还可以支持 sServerName:sFuncName 的配置，会优先根据, 这种类型配置优先级高于只配置sServerName 类型的配置。 proxy配置如下：
 ```
     <proxy>
         hello = TestApp.HelloServer.HelloObj
         hello:sayhello = TestApp.Hello2Server.HelloObj
     </proxy>
 ```
-经过WupProxyServer调用后端服务，客户端请求的http头，可以通过配置采用taf的context进行http头的透传，默认情况下，REMOTE_IP （客户端ip）都会透传给后端。配置为 filterheaders，可以是多个，比如：
+经过TarsGateway调用后端服务，客户端请求的http头，可以通过配置采用tars的context进行http头的透传，默认情况下，REMOTE_IP （客户端ip）都会透传给后端。配置为 filterheaders，可以是多个，比如：
 ```
     filterheaders = X-GUID|X-XUA
 ```
-调用后端taf服务时，WupProxyServer默认采用taf自己的缺省轮训负载均衡策略（robin轮训），也可以通过配置自定义hash策略，hash_type为1时，根据客户端请求id进行tafhash调用; hash_type为2时，根据指定http头(配种中的httpheader)进行tafhash调用，比如http头中的 X-GUID，注意这里选择httpheader需要合理，避免过于集中某个值导致负载均衡过于不均匀的现象； hash_type为3时，则根据客户端的ip进行tafhash调用。 如果obj后面没有配置hash_type，那么采用taf默认轮训调用。配置举例如下：
+调用后端tars服务时，TarsGateway默认采用tars自己的缺省轮训负载均衡策略（robin轮训），也可以通过配置自定义hash策略，hash_type为1时，根据客户端请求id进行tarshash调用; hash_type为2时，根据指定http头(配种中的httpheader)进行tarshash调用，比如http头中的 X-GUID，注意这里选择httpheader需要合理，避免过于集中某个值导致负载均衡过于不均匀的现象； hash_type为3时，则根据客户端的ip进行tarshash调用。 如果obj后面没有配置hash_type，那么采用tars默认轮训调用。配置举例如下：
 ```
     <proxy>
         # servant = server_full_obj [| hash_type [| http header key] ]
@@ -67,7 +67,7 @@ TARS-JSON协议代理，支持两种类型的接口。
 ```
 * **相关参数都在http body中指定：**
 
-必须为post请求类型，路径为/json，body内容为json结构。其中必须有reqid, obj, func, data 四个字段，分别表示请求id、服务servant、服务接口、接口参数，对应BasePacket中的reqid:iRequestId, obj:sServantName, func:sFuncName。data内容为接口中的参数，key为参数名，value为参数内容。除了以上必选四个字段之外，context为可选字段。回包内容包括 reqid 和 data， data为接口出参内容，其中 "" 的key对应内容为函数返回值。 这里除了这里包格式不一样，其他后面的逻辑都和TARS-WUP类型一样。请求参数举例如下：
+必须为post请求类型，路径为/json，body内容为json结构。其中必须有reqid, obj, func, data 四个字段，分别表示请求id、服务servant、服务接口、接口参数，对应BasePacket中的reqid:iRequestId, obj:sServantName, func:sFuncName。data内容为接口中的参数，key为参数名，value为参数内容。除了以上必选四个字段之外，context为可选字段。回包内容包括 reqid 和 data， data为接口出参内容，其中 "" 的key对应内容为函数返回值。 这里除了这里包格式不一样，其他后面的逻辑都和TARS-tup类型一样。请求参数举例如下：
 ```
     请求包：
     {
@@ -150,26 +150,26 @@ proxy_pass:
         };
 ```
 
-IP黑名单和流控策略， 同时支持WupProxyServer的三种协议，所以后面统一介绍。
+IP黑名单和流控策略， 同时支持TarsGateway的三种协议，所以后面统一介绍。
 
 
 ## 5. 流量控制
-可以支持访问WupProxyServer 访问后端进行流量控制，支持单机控制，也支持多机协同控制，也可以关闭流控。
+可以支持访问TarsGateway 访问后端进行流量控制，支持单机控制，也支持多机协同控制，也可以关闭流控。
 
 **开关控制:**  配置flow_control_onoff可以对流控进行开关控制。另外如果服务servant没有配置FlowControlObj，那么就不会开启流控策略。
 
 **流控策略:**  一定时间内最多访问多少次, 通过时间滑动窗口动态控制，滑动窗口大小为1s，超过次数则直接返回http 403。 
 
-**多机协同:**  配置了wup_report_obj，那么会通过该obj进行多机协同流量控制，否则进行单机控制。注意，如果是单机的策略，那么流控配置的一定时间内最多可以访问多少次就是单机最多可以访问该站点多少次；如果是多机协同，那么就是多机同时允许访问该站点多少次。
+**多机协同:**  配置了tup_report_obj，那么会通过该obj进行多机协同流量控制，否则进行单机控制。注意，如果是单机的策略，那么流控配置的一定时间内最多可以访问多少次就是单机最多可以访问该站点多少次；如果是多机协同，那么就是多机同时允许访问该站点多少次。
 
-**配置说明:**  如果是TARS-WUP或者TARS-JSON协议，那么流控的站点ID为服务Obj，如果是http协议，那么站点ID为配置中的stationId.
+**配置说明:**  如果是TARS-tup或者TARS-JSON协议，那么流控的站点ID为服务Obj，如果是http协议，那么站点ID为配置中的stationId.
 
 ## 6. 黑名单策略
 黑名单为IP黑名单，支持全局黑名单和站点黑名单两个级别。
 
 **黑名单格式:** 客户端IP地址，支持通配符。如 192.168.2.130, 192.168.10.*
 
-**全局黑名单:** 对所有访问WupProxyServer进行控制，包括TARS-WUP、TARS-JSON和普通HTTP协议。
+**全局黑名单:** 对所有访问TarsGateway进行控制，包括TARS-tup、TARS-JSON和普通HTTP协议。
 
 **站点黑名单:** 只针对指定站点控制，其他站点不首影响。
 
@@ -178,13 +178,13 @@ IP黑名单和流控策略， 同时支持WupProxyServer的三种协议，所以
 
 ## 7. 配置热更新
 支持常用配置热更新，包括：
-1. loadProxy: 通过该taf命令可以实现TARS-WUP&TARS-JSON协议的servant代理配置更新；
+1. loadProxy: 通过该tars命令可以实现TARS-tup&TARS-JSON协议的servant代理配置更新；
 2. loadHttp:  通过该配置可以进行普通HTTP协议的路由策略, 后端节点配置，监控url配置等；
 3. loadComm:  通过该命令可以进行一些公共的配置加载，主要包括黑白名单加载；
 4. 流控策略自动动态加载DB。
 
 ## 8. 环境切换
-在作为TARS-WUP或TARS-JSON协议代理时，可以通过http头中值，指定到不通的proxy子配置域中。
+在作为TARS-tup或TARS-JSON协议代理时，可以通过http头中值，指定到不通的proxy子配置域中。
 默认是直接使用proxy下面的配置，如果配置了env_httpheader，且当前请求中有该http头，并且http头的value为配置中的内容，那么则优先选择proxy 下面的 env 子域对应的转发规则。比如如下配置，表示http请求头中X-GUID=12345678123456781234567812345678 的用户，则优先选用test环境中配置，即：用户请求servant为hello时，那么真实服务obj选择TestApp.HelloServer.HelloObj@tcp -h 192.168.2.101 -p 10029 , 但是如果用户请求servant为world时，由于test环境中并没有配置 world 对应的转发规则，那么还是用 proxy 下面默认的规则，及真实obj为Test.HelloworldServer.HelloworldObj，配置如下：
 
 ```
@@ -210,20 +210,20 @@ IP黑名单和流控策略， 同时支持WupProxyServer的三种协议，所以
 * 200: OK 正常响应
 * 400: Bad Request  1.解客户端请求包错误。
 * 403: Forbidden  1.客户端ip命中黑名单。
-* 404: Not Found  1.wup或json协议找不到对应servant代理；2. Http找不到后端站点；
+* 404: Not Found  1.tup或json协议找不到对应servant代理；2. Http找不到后端站点；
 * 429: Too Many Request  1.流控超过限制策略；
 * 500: Server Interval Error 1.http后端没有配置目标地；
-* 502: Bad Gateway  1.调用后端taf服务或者http服务异常；
-* 504：Gateway Timeout  1.调用后端taf服务或者http服务超时;
+* 502: Bad Gateway  1.调用后端tars服务或者http服务异常；
+* 504：Gateway Timeout  1.调用后端tars服务或者http服务超时;
 
 ## 10. 日志格式说明
-TARS-WUP & TARS-JSON 协议代理请求响应日志格式说明：
+TARS-tup & TARS-JSON 协议代理请求响应日志格式说明：
 
 **正常回包 response日志:**
 
 日志时间 | 客户端ip | 客户端GUID | 客户端XUA | servantName | funcName | 请求加密类型 | 请求压缩类型 | 响应是否加密 | 响应是否压缩 | 耗时(ms) | 响应包大小
 
-**异常请求 wupcall_exception日志：**
+**异常请求 tupcall_exception日志：**
 
 日志时间 | 客户端ip |servantName | funcName | 客户端GUID | 客户端XUA |  请求加密类型 | 请求压缩类型 | 耗时(ms) | 后端rpc返回码