漫談社區PHP 業務開發

在當前這個互聯網業務飛速發展時期，新的產品如雨後春筍般涌出，老產品線新業務也在不斷突破和嘗試。這就對快速開發迭代提出了更高的要求。

1、基礎運行環境

針對新產品的開發，必須可以快速搭建一套LAMP架構。那麼無外乎選擇一個webserver，選擇一個php版本，選擇一個mysql版本，再選擇一個PHP開發框架和選擇一些php通用擴展和基礎庫等。這個過程讀者可能以爲已經很快了，能不能更快？

選擇的過程要求研發同窗對相關技術方向有必定的積累，權衡利弊和優先點，又是一番調研和學習。若是有一鍵安裝程序，提供自動化安裝webserver，php，mysql，以及攜帶高性能靈活的php開發框架，並提供標準化、安全、經常使用的配置文件，能夠大大縮短產品線LAMP系統調研的成本，縮短工做週期。

 

一鍵安裝四步驟：（1）下載；（2）少許配置；（3）make install；（4）start；（固然有end啦，簡單的運維工具），運行環境OK。

2、業務開發框架

社區產品線各自爲政，封閉得開發各自的業務邏輯。而事實上，各個產品線之間存在不少通用業務邏輯處理，如session驗證、權限判斷、參數驗證、日誌打印等。不一樣產品線，全部請求都須要作這些處理，能不能不重複開發？無線業務開發和PC上的業務邏輯有不少的不一樣，但不一樣產品線之間也有不少通用性。能不能不重複開發？

產品線在內部一般對這些通用邏輯的處理作了必定的抽象，設計爲ActionChain的形式或者經過基類的方案。框架將更完全：將這些全部請求都要處理的通用邏輯以業務邏輯框架的形式提供，研發同窗只須要關注用戶請求專有的邏輯處理。

一個用戶請求的處理邏輯以下圖：藍色部分是控制器框架處理流程，綠色部分和控制器框架相結合，處理全部請求通用的業務邏輯。而真正須要研發同窗關注和開發的該用戶請求專有的業務處理，即×××部分（固然一個不只僅是一個Action腳本，一個請求的處理會橫向作mvc分層，這塊後續會有涉及。）

業務邏輯框架繼承在一鍵安裝程序中提供，簡簡單單就能夠得到。

原生的PHP業務和模板耦合很深，沒有作任何的分層設計，其結果是代碼的複用性差。這樣的原始的PHP系統如今已幾乎消亡。PHP開發框架統一處理路由、渲染、AutoLoad，通用業務邏輯的抽象和基礎庫的抽象，專有業務MVC分層，已大大加快了產品線業務邏輯的開發。以下圖所示：

從上而下，分別是接入層（高性能webserver），PHP開發框架（路由、自動加載、視圖引擎等），應用和基礎庫，存儲引擎。

3、通用服務

社區產品線存在不少共同的需求，如日誌處理、配置文件的處理、字符串處理、數據庫交互、網絡交互等。這些算法和工具封裝成phplib給產品線使用已比較成熟。

社區類產品線的業務功能存在不少的通用性，諸如評論功能、Tag功能、好友功能、圖冊、任務系統等，在衆多社區產品線都有相似的新功能新需求，各自設計開發？

這些需求在各產品線的UI上有個性化需求，可是後端實現方案大同小異，具備必定的通用性。功能服務化，提供API接口給不一樣產品線使用，產品線只須要關注展示邏輯和私有數據的處理邏輯便可，且服務統一運維，下降產品下的系統複雜度。

4、垂直拆分子系統

那麼隨着咱們業務的拓展，單個應用內部的ui和module的數量愈來愈多，Action和Logic（對應MVC中的M層，內部能夠再進一步作分層處理，這次不詳述）的交互，logic和logic之間的交互變得愈來愈複雜。開發同窗須要瞭解整個應用的邏輯，某個logic的升級，須要排查整個應用下是否存在其餘ui或logic的反向依賴。在快速開發的要求下，開發同窗對logic之間的相互耦合關係的梳理不清楚，勢必引起愈來愈多的問題，影響項目質量，難以開始開發。

