背景
api某些字段屬于敏感信息，原本在api層返回，現(xiàn)在禁止返回
比如銀行卡賬號，性別等等
現(xiàn)有架構API+RPC，數(shù)據(jù)存儲redis+DB
暫且不談db是否脫敏（加解密等），在API層是直接返回敏感信息的
如何方便的API層禁止這一個字段的返回
前提，客戶端不強依賴特定字段
場景說明
假設有下面的用戶類型，含id，姓名，性別信息，其中性別屬于敏感信息
type User struct{
id int64
name string
sex string
}
現(xiàn)在有客戶端請求用戶信息，客戶端只用到了name，根本不用sex，那么這時候就需要脫敏了
方案
前提
1.客戶端不強依賴敏感信息字段
比如不給sex信息客戶端也能work，不會crash
2.既然是有RPC接口，肯定有類似thrift的定義，各個接口的返回參數(shù)，也會定義optional，required
方案1
依賴于rpc的實現(xiàn)，即類thrift接口定義文件都定義UserDto中的Sex字段是optional的，那么rpc server端不返回即可，上游可以接受默認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的的時候走一層middleware，將原本的resp通過序列化，json marshell和unmarshell轉(zhuǎn)化成user_new_response,這樣端上就不會受到sex的返回了
比較
| 優(yōu)點 | 缺點 | |
|---|---|---|
| 方案1 | 干凈，省帶寬 | 強依賴接口定義，如果有一個接口沒有寫optional，那這個方案就很難執(zhí)行 |
| 方案2 | 方便，加middleware，不用管rpc各層變更 | 浪費帶寬，序列化等操作耗時 |
思考
如果歷史客戶端強依賴某個敏感字段，怎么辦？
那么客戶端改掉不要依賴，新版執(zhí)行即可
怎么對老版本客戶端返回老resp，新版客戶端給新resp？
服務端根據(jù)客戶端請求的版本號控制就好了
refer
下面寫的比較豐富，我的場景其實只是簡單的一步
http://www.itdecent.cn/p/ee6500509c00
http://www.itdecent.cn/p/2e69ff5bb3cc
https://my.oschina.net/u/3867294/blog/3089014
