詳解Composer+Git怎麼建立 「服務類庫」

導語

我一直認為，現在的 PHP 已經進展到了工程化的領域。以前的 PHP 開發者，以快為美，速度和規模永遠都是矛盾體。現在的 PHP 專案，特別是稍微大型一點的專案中，已經在逐漸演化成為需要兼顧工程化和規模化的層次了。一個程式碼工程化，就意味著演化為逐漸複雜的架構。複雜的架構，微服務往往就是一個很好的選擇。

我在最近的一個專案中，就需要這個問題。我需要開發一個地圖服務，這個服務當然不是簡單的類庫形式，而是有自己的資料庫，自己的服務介面。這種情況其實最優的選擇就是服務化。服務化的方式當然有很多了，Thrift，Http 等。但是我評估了下當前的部門環境，PHP 是主流的語言，加上自己這個專案的進度也比較緊，在我眼中，Thrift，Http 等方式都是使用網路協定實現服務的解耦合，這在我看來已經是重度解決方案了。我覺得在專案沒有明確清晰病入膏肓的情況下是沒有必要這種方式的。使用網路協定服務化的劣勢在於引入了強大的複雜度。這個複雜度往往意味著人力，物力，時間上的投入。所以我希望，能夠提供一個 PHP 語言的 「服務類庫」 的形式進行開發。

我想到的就是 PHP 的 Composer。

Composer 的修改

建立服務類庫

首先，我需要把我的 「服務類庫」 從我的應用程式（起名為 xxx/main1）中獨立出來，這個獨立，我不是選擇在應用程式中建立一個目錄（事實我想過建立一個諸如 Services 的目錄）。但是，如果和業務程式在程式碼上耦合起來，我覺得以人的惰性，很難從始至終都控制住自己能堅持不使用應用程式中方便的各種函數。所以我的選擇是在 Git 庫中新建立一個專案，起名為 xxx/mapService 。

composer.json

現在兩個 Git 專案(xxx/main1 和 xxx/mapService)，我在 main1 中的 composer.json 檔案中增加下面的語句：

而在 mapService 的 composer.json 如下：

這個設定告訴 main1 專案，mapService 的 Git地址，需要使用的版本。

當然需要注意下面幾點：

• dev-master 意思是直接使用 mapService 的master分支。如果 mapService 有其他的 tag，這裡完全可以使用 tag 資訊
• repositories 是說明專案的地址
• 我這裡的這個服務是放在我們公司自己搭建的 GitLab 上的
• mapService 下面的 src 資料夾的名稱空間為 xxxx\\xxxx\\MapService\\ 並且支援 PSR-4
• mapService 使用了 illuminate/database

最後使用 composer update -vvv 可以把我們需要的 mapService 下載下來放在 vendor 目錄下。

更新修改

我們現在編輯器在 main1 專案中，如果我們有對 mapService 這個專案有進行編輯修改，並且希望合併到 mapService 的 master 分支的化，就直接進入 vender/xxx/mapService 目錄，進行 Git 對應的操作。這樣就可以進行直接的程式碼修改了。

獨立設定

這種結構的組合方式只是完成了萬里長征的第一步。後續更為重要的是在編寫這個服務的時候，我需要時刻記住不使用 main1 的所有東西，這樣才能保持 mapService 的獨立性（獨立性是服務化的必要條件之一）。比如我第一個遇到的問題就是組態檔需要獨立。

我的實現方式是直接在 mapService 中建立一個 Config 類，這個類中直接寫死設定。

這裡一直覺得這個組態檔的實現方式有點挫，因為這樣，這個組態檔就進入到了 Git庫。但是確實沒有想到更好的方案了。Laravel 中有通過實現 ServiceProvider 將 Config 建立在 Laravel 的config 資料夾下的方式，但是這種方式僅僅只適用於 Laravel。沒有通用性。在另外一個方向，我想服務使用哪個資料庫這個本身也是服務的一部分，放在服務的 Git 庫中貌似也沒有什麼。

目錄結構

目錄結構如上

• Configs 提供組態檔
• Contracts 提供介面協定
• Exceptions 提供異常
• Supports 提供第三方方法或者類庫
• Models 提供對資料庫的互動
• Node.php 實現具體的介面

服務最重要的事情是介面協定。所以建立一個Contracts資料夾，將提供的服務介面化。

介面的例外處理儘量使用異常，而不是錯誤碼的方式進行互動。而且這些異常儘量要自定義。這樣，在上層就有了統一處理的可能性。

思考

這個架構模式我定位為 PHP 程式碼層面服務化的模式。適用的場景應該是：

• 後期計劃服務化
• 前期人力和思維都希望維持快速開發的場景

和 Git 的 SubTree 、SubModule 的區別

其實這三種方式說到底都是將一個專案作為另外一個專案的類庫來使用的。SubTree 和 SubModule 是 Git 的解決方案。而 Composer 是 PHP 語言的解決方案，它除了將某個專案加入到另外一個專案的功能之外，還提供了加入版本，依賴解決等方案。如果你的專案是 PHP 的，那麼無疑，使用 Composer 是更優的選擇。

後期協定服務化

如果後期我的這個 mapService 想要協定服務化，那麼這個 mapService 專案就可以簡化成為一個SDK，對於上層業務邏輯，只需要使用 composer update 進行更新就行。

服務註冊和發現

我這裡所謂的 「服務類庫」 確實沒有解決服務註冊的問題，我無法知道到底有幾個專案使用了我的服務。這個可能需要額外的流程的工作了。