單一系統的問題暴露愈來愈多，就到了系統拆分的時候了。如何拆？按業務邏輯垂直拆分。將功能獨立的業務邏輯剝離出來，作成獨立的子系統。這個時候還須要考慮業務的通用性，是否能夠服務化？應用已有相同需求的通用服務？此時通用業務邏輯封裝成通用服務或使用了通用服務，旁路的業務邏輯獨立成子系統，如此一來就將原先單一龐大的系統作了大量減負。完成此階段的重構後，系統加入變成以下：

單一系統被拆分紅多個APP(APP內部仍然有橫向的MVC分層)，並複用大量的通用服務。如此一來研發團隊在人員分工並行開發上都獲得了極大提升。

5、跨系統調用框架

然而真實的現狀，在拆分後的子系統之間並不能徹底消除依賴。爲了解決多個子系統之間數據依賴的關係，須要一套統一的解決方案：API框架。子系統成爲獨立的應用（APP），APP之間存在相互的數據依賴，這些依賴以API的形式對外提供。以下圖：

當APP1依賴APP2或APP3的數據後，APP2和APP3會將一部分數據接口以API的形式提供，數據作統一的打包，經過標準規範的URL提供產品線內部其餘APP調用。這種形式很是相似於一個產品對外開放API（對第三方開放API，咱們稱爲openAPI，遵照統一的協議，並通過必要的權限驗證），而解決內部子系統之間數據依賴的API接口能夠進一步簡化。

APP提供的API解決提供接口描述（輸入、輸出），處理API的URL，Logic的轉發實現。API_LIB統一來管理全部的API接口，並提供統一的API_Server::call接口供調用。徹底對上屏蔽內部的轉發和實現細節。一般產品線內部爲了達到運維的簡化和統一，全部的子系統是同機部署的，API接口的會帶來額外的網絡消耗，以及增大qps。在此部署前提下，API_Server的實現方式能夠經過HTTP調用或優化爲直接PHPRequire方式實現。優點：

（1）框架統一，接口收斂，業務解耦；

（2）性能提高，易用性高，擴展性高；

6、UI拆分模型

此時獨立出來的子系統能夠專一作其業務邏輯了，核心的系統也獲得減負。可是核心系統的升級更新頻率是最高的，業務邏輯也最複雜。到了必定時期，核心系統又變得臃腫，難以維護。此時能夠經過一些設計模式來下降程序的可擴展性和可維護性。但即使是如此，仍是有必定的學習成本，在一個App內部，開發同窗或多或少須要關注其餘模塊的代碼，逐漸發展爲升級一點就須要排查不少點。這時候又到了進一步減負的時候。若是減負？分爲兩部：

第一步：異步模型

頁面渲染分爲兩個階段：主題頁面數據和其餘非主題頁面數據。根據頁面的不一樣部分由不一樣的數據源提供數據。按此邏輯將app進一步作垂直拆分。

PHPService是由PHPmodule+一層很薄的UI，返回格式化數據。

第二步：同步模型

Module作拆分，不一樣業務邏輯拆分爲不一樣的Module，區分爲多個數據源，分別提供不一樣數據內容，由統一的UI調度不一樣的數據源後，統一進行渲染頁面返回響應。

如此持續減負後，產品線內部的子系統和模塊將愈來愈多，須要維持部署和運維的統一。對團隊成員的分工很細，業務理解很專一和深刻，合做、並行的效率也會更高，從而使整個開發週期縮短。

7、 小結

隨着業務邏輯的不端壯大，每一個子系統或模塊的業務功能若是過於臃腫就須要不斷作減分，以保持在可控的規模內。如此隨着產品的發展，產品線內部的子系統和模塊將愈來愈多，須要維持部署和運維的統一，保持簡單。對團隊成員的分工更細，業務理解保持專一和深刻，合做、並行的效率也會更高，從而使整個開發週期縮短。

by luhaixia