1 背景介紹

PHP調用Java提供的接口，需要代碼轉化，使用scf調用。 目前有兩種技術方案： 架構組方案和安居客方案。

架構組方案如下所示：

右上圖展示了要轉換代碼需要填寫的信息，左上圖展示了整個接口調用所需要的步驟，依次總共需要8步。

架構組這套方案是有缺陷的：

1.步驟繁瑣，耗時，溝通成本高。

2.無法解析泛型，需另開發一個不含有泛型的接口，比如XXXforPHP。

3.一個接口涉及多個服務調用，本地調試時無法同時調試線上和沙箱服務。

安居客方案如下:

右上圖展示了代碼轉化工具的使用方法，左上圖展示了實現接口調用的整個步驟，共需7步。

從架構組方案迭代到安居客方案，溝通成本相對減少，但是也是有其缺陷的：

1.步驟還是相對比較復雜，比較耗時。

2.遇到泛型需要去詢問服務方是何種泛型，不能自動解析。

3.一個接口涉及多個服務調用，本地調試時無法同時調試線上和沙箱服務。

4.轉換代碼是一種離線模式，同時不能下載多個服務。

現在存在的問題有以下幾點：

1.步驟太多，既耗時開發效率也低。

2.代碼轉換完以后需要自己將代碼拷貝到項目中的指定目錄（有很多同學因為目錄拷貝錯誤導致接口調不通）。

3.泛型不能自動解析。

4.本地接口涉及多個服務時，不能同時調試線上和沙箱服務。

2 重構思想

從現有方案可以看出，現在PHP調用Java接口步驟是很繁瑣的，開發效率偏低。 而且還有兩個問題： 泛型無法解析、不便本地調試。 所以要進行重構來解決這些問題。 重構要圍繞下面三個方向進行：

3 流程解析

圍繞現有問題進行了重構：

具體實現流程如下。

第一步：實現代碼工程化管理。

• 開發PHPbase服務解決Java代碼下載問題。

1. 解析pom坐標信息。根據坐標拼接要下載jar包的URL，通過copyURLToFile將URL的信息下載到指定目錄下，也就是將服務的jar包下載下來。 
2. 解析下載的jar包。循環讀取jar包信息，碰到pom.xml文件讀取依賴信息，并下載。有的依賴version寫在了父pom的dependency內，需要通過父pom讀取，還要兼顧version寫在屬性中的情況。父pom的依賴信息也要下載下來。獲取到所有的jar包，放到一個URL數組里，然后通過URLClassLoader解析，碰到以.class結尾的文件進行判斷是contract？entity？enum? 流程圖如下：

3. 解析contract。對于注解中有serverContract的就是contract文件。通過反射拿到類中含有的方法名字，以及入參和出參。參數的類型包括一些基本類型string、int、bool等還會有一些復雜類型map、list、set等，還可能是泛型。對于復雜類型map、list等類型會繼續分析子元素的類型信息。假如是map類型，那它的子元素信息就是key_type:XXX,value_type:XXX。如果子元素中key_type是個object，那么它的key_class就是這個object的包名。同樣，如果子元素的value_type是個object，那么它的value_class就是這個object的包名。對于復雜類型list、set等也是如此分析。如果是泛型，它的elem_type賦值為object，elem_class賦值為java.lang.object。將方法名字拼接一個hash值（方法名+入參+出參）再拼接一個字符串params代表入參，以這個字段為key，以入參的類型信息為value放到變量paramVar中。同樣方法名字拼接一個hash值（方法名+入參+出參）再拼接一個字符串return代表出參，以這個字段為key，以出參的類型信息為value也放到變量paramVar中。入參和出參的具體信息可以看下圖。最后以contract類的包名信息為key，paramVar為value放入變量contractMap中。
4. 解析entity。如果注解SCFSerializable=true and SCFMember=true，就是一個entity文件。通過SCFMember獲取到字段的信息：var、orderID、generic，將這些信息放入變量TSPEC中，key是orderId的值，value就是這些字段的信息。 對于字段類型分析同contract中類型分析是一致的，在此不贅述了。如果這個實體有繼承關系，要將繼承信息也放入變量TSPEC中。key是999，value是繼承信息。如果注解SCFSerializable.name不為空，將這個值也放入變量TSPEC中。key是998，value是注解SCFSerializable.name的值。最后以entity類的包名信息為key，TSPCE為value放入entityMap中。
5. 解析enum。如果isEnum=true的就是枚舉文件。通過反射獲取字段信息也就是constant信息，放入enumMap中，key是枚舉類的包名，value是各個常量值。
6. 返回結果。將contract、entity、enum這三個信息組裝在一起放入Json中作為結果返回，如下圖所示也就是最下面的這個圖。

• 開發build.php來實現Java代碼到PHP代碼的轉化，解決現在代碼需要人工拷貝的問題。流程圖如下：

從PHPbase拿到解析坐標后的數據，也就是那個JSON數據，反解析獲取到三個包含contract、entity、enum的數組。

下面三個圖展示了三個數組的部分具體內容：

第一個圖是截取的contract數組中的部分信息。key是一個完整的包名，value就是這個類中的所有函數信息。我們看下第一個方法，key是由方法名字+hash值+params字符串組成。value就是入參的類型信息，可以看到有string，有object。類型是object 的就有這個對象對應的class信息。params是入參，帶有return的就是出參信息。

第二個圖是截取的entity數組中的部分信息。我們看到key是一個完整的包名，value是實體的字段信息。比如第一個字段排序是第一個，不是泛型，類型是list，子元素類型是object，elem_class就是這個object的包名信息。key為998對應的value就是Java中注解SCFSerializer.name的值

