如何正確地對接口進(jìn)行防御式編程
我們平時做業(yè)務(wù)開發(fā)工作，本質(zhì)上是處理數(shù)據(jù)與存儲、邏輯的關(guān)系。而我們程序的數(shù)據(jù)，絕大部分來自外部接口輸入，對接口輸入的檢查必須要做。否則就會導(dǎo)致應(yīng)用和各個微服務(wù)的數(shù)據(jù)被寫臟，出現(xiàn)各種數(shù)據(jù)不一致的問題，進(jìn)而引發(fā)運行時邏輯出錯和程序 crash 等問題。這時防御式編程的重要性就體現(xiàn)出來了，而大家也清楚這一點。
但是在具體的工作中，我發(fā)現(xiàn)很多同學(xué)沒有做對接口入?yún)⒌男ｒ?，完全信任外部系統(tǒng)的入?yún)ⅲ挥胁糠滞瑢W(xué)做了校驗，但是不全面。那到底該怎么正確、優(yōu)雅、全面地對接口入?yún)⑦M(jìn)行校驗，做好防御式編程呢？這就是我們接下來要討論的問題。
假設(shè)我們有這樣一個需求：設(shè)計一個訂單商城系統(tǒng)。它會涉及到商品創(chuàng)建、商品發(fā)布、用戶購物車管理、用戶下單、購買、取消訂單等非常多的用例。以商戶端創(chuàng)建商品這個接口設(shè)計為例，我們看下如何運用防御式編程來處理。
class CreateProductRequestData {
privateProductproduct;
}
classProduct {
privateStoreIdstoreId;
privateStringname;
privateStringimageId;
privateTypetype;
privateList<SKU> skus;
...
}針對前端提交的創(chuàng)建商品的數(shù)據(jù)，我們必須對數(shù)據(jù)做正確、全面的校驗，防止客戶端寫 Bug 或者黑客攻擊導(dǎo)致系統(tǒng)應(yīng)用數(shù)據(jù)被寫臟。
在這個 case 中，我們要根據(jù)產(chǎn)品需求校驗參數(shù)，在和前端開發(fā)同學(xué)定義好接口文檔后，也同樣要按照定義去校驗參數(shù)。storeId 必傳、商品 name 必傳、type 必須為枚舉中的值、以及逐個校驗 skus 中的 sku。
if (storeId == null) {
throw new ApiException("storeId 不允許為 null");
}
if (Strings.isNullOrEmpty(name)) {
throw new ApiException("name 不允許為 null");
}
if (type == null) {
throw new ApiException("產(chǎn)品類型 type 不允許為 null");
}
if (CollectionUtils.isEmpty(skus)) {
throw new ApiException("skus 不允許為空");
}
// 校驗skus我們來看上面這段校驗代碼。其實在工作中，我們通常不會這么寫，而是抽出單獨的工具類，對前端接口或者微服務(wù)跨系統(tǒng)之間的調(diào)用參數(shù)進(jìn)行斷言校驗。如果參數(shù)內(nèi)容和接口定義不符或者和產(chǎn)品需求不一致，就拋出 Exception，由自定義的全局異常處理器捕獲 Exception。在我們的例子里是 ApiException，然后生成 response 返回前端。ApiException 代表客戶端寫出了 Bug，或者有黑客對接口進(jìn)行攻擊，亂傳入?yún)?shù)引發(fā)的異常。
這段代碼片段是我們抽出的通用工具類，可以用來校驗前端參數(shù)和微服務(wù)跨系統(tǒng)調(diào)用的入?yún)ⅲ?/span>
public class Asserts {
//校驗表達(dá)式，可以用來檢查客戶端接口數(shù)據(jù)的邏輯關(guān)聯(lián)性
publicstaticvoidassertTrue(String description, boolean value) {
if(!value) {
thrownewApiException(description);
}
}
//校驗字段不為空
publicstaticvoidassertFieldNotEmpty(String field, String value) {
assertFieldNotEmpty(field, value, false /* trim */);
}
// 校驗字段不為空的重載方法
publicstaticStringassertFieldNotEmpty(String field, String value, boolean trim) {
booleanfieldNotEmpty = value != null;
if(fieldNotEmpty) {
if(trim) {
value = value.trim();
}
if(Strings.isNullOrEmpty(value)) {
fieldNotEmpty = false;
}
}
if(!fieldNotEmpty) {
thrownewApiException("字段" + field + "不應(yīng)為空。");
}
returnvalue;
}
//校驗字段不為null
publicstaticvoidassertFieldNotNull(String field, Object value) {
if(value == null) {
thrownewApiException(field + " 不應(yīng)為 Null.");
}
}
//... 其他校驗方法
}這里需要提醒你一點，在防御式編程中，我們要盡可能地處理錯誤，而不是異常。這句話怎么理解呢？還是拿剛才的例子來說，假如不校驗 storeId，任由 null 值進(jìn)入系統(tǒng)，那么在系統(tǒng)運行中，我們就必然要處理因為 storeId 為 null 而產(chǎn)生的 crash，例如 NullPointerException?，F(xiàn)在我們在接口層校驗處理了這個錯誤（校驗 storeId 不為 null），那么就可以保證應(yīng)用中的數(shù)據(jù)是安全的，是經(jīng)過檢查的，沒有臟數(shù)據(jù)。其他字段的校驗也是一樣的作用，通過對外部數(shù)據(jù)進(jìn)行校驗，做防御性保護，盡可能處理錯誤，我們的系統(tǒng)就會非常干凈，運行狀態(tài)也會非常健康。
你可能會問，那如果接口數(shù)量很多，該怎么設(shè)計，在什么地方校驗這些參數(shù)？針對這個問題，可以這么解決，我們定義一個 Validatable 通用接口，里面只有一個方法 validate()，它是一個通用校驗的鉤子方法。我們的各種 RequestData、各種 model(可以是 RequestVO) 實現(xiàn)這個接口，實現(xiàn) validate 鉤子方法，做業(yè)務(wù)相關(guān)的參數(shù)檢查。
比如這段代碼片段，我們可以對之前的代碼做改造和重構(gòu)，讓它們變得更加優(yōu)雅。這樣每個 RequestData 只關(guān)心自己的校驗邏輯，做好自己的防御性保護就行了。
public interface Validatable {
void validate();
}
public class ProductimplementsValidatable {
privateStoreIdstoreId;
privateStringname;
privateStringimageId;
privateTypetype;
privateList<SKU> skus;
// product的其他屬性
@Override
publicvoidvalidate() {
Asserts.assertFieldNotNull("storeId", this.storeId);
Asserts.assertFieldNotEmpty("name", this.name);
Asserts.assertFieldNotNull("type", this.type);
Asserts.assertTrue("skus 不允許為空",!CollectionUtils.isEmpty(skus));
for(SKU sku : skus) {
sku.validate();
}
// ...校驗product的其他字段
}
}
publicclassSKUimplementsValidatable {
privateintordinal;
privateStringname;
// ...sku的其他屬性
@Override
publicvoidvalidate() {
Asserts.assertFieldNotEmpty("name", this.name);
// ...校驗sku的其他字段
}
}
publicclassCreateProductRequestDataimplementsValidatable{
privateProductproduct;
@Override
publicvoidvalidate() {
Asserts.assertFieldNotNull("product", this.product);
product.validate();
}
}這里有一個問題，這么多 RequestData，我們在開發(fā)中到底如何關(guān)聯(lián)具體的處理器呢？我在這里也分享一種解決方案。你可以定義與 RequestData 對應(yīng)的 RequestHandler，然后通過泛型綁定 RequestData 和 ResponseData。通過一個特定的 handlerRepo 在容器啟動的時候就把這些 handler 全部組裝好。這樣，我們增加一個接口時只需要增加對應(yīng)的 RequestData、ResponseData 和 handler，滿足了對擴展開放，對修改關(guān)閉。請求來的時候，根據(jù)請求路徑能知道具體的 handler，在這里可以回調(diào) validate 鉤子完成校驗。你可以參考這段代碼：
@Service
public class CreateProductRequestHandlerextendsRequestHandler<CreateProductRequestData,CreateProductResponseData>{
@Override
publicCreateProductResponseDataexecuteRequest(RequestContext,
CreateProductRequestData req) {
// ...
}
}
@Service
publicclassHandlerRepo {
// 當(dāng)web容器接收請求（請求url約定就是key）后，通過key拿到RequestEntry中的handler,根據(jù)requestClazz反序列化出對應(yīng)的RequestData，再統(tǒng)一校驗，調(diào)用validate鉤子方法。validateRequestData可以做在RequestHandler抽象類中，讓具體開發(fā)接口的同學(xué)無需關(guān)心如何調(diào)用validate方法。此處設(shè)計不在本次課程中。
classRequestEntry {
finalRequestHandlerhandler;
finalClass<? extendsApiRequestData> requestClazz;
finalClass<? extendsApiResponseData> responseClazz;
// ...
}
privatefinalMap<String, RequestEntry> map = Maps.newHashMap();
@Autowired
publicvoidinitHandlers(RequestHandler<? extends ApiRequestData,
? extends ApiResponseData>[]) {
// 把每一個RequestHandler解析成RequestEntry,key可以是包名加類名的分割，如
/api/com/abc/xyx/createProduct
}
}在關(guān)于接口相關(guān)的防御式編程中，除了要校驗系統(tǒng)外部數(shù)據(jù)的格式和合法性之外，有的校驗還需要上下文的支持。
例如，在我們這一講的例子中，除了常規(guī)參數(shù)校驗，還需要校驗 storeId 的邏輯關(guān)系。這句話怎么理解？當(dāng)商戶端在后臺登錄時，登錄態(tài)中可以拿到當(dāng)前商家信息。接口提交上來的 storeId，必須是當(dāng)前商家所屬的 Store，因為肯定不能創(chuàng)建其他商家的產(chǎn)品。這種校驗，其實很多同學(xué)都會忽略，但又是非常重要的。假如不校驗，有人繞過界面調(diào)用接口，傳入其他 storeId，就會引發(fā)服務(wù)器 Bug，造成應(yīng)用數(shù)據(jù)被寫臟。這種錯誤校驗也屬于 ApiException，我們認(rèn)為也是客戶端 Bug。
正確的校驗命令，你可以參考這段代碼：
public void createProduct(Product product) {
Asserts.assertTrue("只能創(chuàng)建自己的商品：" + product.getStoreId(), product.getStoreId() == RequestContext().getSession().getStoreId());
//... 產(chǎn)品信息入庫邏輯
}當(dāng)然了，在實際的工作中，還有很多情況是需要結(jié)合上下文來校驗前端參數(shù)的。比如刪除文章這個接口，在產(chǎn)品設(shè)計上，我們只能刪除自己的文章，如果客戶端提交上來的文章作者是其他用戶，你沒有經(jīng)過校驗就做刪除，那就是不對的。在我的職業(yè)經(jīng)歷中，無論是大型互聯(lián)網(wǎng)公司，還是創(chuàng)業(yè)公司，很多業(yè)務(wù)代碼都沒有這種防御處理，完全信任客戶端的入?yún)?，這種做法非常危險。所以，服務(wù)器對于這種在異常交互下提交上來的參數(shù)，必須做檢查。我們考慮得越全面，寫出來的代碼就越健壯，應(yīng)用數(shù)據(jù)越安全。
我用一張思維導(dǎo)圖給你總結(jié)一下講的內(nèi)容。對于接口的防御式編程處理方式呢，我們首先要進(jìn)行契約檢查，也就是數(shù)據(jù)格式、定義是不是合法的，這是最基本的校驗要素。其次，還要檢查接口入?yún)⒂袥]有邏輯上的 Bug，這需要結(jié)合你當(dāng)前的具體業(yè)務(wù)來判斷，因為接口本質(zhì)上只是一個輸入輸出，不應(yīng)該和具體的界面聯(lián)系起來。
圖片
