背景

隨著業(yè)務(wù)的發(fā)展，系統(tǒng)架構(gòu)從單體架構(gòu)變?yōu)槊嫦蚍?wù)架構(gòu)，水平分層架構(gòu);再變?yōu)槲⒎?wù)架構(gòu)，

服務(wù)網(wǎng)格，服務(wù)與服務(wù)間的交互越來越復雜，如何優(yōu)雅的設(shè)計一個接口，需要考慮哪些方面?特別是對公服務(wù)(比如BFF)需要對外提供公網(wǎng)域名的接口，安全性怎么保證，我整理了我工作以來一些常見的措施以及具體如何去實現(xiàn)：

數(shù)據(jù)有效性校驗

合法性校驗包括：常規(guī)性校驗以及業(yè)務(wù)校驗; 常規(guī)性校驗：包括必填字段校驗，長度校驗，類型校驗，格式校驗等; 業(yè)務(wù)校驗：根據(jù)實際業(yè)務(wù)而定，比如訂單金額不能小于0等;

冪等設(shè)計

所謂冪等，簡單地說，就是對接口的多次調(diào)用所產(chǎn)生的結(jié)果和調(diào)用一次是一致的。數(shù)據(jù)發(fā)生改變才需要做冪等，有些接口是天然保證冪等性的。

比如查詢接口，有些對數(shù)據(jù)的修改是一個常量，并且無其他記錄和操作，那也可以說是具有冪等性的。其他情況下，所有涉及對數(shù)據(jù)的修改、狀態(tài)的變更就都有必要防止重復性操作的發(fā)生。通過間接的實現(xiàn)接口的冪等性來防止重復操作所帶來的影響。

又比如我們電商比較常見的加減GMV同一個消息無論過來多少次結(jié)果都應(yīng)該只加減一次，不然會導致金額錯誤甚至造成資損。

請求層面： 多次執(zhí)行的結(jié)果是一致的 業(yè)務(wù)層面： 同一個用戶不重復下單，商品不超賣，MQ不重復消費

冪等的本質(zhì)是分布式鎖的問題，分布式鎖正?？梢酝ㄟ^redis或zookeeper實現(xiàn);

在分布式環(huán)境下，鎖定全局唯一資源，使請求串行化，實際表現(xiàn)為互斥鎖，防止重復，解決冪等

安全性

1. 數(shù)據(jù)加密

我們知道數(shù)據(jù)在傳輸過程中是很容易被抓包的，如果直接傳輸比如http協(xié)議傳輸，那么數(shù)據(jù)在傳輸?shù)倪^程中可能被任何人獲取。

所以必須對數(shù)據(jù)進行加密，常見的做法是對敏感數(shù)據(jù)比如身份證號進行md5加密?，F(xiàn)在主流的做法是使用https協(xié)議，在http和tcp之間添加一層數(shù)數(shù)據(jù)安全層(SSL層)，這一層負責數(shù)據(jù)的加密和解密。https如何配置和使用，大家翻閱我歷史文章自行去研究。

對稱加密: 密鑰在加密過程中和解密過程中是不變的，常見的算法有DES,AES;優(yōu)點是加解密計算速度快;缺點是數(shù)據(jù)傳送前，服務(wù)雙方必須約定好密鑰，如果一方密鑰泄露，加密信息也就不安全了。

非對稱加密: 密鑰成對出現(xiàn)，一個密鑰加密之后，由另外一個密鑰來解密;私鑰放在服務(wù)端文件中，公鑰可以發(fā)布給任何人使用;優(yōu)點是比對稱加密更安全，但是加解密的速度比對稱加密慢多了，廣泛使用的是RSA算法;

https的實現(xiàn)正好是結(jié)合了兩種加密方式，整合了雙方的優(yōu)點，在安全性和性能方面都比較好。對稱加密和非對稱加密的代碼實現(xiàn)，jdk提供了相關(guān)的工具類可以直接使用，本文不過多介紹。

2. 數(shù)據(jù)簽名

介紹3種數(shù)據(jù)簽名安全策略：摘要[KEY] , 簽名[證書] , 簽名+加密[證書]

