一種支持泛型解析的PHPScf無痕化技術(shù)方案
1 背景介紹
PHP調(diào)用Java提供的接口，需要代碼轉(zhuǎn)化，使用scf調(diào)用。 目前有兩種技術(shù)方案： 架構(gòu)組方案和安居客方案。
架構(gòu)組方案如下所示：
右上圖展示了要轉(zhuǎn)換代碼需要填寫的信息，左上圖展示了整個接口調(diào)用所需要的步驟，依次總共需要8步。
架構(gòu)組這套方案是有缺陷的：
1.步驟繁瑣，耗時，溝通成本高。
2.無法解析泛型，需另開發(fā)一個不含有泛型的接口，比如XXXforPHP。
3.一個接口涉及多個服務(wù)調(diào)用，本地調(diào)試時無法同時調(diào)試線上和沙箱服務(wù)。
安居客方案如下:
右上圖展示了代碼轉(zhuǎn)化工具的使用方法，左上圖展示了實現(xiàn)接口調(diào)用的整個步驟，共需7步。
從架構(gòu)組方案迭代到安居客方案，溝通成本相對減少，但是也是有其缺陷的：
1.步驟還是相對比較復(fù)雜，比較耗時。
2.遇到泛型需要去詢問服務(wù)方是何種泛型，不能自動解析。
3.一個接口涉及多個服務(wù)調(diào)用，本地調(diào)試時無法同時調(diào)試線上和沙箱服務(wù)。
4.轉(zhuǎn)換代碼是一種離線模式，同時不能下載多個服務(wù)。
現(xiàn)在存在的問題有以下幾點：
1.步驟太多，既耗時開發(fā)效率也低。
2.代碼轉(zhuǎn)換完以后需要自己將代碼拷貝到項目中的指定目錄（有很多同學(xué)因為目錄拷貝錯誤導(dǎo)致接口調(diào)不通）。
3.泛型不能自動解析。
4.本地接口涉及多個服務(wù)時，不能同時調(diào)試線上和沙箱服務(wù)。
2 重構(gòu)思想
從現(xiàn)有方案可以看出，現(xiàn)在PHP調(diào)用Java接口步驟是很繁瑣的，開發(fā)效率偏低。 而且還有兩個問題： 泛型無法解析、不便本地調(diào)試。 所以要進(jìn)行重構(gòu)來解決這些問題。 重構(gòu)要圍繞下面三個方向進(jìn)行：
3 流程解析
圍繞現(xiàn)有問題進(jìn)行了重構(gòu)：
具體實現(xiàn)流程如下。
第一步：實現(xiàn)代碼工程化管理。
- 開發(fā)PHPbase服務(wù)解決Java代碼下載問題。
- 解析pom坐標(biāo)信息。根據(jù)坐標(biāo)拼接要下載jar包的URL，通過copyURLToFile將URL的信息下載到指定目錄下，也就是將服務(wù)的jar包下載下來。
- 解析下載的jar包。循環(huán)讀取jar包信息，碰到pom.xml文件讀取依賴信息，并下載。有的依賴version寫在了父pom的dependency內(nèi)，需要通過父pom讀取，還要兼顧version寫在屬性中的情況。父pom的依賴信息也要下載下來。獲取到所有的jar包，放到一個URL數(shù)組里，然后通過URLClassLoader解析，碰到以.class結(jié)尾的文件進(jìn)行判斷是contract？entity？enum? 流程圖如下：
- 解析contract。對于注解中有serverContract的就是contract文件。通過反射拿到類中含有的方法名字，以及入?yún)⒑统鰠?。參?shù)的類型包括一些基本類型string、int、bool等還會有一些復(fù)雜類型map、list、set等，還可能是泛型。對于復(fù)雜類型map、list等類型會繼續(xù)分析子元素的類型信息。假如是map類型，那它的子元素信息就是key_type:XXX,value_type:XXX。如果子元素中key_type是個object，那么它的key_class就是這個object的包名。同樣，如果子元素的value_type是個object，那么它的value_class就是這個object的包名。對于復(fù)雜類型list、set等也是如此分析。如果是泛型，它的elem_type賦值為object，elem_class賦值為java.lang.object。將方法名字拼接一個hash值（方法名+入?yún)?出參）再拼接一個字符串params代表入?yún)?，以這個字段為key，以入?yún)⒌念愋托畔関alue放到變量paramVar中。同樣方法名字拼接一個hash值（方法名+入?yún)?出參）再拼接一個字符串return代表出參，以這個字段為key，以出參的類型信息為value也放到變量paramVar中。入?yún)⒑统鰠⒌木唧w信息可以看下圖。最后以contract類的包名信息為key，paramVar為value放入變量contractMap中。
- 解析entity。如果注解SCFSerializable=true and SCFMember=true，就是一個entity文件。通過SCFMember獲取到字段的信息：var、orderID、generic，將這些信息放入變量TSPEC中，key是orderId的值，value就是這些字段的信息。 對于字段類型分析同contract中類型分析是一致的，在此不贅述了。如果這個實體有繼承關(guān)系，要將繼承信息也放入變量TSPEC中。key是999，value是繼承信息。如果注解SCFSerializable.name不為空，將這個值也放入變量TSPEC中。key是998，value是注解SCFSerializable.name的值。最后以entity類的包名信息為key，TSPCE為value放入entityMap中。
- 解析enum。如果isEnum=true的就是枚舉文件。通過反射獲取字段信息也就是constant信息，放入enumMap中，key是枚舉類的包名，value是各個常量值。
- 返回結(jié)果。將contract、entity、enum這三個信息組裝在一起放入Json中作為結(jié)果返回，如下圖所示也就是最下面的這個圖。
- 開發(fā)build.php來實現(xiàn)Java代碼到PHP代碼的轉(zhuǎn)化，解決現(xiàn)在代碼需要人工拷貝的問題。流程圖如下：
從PHPbase拿到解析坐標(biāo)后的數(shù)據(jù)，也就是那個JSON數(shù)據(jù)，反解析獲取到三個包含contract、entity、enum的數(shù)組。
下面三個圖展示了三個數(shù)組的部分具體內(nèi)容：
第一個圖是截取的contract數(shù)組中的部分信息。key是一個完整的包名，value就是這個類中的所有函數(shù)信息。我們看下第一個方法，key是由方法名字+hash值+params字符串組成。value就是入?yún)⒌念愋托畔ⅲ梢钥吹接衧tring，有object。類型是object 的就有這個對象對應(yīng)的class信息。params是入?yún)?，帶有return的就是出參信息。
第二個圖是截取的entity數(shù)組中的部分信息。我們看到key是一個完整的包名，value是實體的字段信息。比如第一個字段排序是第一個，不是泛型，類型是list，子元素類型是object，elem_class就是這個object的包名信息。key為998對應(yīng)的value就是Java中注解SCFSerializer.name的值
第三個圖是截取的enum數(shù)組中的部分信息。key是完整包名，value就是各個常量的值。
數(shù)組信息分析完，看下具體解析過程。contract數(shù)組解析流程圖如下所示：
拿到contract數(shù)組循環(huán)遍歷，對于類文件的目錄我們用的是包名+固定路徑“Libs/wscfcore/package”，為了防止和項目中已有的代碼相區(qū)別，我們將代碼放到了libs/wscfcore/package下。命名空間也是包名信息+剛才那個固定路徑，大家可以看下右上方這個圖。對于類文件的依賴，也是包括兩部分，一個是固定的依賴 “use libswscfcoreclient”，這個是因為類中的構(gòu)造方法用到了scf client的實例化。依賴的另一部分就是參數(shù)中用到的引用。生成方法的時候要考慮兩個問題，一個是重名問題，一個是序列化問題。
當(dāng)方法重名的時候我們用0，1來進(jìn)行區(qū)分，比如getInfo0，getInfo1。這里面有一個坑，就是要考慮下每次生成這個方法時的順序問題，因為方法重名里面的參數(shù)個數(shù)是不一樣的，所以名字絕對不能變換順序。我們?yōu)榱朔乐拱l(fā)生順序變更問題，在Java代碼生成的時候用到了一個hash值。就是將方法名、入?yún)?、出參做了一個hash值，這個肯定是唯一的，通過這個來保證順序不變。
生成方法的時候還要考慮第二個問題那就是序列化的問題，我們看下右上方這個圖，對于第四個參數(shù)的類型是非基礎(chǔ)類型，所以這個類型序列化時對應(yīng)的typeID也就是hash值就從這個類的包名來獲取，通過在這建立全局?jǐn)?shù)組，在后邊生成typeID的時候獲取這個參數(shù)的包名信息。$params這個參數(shù)里面包含了lookup，methodName，以及入?yún)⑿畔ⅰ?/p>
entity數(shù)組解析流程圖如下所示：
生成實體的過程中也要生成目錄，命名空間，依賴。這些同contract的分析是一樣的，就不贅述了。實體的構(gòu)造方法我們看右上圖可以看出是對靜態(tài)變量TSPEC賦值的過程。這個變量是一個數(shù)組，里面包含了各個字段的信息，名字var，順序orderID，是不是泛型isGeneric，以及類型type。對于復(fù)雜類型list也要生成它的子元素的類型。這個類型信息在從服務(wù)器拿到二進(jìn)制流數(shù)據(jù)進(jìn)行反序列化的時候要用到，類型必須和其相同才能正確的解析出來。如果這個實體類有繼承，那么也要生成這個類的繼承類。
enum數(shù)組解析如下圖所示：
Enum的解析就簡單些了。要生成目錄，命名空間，const信息。const信息遍歷enum數(shù)組即可。到這Java代碼到PHP代碼的轉(zhuǎn)化就完成了，并生成在了指定位置。我們再也不用手動拷貝代碼了。避免了因為拷貝代碼路徑出錯導(dǎo)致的接口調(diào)不通問題。
- 引入一個service.xml文件來管理服務(wù)版本信息，所有要下載的服務(wù)都寫在這里，采用XML格式的文件，開發(fā)同學(xué)直接將坐標(biāo)信息復(fù)制到這里即可，方便開發(fā)同學(xué)使用。
第二步：解決泛型解析問題。
Java同學(xué)是知道泛型對應(yīng)的具體是何種類型，就是他們開發(fā)的實體中的某一個，不過PHP同學(xué)是不知道的。但是這個泛型序列化以后的typeID值也就是hashcode值我們可以拿到，那么我們將所有實體做一個hash計算，然后我們反推是不是就可以知道泛型是哪個實體了呢？
所以優(yōu)化build.php文件，收集服務(wù)的實體和枚舉信息，進(jìn)行hash計算。我們現(xiàn)在有scfv1、scfv3兩種協(xié)議，不同協(xié)議對應(yīng)的typeID是不同的，所以針對這兩種協(xié)議進(jìn)行hash計算。對于scfv1協(xié)議，若實體中有scheme字段（998），那么對scheme字段進(jìn)行。若沒有，則對類名進(jìn)行hash計算。而對于scfv3協(xié)議是對整個包名進(jìn)行計算。有了這個hash文件就可以解析泛型了。
第三步：解決本地?zé)o法同時調(diào)試線上和沙箱服務(wù)的問題。增加沙箱配置文件，方便開發(fā)者進(jìn)行調(diào)試。文件如下圖所示：
服務(wù)名字和沙箱IP要準(zhǔn)確對應(yīng)上。底層獲取服務(wù)信息時，判斷有此文件，拿到服務(wù)的信息就可以直接走沙箱服務(wù)了。對于不存在于此文件的服務(wù)是走線上的。如果將代碼放到沙箱環(huán)境，灰度的申請就可以用這個文件代替了，省去了申請的操作。
第四步：將步驟由8步減少為3步。
- 將Java的pom坐標(biāo)信息放入service.xml文件中。
- 執(zhí)行build文件，響應(yīng)信息如下圖所示。從service.xml中獲取坐標(biāo)信息，檢查是否已經(jīng)下載過該服務(wù)。若沒有下載過，掉PHPbase拉取Java代碼，然后轉(zhuǎn)化為PHP代碼，并放到項目中的指定位置。
- 接口調(diào)用。運用反射機制實例化調(diào)用類，然后再調(diào)用類中的方法。
下面這個圖是IHouseService類的內(nèi)容，可以看到實例化此類要傳入服務(wù)名serviceName，查找類lookup，分別對應(yīng)上圖中的hmc、HouseService
4.無痕調(diào)用
從集團(tuán)方案迭代到租房方案，調(diào)用步驟由原來的八步減少到了現(xiàn)在的三步。
租房方案的實現(xiàn)代碼的目錄結(jié)構(gòu)展示如下所示：
wscfcore這個目錄是包括了所有scf相關(guān)的文件。Hashdata這個目錄里面放的是hash文件。package.lock里面存儲了所有項目中目前已經(jīng)下載的服務(wù)坐標(biāo)信息，存的是字符串。package目錄里面存的是所有下載的代碼。Build文件是整個代碼的核心，根據(jù)坐標(biāo)拉取Java代碼然后再轉(zhuǎn)化為PHP代碼放在指定位置。service.xml文件是存放我們要下載的服務(wù)的pom坐標(biāo)，采用xml格式方便大家直接將坐標(biāo)信息復(fù)制粘貼即可。wscfcore目錄會放到composer中供大家下載使用。
PHP同學(xué)用這套代碼，調(diào)用某個服務(wù)的接口時，實現(xiàn)了PHP同學(xué)調(diào)Java接口就像Java同學(xué)調(diào)Java接口是一樣的，是一種無痕式的調(diào)用。
