兩年PHPer聊下架構

前言

2016年頗有幸參與了公司內部系統架構3.0的升級，咱們把公司的業務進行了四大板塊的拆分，分別是應用服務、內容服務、電商服務、支付服務。其餘和業務無關的功能拆分到了基礎服務，爲全公司的業務提供基礎服務能力，例如短信、app推送、微信模板消息、圖片上傳等服務能力。咱們還創建咱們本身的網關服務，對外提供了統一的服務訪問地址。自此以後我對架構的發展和演變也產生了濃厚的興趣和想法，可是目前接觸的有限，與大公司的業務複雜度比仍是有很大的差距，一年過去了可是仍是想把本身經歷的作個總結和本身的想法表達出來，同時也但願大牛們能夠指導一番。

備註：「系統架構」是一個很大的範疇，我這裏只是把我所經歷的小型創業公司的一次架構升級作個分享。

實際架構

直接上最終的架構圖，以下：

• 網關: 企業服務總線，對外暴露統一的資源域，把實際業務中接口中都涉及簽名鑑權等一系列鑑權邏輯抽到網關，其次爲將來開放第三方服務準備。
• 協議層: 組裝各個服務的結果，把http協議的請求轉換成rpc請求(這裏咱們使用的是phprpc)。
• 業務服務: 實際的業務方，各類商業邏輯，如圖所示。
• 基礎服務: 基礎服務能力，和實際商業邏輯無關。

理論架構

上面的架構有什麼問題，協議層產生了重度的耦合，協議層耦合各個業務方的邏輯。雖然系統拆分的原則是儘量的不產生依賴，可是有些仍是不可避免的。

三方面：

• ①透傳：明明協議層不需對邏輯作特殊的處理，協議層卻要實現一遍代碼，增長了工做量
• ②組裝：協議層調用各個服務的組裝數據的時候，其實仍是下意識涉及了部分業務邏輯
• ③html5應用直接調用了協議層，沒有正真的實現企業總線

其次我認爲最恐怖的是負責協議層開發的同窗被坑了，寫透傳的代碼沒技術含量並且是重複性的工做，涉及數據組裝的，還得須要簡單的瞭解各個服務邏輯。從而這個協議層就成了耦合的重災區，因此我根據本身的想法改進了這個架構設計，架構圖以下：

• 改進一：html5應用也統一走網關，html5應用的請求執行對應的網關策略
• 改進二：下移協議層到網關，網關直接進行協議轉化
• 改進三：業務服務直接調用所依賴的服務，這樣咱們的服務就能夠業務直接經過網關暴露出去

更進一步的架構

然而上面的架構有什麼問題？業務服務內部互相依賴，一旦將來服務拆分的粒度愈來愈細，以及業務的新增，這些依賴就成了一個網狀結構，慢慢變的不可維護。接着我改進了這個架構圖，再進一步，應該是這樣的：

我把以前服務之間直接的互相依賴轉變成了統一對中間件的依賴，這樣將來再多的服務整個系統架構都是清晰的。

中間件具有的能力：

• 同步調用：直接經過對中間件的調用完成對服務的直接調用
• 異步調用：經過對中間件的調用完成對服務的異步調用

然而，這裏有個最大的問題就是全部壓力都集中到了中間件，保證中間件的高可用又成爲了一個很大的問題。

結語

除了上述的實際架構是真實的生產環境架構，其餘的爲我我的目前的想法，目前我的未真實在生產環境實現。最後說說實際踩的坑：

• 服務超時：網關設置了熔斷時間，致使服務剛提交事務卻被終端請求致使的數據一致性問題。再例如，剛發送短信成功，卻被中斷請求，客戶端返回失敗，實際卻接收到短信。
• 分佈式事務：跨服務調用使得事務的提交不像之前那麼簡單
• 若是開發人少，致使一我的維護多個項目
• 增長了部署難度
• 追蹤問題難度加深(咱們引入了requestId追蹤整個鏈路的調用過程)

Easy PHP：一個極速輕量級的PHP全棧框架

掃面下方二維碼關注個人技術公衆號，及時爲你們推送個人原創技術分享