安全策略 描述 安全級別 摘要[Key] 將數(shù)據(jù)和Key(自定義契約密碼)組合后進行摘要 安全級別低，契約密鑰安全性非常低。在契約密鑰安全情況下能基本保障數(shù)據(jù)的不可篡改性。 簽名[證書] 使用證書和非對稱簽名算法對數(shù)據(jù)進行簽名 安全級別中，能夠保障數(shù)據(jù)的不可篡改性和不可抵賴性，但是不能保障數(shù)據(jù)的私密性 簽名-加密[證書] 使用證書和非對稱算法對數(shù)據(jù)簽名，使用一次一密的密鑰和對稱算法對數(shù)據(jù)進行加密 安全級別高，能夠保障數(shù)據(jù)的不可篡改性和不可抵賴性，而且能保障數(shù)據(jù)的私密性。

• 機密性(Confidentiality): 未經(jīng)許可不許看
• 完整性(Integrity) : 不許篡改
• 可用性(Availability) : 防止不可用
• 不可抵賴性(Non-Repudiation): 用戶不能否認其行為

摘要[KEY]過程：將需要提交的數(shù)據(jù)通過某種方式組合成一個字符串，然后通過md5生成一段加密字符串，這段字符串就是數(shù)據(jù)包的簽名，比如：

str：參數(shù)1={參數(shù)1}&參數(shù)2={參數(shù)2}&……&參數(shù)n={參數(shù)n}$key={用戶密鑰}; 
 
MD5.encrypt(str); 

摘要[KEY]原理：Hash算法不可逆，并且計算結(jié)果具有唯一性，在key 的隱私得到保證的情況下，可以保證完整性 摘要[KEY]缺陷：key的隱私性很難保證，明文傳輸

簽名[證書]過程：客戶端對明文做一個md5/SHA計算，對計算后的值通過私鑰加密得到密文，客戶端將明文和密文發(fā)送給服務(wù)端，服務(wù)端對密文通過公鑰解密得到值A(chǔ)，同時服務(wù)端對明文做一個md5/SHA計算得到值B，比較值A(chǔ)與值B，相同得驗證通過，能夠保障不可篡性和不可抵賴性，但是不能保障數(shù)據(jù)的私密性(明文傳輸)

簽名+加密[證書]過程：客戶端生成一個隨機字符串，作為password，然后把這個password通過B公鑰加密生成密文C，把A明文通過password加密生成密文B， 同時把A明文做MD5/SHA計算后的值通過A私鑰加密得到簽名D， 把密文B和密文C和簽名D發(fā)給服務(wù)端，服務(wù)端通過私鑰解密文C得到password，然后通過password解密文B就可以得到A明文，同時簽名可以用來驗證發(fā)送者是不是A，以及A發(fā)送的數(shù)據(jù)有沒有被第三方修改過。

可以假設(shè)存在一個惡意的一方X，冒充了A，發(fā)送了密文B(password生成)，密文C服務(wù)端收到數(shù)據(jù)后，仍然可以正常解密得到明文，但是卻無法證明這個明文數(shù)據(jù)是A發(fā)送的還是惡意用戶B發(fā)送的。簽名D的含義就是A自己簽名，服務(wù)端可以驗證。X由于沒有A的私鑰，這個簽名它無法冒充，會被服務(wù)端識別出來。

加密-簽名

3. 時間戳機制

數(shù)據(jù)經(jīng)過了加密處理，酒店抓取到了數(shù)據(jù)也看不到真實數(shù)據(jù);但是有不法者不關(guān)心真實數(shù)據(jù)，拿到數(shù)據(jù)后直接進行惡意請求，這個時候簡單的做法可以考慮時間戳機制，在每次請求中加入當前時間，服務(wù)端會將報文中的時間與系統(tǒng)當前時間做比對，看是否在一個固定的時間范圍內(nèi)比如5分鐘，惡意偽造的數(shù)據(jù)是沒法更改報文中時間的，超過5分鐘就可以當作非法請求了。

偽代碼如下：

long interval=5*60*1000；//超時時間 
long clientTime=request.getparameter("clientTime"); 
long serverTime=System.currentTimeMillis(); 
if(serverTime-clientTime>interval){ 
    return new Response("超過處理時長") 
} 

4. AppId機制

大部分網(wǎng)站需要用戶名和密碼才能登陸，這其實是一種安全機制;對應(yīng)的服務(wù)也可以使用這一機制，不是誰都可以調(diào)用，調(diào)用服務(wù)前必須先申請開通一個唯一的appid，提供相關(guān)的密鑰，在調(diào)用接口時需要提供appid+密鑰信息，服務(wù)端會進行驗證。

