詳解Composer+Git怎麼創建 '服務類別庫”

本文由composer教學專欄為大家介紹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 進行更新就行。

服務註冊和發現

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

以上是詳解Composer+Git怎麼創建 '服務類別庫”的詳細內容。更多資訊請關注PHP中文網其他相關文章！