我們平時(shí)做業(yè)務(wù)開(kāi)發(fā)工作，本質(zhì)上是處理數(shù)據(jù)與存儲(chǔ)、邏輯的關(guān)系。而我們程序的數(shù)據(jù)，絕大部分來(lái)自外部接口輸入，對(duì)接口輸入的檢查必須要做。否則就會(huì)導(dǎo)致應(yīng)用和各個(gè)微服務(wù)的數(shù)據(jù)被寫(xiě)臟，出現(xiàn)各種數(shù)據(jù)不一致的問(wèn)題，進(jìn)而引發(fā)運(yùn)行時(shí)邏輯出錯(cuò)和程序 crash 等問(wèn)題。這時(shí)防御式編程的重要性就體現(xiàn)出來(lái)了，而大家也清楚這一點(diǎn)。

但是在具體的工作中，我發(fā)現(xiàn)很多同學(xué)沒(méi)有做對(duì)接口入?yún)⒌男ｒ?yàn)，完全信任外部系統(tǒng)的入?yún)ⅲ挥胁糠滞瑢W(xué)做了校驗(yàn)，但是不全面。那到底該怎么正確、優(yōu)雅、全面地對(duì)接口入?yún)⑦M(jìn)行校驗(yàn)，做好防御式編程呢？這就是我們接下來(lái)要討論的問(wèn)題。

假設(shè)我們有這樣一個(gè)需求：設(shè)計(jì)一個(gè)訂單商城系統(tǒng)。它會(huì)涉及到商品創(chuàng)建、商品發(fā)布、用戶購(gòu)物車管理、用戶下單、購(gòu)買、取消訂單等非常多的用例。以商戶端創(chuàng)建商品這個(gè)接口設(shè)計(jì)為例，我們看下如何運(yùn)用防御式編程來(lái)處理。

class CreateProductRequestData {
privateProductproduct;
}
classProduct {
privateStoreIdstoreId;
privateStringname;
privateStringimageId;
privateTypetype;
privateList<SKU> skus;
  ...
}

針對(duì)前端提交的創(chuàng)建商品的數(shù)據(jù)，我們必須對(duì)數(shù)據(jù)做正確、全面的校驗(yàn)，防止客戶端寫(xiě) Bug 或者黑客攻擊導(dǎo)致系統(tǒng)應(yīng)用數(shù)據(jù)被寫(xiě)臟。

在這個(gè) case 中，我們要根據(jù)產(chǎn)品需求校驗(yàn)參數(shù)，在和前端開(kāi)發(fā)同學(xué)定義好接口文檔后，也同樣要按照定義去校驗(yàn)參數(shù)。storeId 必傳、商品 name 必傳、type 必須為枚舉中的值、以及逐個(gè)校驗(yàn) 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 不允許為空");
}
// 校驗(yàn)skus

我們來(lái)看上面這段校驗(yàn)代碼。其實(shí)在工作中，我們通常不會(huì)這么寫(xiě)，而是抽出單獨(dú)的工具類，對(duì)前端接口或者微服務(wù)跨系統(tǒng)之間的調(diào)用參數(shù)進(jìn)行斷言校驗(yàn)。如果參數(shù)內(nèi)容和接口定義不符或者和產(chǎn)品需求不一致，就拋出 Exception，由自定義的全局異常處理器捕獲 Exception。在我們的例子里是 ApiException，然后生成 response 返回前端。ApiException 代表客戶端寫(xiě)出了 Bug，或者有黑客對(duì)接口進(jìn)行攻擊，亂傳入?yún)?shù)引發(fā)的異常。

這段代碼片段是我們抽出的通用工具類，可以用來(lái)校驗(yàn)前端參數(shù)和微服務(wù)跨系統(tǒng)調(diào)用的入?yún)ⅲ?/span>

public class Asserts {
    //校驗(yàn)表達(dá)式，可以用來(lái)檢查客戶端接口數(shù)據(jù)的邏輯關(guān)聯(lián)性
    publicstaticvoidassertTrue(String description, boolean value) {
        if(!value) {
            thrownewApiException(description);
        }
    }
    //校驗(yàn)字段不為空
    publicstaticvoidassertFieldNotEmpty(String field, String value)    {
        assertFieldNotEmpty(field, value, false /* trim */);
    }
    // 校驗(yàn)字段不為空的重載方法
    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;
    }
    //校驗(yàn)字段不為null
    publicstaticvoidassertFieldNotNull(String field, Object value) {
        if(value == null) {
            thrownewApiException(field + " 不應(yīng)為 Null.");
        }
    }
    //... 其他校驗(yàn)方法
}