第三個圖是截取的enum數組中的部分信息。key是完整包名，value就是各個常量的值。

數組信息分析完，看下具體解析過程。contract數組解析流程圖如下所示：

拿到contract數組循環遍歷，對于類文件的目錄我們用的是包名+固定路徑“Libs/wscfcore/package”，為了防止和項目中已有的代碼相區別，我們將代碼放到了libs/wscfcore/package下。命名空間也是包名信息+剛才那個固定路徑，大家可以看下右上方這個圖。對于類文件的依賴，也是包括兩部分，一個是固定的依賴 “use libswscfcoreclient”，這個是因為類中的構造方法用到了scf client的實例化。依賴的另一部分就是參數中用到的引用。生成方法的時候要考慮兩個問題，一個是重名問題，一個是序列化問題。

當方法重名的時候我們用0，1來進行區分，比如getInfo0，getInfo1。這里面有一個坑，就是要考慮下每次生成這個方法時的順序問題，因為方法重名里面的參數個數是不一樣的，所以名字絕對不能變換順序。我們為了防止發生順序變更問題，在Java代碼生成的時候用到了一個hash值。就是將方法名、入參、出參做了一個hash值，這個肯定是唯一的，通過這個來保證順序不變。

生成方法的時候還要考慮第二個問題那就是序列化的問題，我們看下右上方這個圖，對于第四個參數的類型是非基礎類型，所以這個類型序列化時對應的typeID也就是hash值就從這個類的包名來獲取，通過在這建立全局數組，在后邊生成typeID的時候獲取這個參數的包名信息。$params這個參數里面包含了lookup，methodName，以及入參信息。

entity數組解析流程圖如下所示：

生成實體的過程中也要生成目錄，命名空間，依賴。這些同contract的分析是一樣的，就不贅述了。實體的構造方法我們看右上圖可以看出是對靜態變量TSPEC賦值的過程。這個變量是一個數組，里面包含了各個字段的信息，名字var，順序orderID，是不是泛型isGeneric，以及類型type。對于復雜類型list也要生成它的子元素的類型。這個類型信息在從服務器拿到二進制流數據進行反序列化的時候要用到，類型必須和其相同才能正確的解析出來。如果這個實體類有繼承，那么也要生成這個類的繼承類。

enum數組解析如下圖所示：

Enum的解析就簡單些了。要生成目錄，命名空間，const信息。const信息遍歷enum數組即可。到這Java代碼到PHP代碼的轉化就完成了，并生成在了指定位置。我們再也不用手動拷貝代碼了。避免了因為拷貝代碼路徑出錯導致的接口調不通問題。

• 引入一個service.xml文件來管理服務版本信息，所有要下載的服務都寫在這里，采用XML格式的文件，開發同學直接將坐標信息復制到這里即可，方便開發同學使用。

第二步：解決泛型解析問題。

Java同學是知道泛型對應的具體是何種類型，就是他們開發的實體中的某一個，不過PHP同學是不知道的。但是這個泛型序列化以后的typeID值也就是hashcode值我們可以拿到，那么我們將所有實體做一個hash計算，然后我們反推是不是就可以知道泛型是哪個實體了呢？

所以優化build.php文件，收集服務的實體和枚舉信息，進行hash計算。我們現在有scfv1、scfv3兩種協議，不同協議對應的typeID是不同的，所以針對這兩種協議進行hash計算。對于scfv1協議，若實體中有scheme字段（998），那么對scheme字段進行。若沒有，則對類名進行hash計算。而對于scfv3協議是對整個包名進行計算。有了這個hash文件就可以解析泛型了。

第三步：解決本地無法同時調試線上和沙箱服務的問題。增加沙箱配置文件，方便開發者進行調試。文件如下圖所示：

服務名字和沙箱IP要準確對應上。底層獲取服務信息時，判斷有此文件，拿到服務的信息就可以直接走沙箱服務了。對于不存在于此文件的服務是走線上的。如果將代碼放到沙箱環境，灰度的申請就可以用這個文件代替了，省去了申請的操作。

第四步：將步驟由8步減少為3步。

• 將Java的pom坐標信息放入service.xml文件中。
• 執行build文件，響應信息如下圖所示。從service.xml中獲取坐標信息，檢查是否已經下載過該服務。若沒有下載過，掉PHPbase拉取Java代碼，然后轉化為PHP代碼，并放到項目中的指定位置。

• 接口調用。運用反射機制實例化調用類，然后再調用類中的方法。

下面這個圖是IHouseService類的內容，可以看到實例化此類要傳入服務名serviceName，查找類lookup，分別對應上圖中的hmc、HouseService

4.無痕調用

從集團方案迭代到租房方案，調用步驟由原來的八步減少到了現在的三步。

租房方案的實現代碼的目錄結構展示如下所示：

wscfcore這個目錄是包括了所有scf相關的文件。Hashdata這個目錄里面放的是hash文件。package.lock里面存儲了所有項目中目前已經下載的服務坐標信息，存的是字符串。package目錄里面存的是所有下載的代碼。Build文件是整個代碼的核心，根據坐標拉取Java代碼然后再轉化為PHP代碼放在指定位置。service.xml文件是存放我們要下載的服務的pom坐標，采用xml格式方便大家直接將坐標信息復制粘貼即可。wscfcore目錄會放到composer中供大家下載使用。

PHP同學用這套代碼，調用某個服務的接口時，實現了PHP同學調Java接口就像Java同學調Java接口是一樣的，是一種無痕式的調用。