背景
api某些字段屬于敏感信息，原本在api層返回，現(xiàn)在禁止返回
比如銀行卡賬號载慈，性別等等
現(xiàn)有架構(gòu)API+RPC徽千，數(shù)據(jù)存儲redis+DB
暫且不談db是否脫敏（加解密等）苫费，在API層是直接返回敏感信息的
如何方便的API層禁止這一個字段的返回
前提，客戶端不強(qiáng)依賴特定字段
場景說明
假設(shè)有下面的用戶類型双抽，含id百框，姓名，性別信息牍汹，其中性別屬于敏感信息
type User struct{
id int64
name string
sex string
}
現(xiàn)在有客戶端請求用戶信息铐维，客戶端只用到了name柬泽，根本不用sex，那么這時(shí)候就需要脫敏了
方案
前提
1.客戶端不強(qiáng)依賴敏感信息字段
比如不給sex信息客戶端也能work嫁蛇，不會crash
2.既然是有RPC接口锨并，肯定有類似thrift的定義，各個接口的返回參數(shù)睬棚，也會定義optional琳疏，required
方案1
依賴于rpc的實(shí)現(xiàn)，即類thrift接口定義文件都定義UserDto中的Sex字段是optional的闸拿，那么rpc server端不返回即可空盼，上游可以接受默認(rèn)nil
方案2
定義出original response和new response，比如
message user_response{
required int32 status_code = 1;
required int64 id = 1
required string name=2
required string sex=3
}
message user_new_response{
required int32 status_code = 1;
required int64 id = 1
required string name=2
}
原resp為user_response新荤，新resp為user_new_response
那么吐出api的的時(shí)候走一層middleware揽趾，將原本的resp通過序列化，json marshell和unmarshell轉(zhuǎn)化成user_new_response,這樣端上就不會受到sex的返回了
比較
| 優(yōu)點(diǎn) | 缺點(diǎn) | |
|---|---|---|
| 方案1 | 干凈苛骨，省帶寬 | 強(qiáng)依賴接口定義篱瞎，如果有一個接口沒有寫optional，那這個方案就很難執(zhí)行 |
| 方案2 | 方便痒芝，加middleware俐筋，不用管rpc各層變更 | 浪費(fèi)帶寬，序列化等操作耗時(shí) |
思考
如果歷史客戶端強(qiáng)依賴某個敏感字段严衬，怎么辦澄者？
那么客戶端改掉不要依賴，新版執(zhí)行即可
怎么對老版本客戶端返回老resp请琳，新版客戶端給新resp粱挡？
服務(wù)端根據(jù)客戶端請求的版本號控制就好了
refer
下面寫的比較豐富，我的場景其實(shí)只是簡單的一步
http://www.reibang.com/p/ee6500509c00
http://www.reibang.com/p/2e69ff5bb3cc
https://my.oschina.net/u/3867294/blog/3089014