這里需要提醒你一點(diǎn)，在防御式編程中，我們要盡可能地處理錯(cuò)誤，而不是異常。這句話怎么理解呢？還是拿剛才的例子來(lái)說(shuō)，假如不校驗(yàn) storeId，任由 null 值進(jìn)入系統(tǒng)，那么在系統(tǒng)運(yùn)行中，我們就必然要處理因?yàn)?storeId 為 null 而產(chǎn)生的 crash，例如 NullPointerException?，F(xiàn)在我們?cè)诮涌趯有ｒ?yàn)處理了這個(gè)錯(cuò)誤（校驗(yàn) storeId 不為 null），那么就可以保證應(yīng)用中的數(shù)據(jù)是安全的，是經(jīng)過(guò)檢查的，沒(méi)有臟數(shù)據(jù)。其他字段的校驗(yàn)也是一樣的作用，通過(guò)對(duì)外部數(shù)據(jù)進(jìn)行校驗(yàn)，做防御性保護(hù)，盡可能處理錯(cuò)誤，我們的系統(tǒng)就會(huì)非常干凈，運(yùn)行狀態(tài)也會(huì)非常健康。

你可能會(huì)問(wèn)，那如果接口數(shù)量很多，該怎么設(shè)計(jì)，在什么地方校驗(yàn)這些參數(shù)？針對(duì)這個(gè)問(wèn)題，可以這么解決，我們定義一個(gè) Validatable 通用接口，里面只有一個(gè)方法 validate()，它是一個(gè)通用校驗(yàn)的鉤子方法。我們的各種 RequestData、各種 model(可以是 RequestVO) 實(shí)現(xiàn)這個(gè)接口，實(shí)現(xiàn) validate 鉤子方法，做業(yè)務(wù)相關(guān)的參數(shù)檢查。

比如這段代碼片段，我們可以對(duì)之前的代碼做改造和重構(gòu)，讓它們變得更加優(yōu)雅。這樣每個(gè) RequestData 只關(guān)心自己的校驗(yàn)邏輯，做好自己的防御性保護(hù)就行了。

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();
    }
    // ...校驗(yàn)product的其他字段
  }
}
publicclassSKUimplementsValidatable {
privateintordinal;
privateStringname;
  // ...sku的其他屬性
  @Override
publicvoidvalidate() {
    Asserts.assertFieldNotEmpty("name", this.name);
    // ...校驗(yàn)sku的其他字段
  }
}
publicclassCreateProductRequestDataimplementsValidatable{
privateProductproduct;
  @Override
publicvoidvalidate() {
    Asserts.assertFieldNotNull("product", this.product);
    product.validate();
  }
}

這里有一個(gè)問(wèn)題，這么多 RequestData，我們?cè)陂_(kāi)發(fā)中到底如何關(guān)聯(lián)具體的處理器呢？我在這里也分享一種解決方案。你可以定義與 RequestData 對(duì)應(yīng)的 RequestHandler，然后通過(guò)泛型綁定 RequestData 和 ResponseData。通過(guò)一個(gè)特定的 handlerRepo 在容器啟動(dòng)的時(shí)候就把這些 handler 全部組裝好。這樣，我們?cè)黾右粋€(gè)接口時(shí)只需要增加對(duì)應(yīng)的 RequestData、ResponseData 和 handler，滿足了對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。請(qǐng)求來(lái)的時(shí)候，根據(jù)請(qǐng)求路徑能知道具體的 handler，在這里可以回調(diào) validate 鉤子完成校驗(yàn)。你可以參考這段代碼：

