站長資訊網(wǎng)
導語
我一直認為，現(xiàn)在的 PHP 已經(jīng)進展到了工程化的領域。以前的 PHP 開發(fā)者，以快為美，速度和規(guī)模永遠都是矛盾體?，F(xiàn)在的 PHP 項目，特別是稍微大型一點的項目中，已經(jīng)在逐漸演化成為需要兼顧工程化和規(guī)?；膶哟瘟恕Ｒ粋€代碼工程化，就意味著演化為逐漸復雜的架構。復雜的架構，微服務往往就是一個很好的選擇。
我在最近的一個項目中，就需要這個問題。我需要開發(fā)一個地圖服務，這個服務當然不是簡單的類庫形式，而是有自己的數(shù)據(jù)庫，自己的服務接口。這種情況其實最優(yōu)的選擇就是服務化。服務化的方式當然有很多了，Thrift，Http 等。但是我評估了下當前的部門環(huán)境，PHP 是主流的語言，加上自己這個項目的進度也比較緊，在我眼中，Thrift，Http 等方式都是使用網(wǎng)絡協(xié)議實現(xiàn)服務的解耦合，這在我看來已經(jīng)是重度解決方案了。我覺得在項目沒有明確清晰病入膏肓的情況下是沒有必要這種方式的。使用網(wǎng)絡協(xié)議服務化的劣勢在于引入了強大的復雜度。這個復雜度往往意味著人力，物力，時間上的投入。所以我希望，能夠提供一個 PHP 語言的 “服務類庫” 的形式進行開發(fā)。
我想到的就是 PHP 的 Composer。
Composer 的修改
創(chuàng)建服務類庫
首先，我需要把我的 “服務類庫” 從我的應用程序（起名為 xxx/main1）中獨立出來，這個獨立，我不是選擇在應用程序中創(chuàng)建一個目錄（事實我想過創(chuàng)建一個諸如 Services 的目錄）。但是，如果和業(yè)務程序在代碼上耦合起來，我覺得以人的惰性，很難從始至終都控制住自己能堅持不使用應用程序中方便的各種函數(shù)。所以我的選擇是在 Git 庫中新創(chuàng)建一個項目，起名為 xxx/mapService 。
composer.json
現(xiàn)在兩個 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 目錄下。
更新修改
我們現(xiàn)在編輯器在 main1 項目中，如果我們有對 mapService 這個項目有進行編輯修改，并且希望合并到 mapService 的 master 分支的化，就直接進入 vender/xxx/mapService 目錄，進行 Git 對應的操作。這樣就可以進行直接的代碼修改了。
獨立配置
這種結構的組合方式只是完成了萬里長征的第一步。后續(xù)更為重要的是在編寫這個服務的時候，我需要時刻記住不使用 main1 的所有東西，這樣才能保持 mapService 的獨立性（獨立性是服務化的必要條件之一）。比如我第一個遇到的問題就是配置文件需要獨立。
我的實現(xiàn)方式是直接在 mapService 中創(chuàng)建一個 Config 類，這個類中直接寫死配置。
這里一直覺得這個配置文件的實現(xiàn)方式有點挫，因為這樣，這個配置文件就進入到了 Git庫。但是確實沒有想到更好的方案了。Laravel 中有通過實現(xiàn) ServiceProvider 將 Config 創(chuàng)建在 Laravel 的config 文件夾下的方式，但是這種方式僅僅只適用于 Laravel。沒有通用性。在另外一個方向，我想服務使用哪個數(shù)據(jù)庫這個本身也是服務的一部分，放在服務的 Git 庫中貌似也沒有什么。
目錄結構
目錄結構如上
- Configs 提供配置文件
- Contracts 提供接口協(xié)議
- Exceptions 提供異常
- Supports 提供第三方方法或者類庫
- Models 提供對數(shù)據(jù)庫的交互
- Node.php 實現(xiàn)具體的接口
服務最重要的事情是接口協(xié)議。所以創(chuàng)建一個Contracts文件夾，將提供的服務接口化。
接口的異常處理盡量使用異常，而不是錯誤碼的方式進行交互。而且這些異常盡量要自定義。這樣，在上層就有了統(tǒng)一處理的可能性。
思考
這個架構模式我定位為 PHP 代碼層面服務化的模式。適用的場景應該是：
- 后期計劃服務化
- 前期人力和思維都希望維持快速開發(fā)的場景
和 Git 的 SubTree 、SubModule 的區(qū)別
其實這三種方式說到底都是將一個項目作為另外一個項目的類庫來使用的。SubTree 和 SubModule 是 Git 的解決方案。而 Composer 是 PHP 語言的解決方案，它除了將某個項目加入到另外一個項目的功能之外，還提供了加入版本，依賴解決等方案。如果你的項目是 PHP 的，那么無疑，使用 Composer 是更優(yōu)的選擇。
后期協(xié)議服務化
如果后期我的這個 mapService 想要協(xié)議服務化，那么這個 mapService 項目就可以簡化成為一個SDK，對于上層業(yè)務邏輯，只需要使用 composer update 進行更新就行。
服務注冊和發(fā)現(xiàn)
我這里所謂的 “服務類庫” 確實沒有解決服務注冊的問題，我無法知道到底有幾個項目使用了我的服務。這個可能需要額外的流程的工作了。