appid使用字母，數(shù)字，特殊符號等隨機生成，生成的唯一appid看系統(tǒng)實際要求是否需要全局唯一;不管是否全局唯一最好有以下屬性：

• 趨勢遞增: 這樣在保存數(shù)據(jù)庫的時候，索引的性能更好
• 信息安全: 隨機生成，不要是連續(xù)的，容易被發(fā)現(xiàn)規(guī)律
• 關(guān)于全局唯一Id生成的方式常見的有snowflake方式等

snowflake

以上示意圖描述了一個序列號的二進制組成結(jié)構(gòu)。

第一位不用，恒為0，即表示正整數(shù);接下來的41位表示時間戳，精確到毫秒。為了節(jié)約空間，可以將此時間戳定義為距離某個時間點所經(jīng)歷的毫秒數(shù)(Java默認是1970-01-01 00:00:00)。

再后來的10位用來標識工作機器，如果出現(xiàn)了跨IDC的情況，可以將這10位一分為二，一部分用于標識IDC，一部分用于標識服務(wù)器;最后12位是序列號，自增長。

snowflake的核心思想是64bit的合理分配，但不必要嚴格按照上圖所示的分法。如果在機器較少的情況下，可以適當縮短機器id的長度，留出來給序列號。

5. 黑名單機制

如果此appid進行過很多非法操作，或者說專門有一個中黑系統(tǒng)，經(jīng)過分析之后直接將此appid列入黑名單，所有請求直接返回錯誤碼;

我們可以給每個appid設(shè)置一個狀態(tài)比如包括：初始化狀態(tài)，正常狀態(tài)，中黑狀態(tài)，關(guān)閉狀態(tài)等等;或者我們直接通過分布式配置中心，直接保存黑名單列表，每次檢查是否在列表中即可;

限流機制

常用的限流算法包括：令牌桶限流，漏桶限流，計數(shù)器限流;

• 令牌桶限流 令牌桶算法的原理是系統(tǒng)以一定速率向桶中放入令牌，填滿了就丟棄令牌;請求來時會先從桶中取出令牌，如果能取到令牌，則可以繼續(xù)完成請求，否則等待或者拒絕服務(wù);令牌桶允許一定程度突發(fā)流量，只要有令牌就可以處理，支持一次拿多個令牌;
• 漏桶限流 漏桶算法的原理是按照固定常量速率流出請求，流入請求速率任意，當請求數(shù)超過桶的容量時，新的請求等待或者拒絕服務(wù);可以看出漏桶算法可以強制限制數(shù)據(jù)的傳輸速度;
• 計數(shù)器限流 計數(shù)器是一種比較簡單粗暴的算法，主要用來限制總并發(fā)數(shù)，比如數(shù)據(jù)庫連接池、線程池、秒殺的并發(fā)數(shù);計數(shù)器限流只要一定時間內(nèi)的總請求數(shù)超過設(shè)定的閥值則進行限流;

具體基于以上算法如何實現(xiàn)，Guava提供了RateLimiter工具類基于基于令牌桶算法：

RateLimiter rateLimiter = RateLimiter.create(5); 

以上代碼表示一秒鐘只允許處理五個并發(fā)請求，以上方式只能用在單應(yīng)用的請求限流，不能進行全局限流;這個時候就需要分布式限流，可以基于redis+lua來實現(xiàn);

總結(jié)

其實接口不管是設(shè)計還是開發(fā)，如果不是特別急的需求大家都可以多一點思考，這樣你的系統(tǒng)才會更穩(wěn)定，上線和測試過程中bug更少，而且從個人提升角度來說，多思考總是一件好事。

很多時候大家都在抱怨：哎呀我公司小，我學校差這種環(huán)境得不到成長。傻瓜，很多時候高手也是這樣走過來的，不過一樣的事情每個人的態(tài)度不一樣，時間久了結(jié)果也就不一樣了。

好啦，現(xiàn)在大家應(yīng)該都上班了，我熬夜值班還在大促現(xiàn)場(文章周末寫的，現(xiàn)在就寫個總結(jié))，我是敖丙，你知道的越多，你不知道的越多，我們下期見。