@Service
public class CreateProductRequestHandlerextendsRequestHandler<CreateProductRequestData,CreateProductResponseData>{
  @Override
publicCreateProductResponseDataexecuteRequest(RequestContext,
  CreateProductRequestData req) {
    // ...
  }
}
@Service
publicclassHandlerRepo {
// 當(dāng)web容器接收請(qǐng)求（請(qǐng)求url約定就是key）后，通過(guò)key拿到RequestEntry中的handler,根據(jù)requestClazz反序列化出對(duì)應(yīng)的RequestData，再統(tǒng)一校驗(yàn)，調(diào)用validate鉤子方法。validateRequestData可以做在RequestHandler抽象類中，讓具體開(kāi)發(fā)接口的同學(xué)無(wú)需關(guān)心如何調(diào)用validate方法。此處設(shè)計(jì)不在本次課程中。
classRequestEntry {
    finalRequestHandlerhandler;
    finalClass<? extendsApiRequestData> requestClazz;
    finalClass<? extendsApiResponseData> responseClazz;
    // ...
  }
privatefinalMap<String, RequestEntry> map = Maps.newHashMap();
  @Autowired
publicvoidinitHandlers(RequestHandler<? extends ApiRequestData,
  ? extends ApiResponseData>[]) {
    // 把每一個(gè)RequestHandler解析成RequestEntry,key可以是包名加類名的分割，如
    /api/com/abc/xyx/createProduct
  }
}

在關(guān)于接口相關(guān)的防御式編程中，除了要校驗(yàn)系統(tǒng)外部數(shù)據(jù)的格式和合法性之外，有的校驗(yàn)還需要上下文的支持。

例如，在我們這一講的例子中，除了常規(guī)參數(shù)校驗(yàn)，還需要校驗(yàn) storeId 的邏輯關(guān)系。這句話怎么理解？當(dāng)商戶端在后臺(tái)登錄時(shí)，登錄態(tài)中可以拿到當(dāng)前商家信息。接口提交上來(lái)的 storeId，必須是當(dāng)前商家所屬的 Store，因?yàn)榭隙ú荒軇?chuàng)建其他商家的產(chǎn)品。這種校驗(yàn)，其實(shí)很多同學(xué)都會(huì)忽略，但又是非常重要的。假如不校驗(yàn)，有人繞過(guò)界面調(diào)用接口，傳入其他 storeId，就會(huì)引發(fā)服務(wù)器 Bug，造成應(yīng)用數(shù)據(jù)被寫(xiě)臟。這種錯(cuò)誤校驗(yàn)也屬于 ApiException，我們認(rèn)為也是客戶端 Bug。

正確的校驗(yàn)命令，你可以參考這段代碼：

public void createProduct(Product product) {
  Asserts.assertTrue("只能創(chuàng)建自己的商品：" + product.getStoreId(), product.getStoreId() == RequestContext().getSession().getStoreId());
  //... 產(chǎn)品信息入庫(kù)邏輯
}

當(dāng)然了，在實(shí)際的工作中，還有很多情況是需要結(jié)合上下文來(lái)校驗(yàn)前端參數(shù)的。比如刪除文章這個(gè)接口，在產(chǎn)品設(shè)計(jì)上，我們只能刪除自己的文章，如果客戶端提交上來(lái)的文章作者是其他用戶，你沒(méi)有經(jīng)過(guò)校驗(yàn)就做刪除，那就是不對(duì)的。在我的職業(yè)經(jīng)歷中，無(wú)論是大型互聯(lián)網(wǎng)公司，還是創(chuàng)業(yè)公司，很多業(yè)務(wù)代碼都沒(méi)有這種防御處理，完全信任客戶端的入?yún)?，這種做法非常危險(xiǎn)。所以，服務(wù)器對(duì)于這種在異常交互下提交上來(lái)的參數(shù)，必須做檢查。我們考慮得越全面，寫(xiě)出來(lái)的代碼就越健壯，應(yīng)用數(shù)據(jù)越安全。

我用一張思維導(dǎo)圖給你總結(jié)一下講的內(nèi)容。對(duì)于接口的防御式編程處理方式呢，我們首先要進(jìn)行契約檢查，也就是數(shù)據(jù)格式、定義是不是合法的，這是最基本的校驗(yàn)要素。其次，還要檢查接口入?yún)⒂袥](méi)有邏輯上的 Bug，這需要結(jié)合你當(dāng)前的具體業(yè)務(wù)來(lái)判斷，因?yàn)榻涌诒举|(zhì)上只是一個(gè)輸入輸出，不應(yīng)該和具體的界面聯(lián)系起來(lái)。

圖片