隨着業務的不斷發展，軟件系統不可避免的走向熵增：復雜度越來越高、研發效率越來越差、穩定性逐漸降低等。這時抽象核心能力，走向平台化的道路成為很多系統的首要選擇。筆者結合自己的經驗，總結了平台化建設的幾種思路，希望對大家建設平台化有所幫助。
平台化有以下優點
- 復用性強：復用核心邏輯，業務功能只在平台之上的業務層建設，降低建設成本；
- 研發效率高：平台服務作為通用能力基建，業務只需要關注需求，不用關心平台底層復雜能力實現；
- 降低復雜性：平台都有合理的職責邊界和模塊划分，對外開發的接口也都直觀簡潔；
- 穩定性：平台服務的穩定性是重中之重，一般有專門的團隊維護，穩定性比一般的業務系統強；
平台化建設幾種方式
1、嵌入式
平台提供類似容器的功能，業務方以Jar包形式嵌入到平台當中，類似於傳統的多個war包部署在tomcat中。這種實現方式平台提供通用能力接口和業務擴展點，業務方實現業務擴展點來實現業務邏輯。一般有統一的入口（比如tomcat提供的域名+端口），根據租戶標識來區分業務方（比如tomcat的serverPath），平台底層的存儲及模型中也都有租戶ID標識。
優勢：
- 運維： 平台統一運維，業務方工作量降低；
- 對外接口：對外統一接口，調用者的工作量會降低；
劣勢：
- 業務方功能受限：一般不能做重量級任務，平台以擴展點方式提供給業務方擴展，除此之外的能力都應該被限制；
- jar包沖突、類沖突問題：平台本身包含了很多依賴，業務方jar包也會有很多依賴，如果有沖突會導致整個平台不可用，下文會介紹幾種規避方法；
- 業務隔離性差：不同業務方之間可能相互影響；
處理業務隔離的常用方案：
- 每個業務方提供一個集群；
- 使用類加載器隔離jar包，但可能依然解決不了jar包沖突的問題；
- 業務方提供fatjar，更改所有依賴包的package路徑，比如MavenShadePlugin插件；
2、接口依賴式
平台也可以通過遠程依賴的形式來整合業務的功能。這樣能避免jar包沖突、業務功能受限等問題。此方案也會有一些限制，比如原jar包依賴的方式都是本地調用，現在都是遠程調用，對性能、事務保證等都提出了新的挑戰；需要保證接口的兼容性；平台與業務的交互由原來對象交互變成RPC接口，設計到編解碼等；
這種方案適合平台與業務層交互較少、擴展點比較固定的場景，比如API渲染服務，平台提供渲染模板接口，業務方實現接口填充字段。
優勢：
- 隔離性：平台和業務完全隔離；
- 業務方方便整合其他業務：平台擴展點只是作為業務方的一種能力，可以在已有的服務上提供；
劣勢：
- 接口變更復雜：如果要變更接口，所有業務方都需要迭代；
- 交互復雜：都是通過RPC交互，一些擴展字段需要編解碼成String傳輸；
- 平台方兜底：如果業務方服務異常，平台方需要提供限流、降級、兜底的能力；
3、中台式
上面講到兩種模式都是以平台為主，對上層來說都是感知的平台，適合交互接口比較固定的場景，對交互差異性大的業務不是很適合。中台式的思路是提供業務通用能力，業務方基於中台能力快速開發自己的業務，並獨立提供服務或頁面。
中台和平台的區別：
- 視角不同：平台關注的是去重、整合；中台關注的是復用；
- 價值體現：平台直接對外提供服務，是一個功能大集合；中台是其他產品的一部分，為了其他產品更好的提供服務；
優勢：
- 能力聚焦：只需要提供核心能力支撐，不關心和用戶交互；
- 復用性更強：平台不依賴業務的擴展點，而只是業務方到平台的單向依賴；
劣勢：
- 個性化能力弱：因為沒有擴展點，只提供通用能力；
平台化建設常用模式
1、DSL領域特性語言
DSL（Domain Specific Language）是針對某一領域，具有受限表達性的一種計算機程序設計語言。 DSL 具備強大的表現力，常用於聚焦指定的領域或問題。
在平台化建設中，DSL一般用來屏蔽平台復雜的業務邏輯，以DSL的形式對業務方暴露簡潔能力接口。
比如非常有名的Gradle，就是一種DSL表達，具有比Maven更靈活的特性，關於如何構建DSL，請參考作者博客：使用Groovy構建DSL
2、Specification規約模式
Specification 模式用於解決「業務規則」相關的復雜性。
什么是業務規則呢？比如電商業務場景中需要判斷：賬戶有效狀態、是否是VIP、活動價有效期、賬戶余額等。在常規的代碼開發中，有三種處理方式：
- 在業務流程代碼中case by case的編寫；缺點是會導致能力復用性、可維護性越來越差；
- 新建靜態類，比如OrderValidator、TimeValidator等，缺點是處理組合邏輯（and、or）力不從心；
- 在模型類中校驗，缺點是類中會摻雜越來越多的非領域邏輯，這種邏輯太多會掩蓋業務核心的業務規則；
Specification模式認為校驗邏輯都是“動作”，需要單獨建模，且模型都是值對象，接口通用模式如下：
public interface Specification<T> {
boolean isMatch(T domainObject);
}
通過實現 Specification 接口，我們可以對不同的領域對象擴展不同的校驗邏輯，而這些類都是可以復用的。
同時這些 Specification 可以作為基礎元素進行任意的組合，組合更為復雜的校驗規則與篩選邏輯。
當然Specification 不僅僅適用於過濾數據，它的核心是組裝業務規則。例如 Spring Data JPA 提供了基於 JPA 的 Specification 模式的查詢功能，使用起來非常方便，以下是一個示例：
public List<Student> getStudent(String studentNumber, String name) {
Specification<Student> specification = new Specification<Student>(){
@Override
public Predicate toPredicate(Root<Student> root, CriteriaQuery<?> query, CriteriaBuilder cb) {
//用於暫時存放查詢條件的集合
List<Predicate> predicatesList = new ArrayList<>();
//equal
if (!StringUtils.isEmpty(name)){
Predicate namePredicate = cb.equal(root.get("name"), name);
predicatesList.add(namePredicate);
}
//like
if (!StringUtils.isEmpty(nickName)){
Predicate nickNamePredicate = cb.like(root.get("nickName"), '%'+nickName+'%');
predicatesList.add(nickNamePredicate);
}
//最終將查詢條件拼好然后return
Predicate[] predicates = new Predicate[predicatesList.size()];
return cb.and(predicatesList.toArray(predicates));
}
};
return repository.findAll(specification);
}
3、異構
平台提供的通用能力如果不能直接滿足業務的需求，需要提供擴展能力以適配業務模型來達到異構的目的。支持業務擴展模型一般有以下幾種方式：
- String ext
- Map<String,String> ext
- Class：一般用於嵌入jar式
還有另外一個問題需要解決，平台作為通用能力，有平台自身的模型，如何將平台模型轉換為業務模型？簡單的做法是作為擴展點開放給業務方實現，不過作為業務方，應該關注的是業務模型，平台模型有自己的規則且平台為了通用化，模型都會非常復雜。
一個更完善的平台應該支持更靈活的異構模型支持，常用是方案是字段配置化：
- 在平台申請一個模型的定義，一般包括類型，長度，限制規則等（比如必須是正整數）；
- 業務方配置字段和平台模型的映射關系，如果需要動態能力，可提供Groovy或Aviator等腳本支持；
- 轉換為業務方模型：根據用戶配置，自動轉換並給用戶返回業務模型；
- 轉化為平台模型：參數中需要傳入元數據類名，平台按照配置規則進行有效性校驗；如果需要自動轉化，則需要在配置服務支持雙向映射
4、統一存儲
平台除了平台通用模型的存儲支持，還需要支持不能轉換為平台模型業務模型存儲。有以下幾種方案：
- 寬表：采用列式存儲引擎，可方便的創建、修改列，缺點是常用的列式存儲引擎一般不能提供的很好的事務支持；
- 列轉行：數據表只有三列：id、key、value，查詢及存儲時在repository層進行轉換，缺點是不能join、不支持修改列；適用於不太復雜的業務場景；
- 元數據：完全接管數據庫操作，根據不同字段格式自動存儲到不同列，完善的元數據平台還支持分庫分表、擴縮容、數據遷移等能力，建設成本最高；
總結
平台化建設是一個非常復雜的工程，涉及的業務方、方案選擇比較多，難點和投入成本也都差異較大，沒有一套完美的方案能覆蓋所有業務場景，本文提供了幾種參考方案和設計模式，具體的方案還需要讀者結合自己的業務場景來挑選最適合自己的方案。
作者簡介：木小豐，美團Java技術專家，專注分享軟件研發實踐、架構思考。歡迎關注公共號：Java研發
本文鏈接：平台化建設思路淺談
