一、基礎運行環(huán)境

　　針對新產品的開發(fā)，必需能夠快速搭建一套LAMP架構。那么無外乎選擇一個webserver，選擇一個php版本，選擇一個mysql版本，再選擇一個PHP開發(fā)框架和選擇一些php通用擴展和基礎庫等。這個過程讀者可能覺得已經很快了，能不能更快?

　　選擇的過程要求研發(fā)同學對相關技術方向有一定的積累，權衡利弊和優(yōu)先點，又是一番調研和學習。假如有一鍵安裝程序，提供自動化安裝webserver，php，mysql，以及攜帶高機能靈活的php開發(fā)框架，并提供尺度化、安全、常用的配置文件，可以大大縮短產品線LAMP系統(tǒng)調研的本錢，縮短工作周期。

　　一鍵安裝四步驟：(1)下載;(2)少量配置;(3)make install;(4)start;(當然有end啦，簡樸的運維工具)，運行環(huán)境OK。

　　二、業(yè)務開發(fā)框架

　　社區(qū)產品線各自為政，封鎖得開發(fā)各自的業(yè)務邏輯。而事實上，各個產品線之間存在良多通用業(yè)務邏輯處理，如session驗證、權限判定、參數(shù)驗證、日志打印等。不同產品線，所有哀求都需要做這些處理，能不能不重復開發(fā)?無線業(yè)務開發(fā)和PC上的業(yè)務邏輯有良多的不同，但不同產品線之間也有良多通用性。能不能不重復開發(fā)?

　　產品線在內部通常對這些通用邏輯的處理做了一定的抽象，設計為ActionChain的形式或者通過基類的方案�？蚣軐⒏鼜氐祝簩⑦@些所有哀求都要處理的通用邏輯以業(yè)務邏輯框架的形式提供，研發(fā)同學只需要關注用戶哀求專有的邏輯處理。

　　業(yè)務邏輯框架繼續(xù)在一鍵安裝程序中提供，簡簡樸單就可以獲得。

　　原生的PHP業(yè)務和模板耦合很深，沒有做任何的分層設計，其結果是代碼的復用性差。這樣的原始的PHP系統(tǒng)現(xiàn)在已幾乎消亡。PHP開發(fā)框架同一處理路由、渲染、AutoLoad，通用業(yè)務邏輯的抽象和基礎庫的抽象，專有業(yè)務MVC分層，已大大加快了產品線業(yè)務邏輯的開發(fā)。

　　三、通用服務

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

　　社區(qū)類產品線的業(yè)務功能存在良多的通用性，諸如評論功能、Tag功能、摯友功能、圖冊、任務系統(tǒng)等，在眾多社區(qū)產品線都有類似的新功能新需求，各自設計開發(fā)?

　　這些需求在各產品線的UI上有個性化需求，但是后端實現(xiàn)方案大同小異，具有一定的通用性。功能服務化，提供API接口給不同產品線使用，產品線只需要關注展現(xiàn)邏輯和私有數(shù)據(jù)的處理邏輯即可，且服務同一運維，降低產品下的系統(tǒng)復雜度。

　　四、垂直拆分子系統(tǒng)

　　那么跟著我們業(yè)務的拓展，單個應用內部的ui和module的數(shù)目越來越多，Action和Logic(對應MVC中的M層，內部可以再進一步做分層處理，此次不臚陳)的交互，logic和logic之間的交互變得越來越復雜。開發(fā)同學需要了解整個應用的邏輯，某個logic的進級，需要排查整個應用下是否存在其他ui或logic的反向依靠。在快速開發(fā)的要求下，開發(fā)同學對logic之間的相互耦合關系的梳理不清晰，勢必引發(fā)越來越多的題目，影響項目質量，難以開始開發(fā)。

　　單一系統(tǒng)的題目暴露越來越多，就到了系統(tǒng)拆分的時候了。如何拆?按業(yè)務邏輯垂直拆分。將功能獨立的業(yè)務邏輯剝離出來，做成獨立的子系統(tǒng)。這個時候還需要考慮業(yè)務的通用性，是否可以服務化?應用已有相同需求的通用服務?此時通用業(yè)務邏輯封裝成通用服務或使用了通用服務，旁路的業(yè)務邏輯獨立成子系統(tǒng)，如斯一來就將原先單一龐大的系統(tǒng)做了大量減負。完成此階段的重構后，系統(tǒng)加入變成如下：
 

　　單一系統(tǒng)被拆分成多個APP(APP內部仍舊有橫向的MVC分層)，并復用大量的通用服務。如斯一來研發(fā)團隊在職員分工并行開發(fā)上都得到了極大進步。

　　五、跨系統(tǒng)調用框架

　　然而真實的現(xiàn)狀，在拆分后的子系統(tǒng)之間并不能完全消除依靠。為了解決多個子系統(tǒng)之間數(shù)據(jù)依靠的關系，需要一套同一的解決方案：API框架。子系統(tǒng)成為獨立的應用(APP)，APP之間存在相互的數(shù)據(jù)依靠，這些依靠以API的形式對外提供。
　　APP提供的API解決提供接口描述(輸入、輸出)，處理API的URL，Logic的轉發(fā)實現(xiàn)。API_LIB同一來治理所有的API接口，并提供同一的API_Server::call接口供調用。完全對上屏蔽內部的轉發(fā)和實現(xiàn)細節(jié)。通常產品線內部為了達到運維的簡化和同一，所有的子系統(tǒng)是同機部署的，API接口的會帶來額外的網絡消耗，以及增大qps。在此部署條件下，API_Server的實現(xiàn)方式可以通過HTTP調用或優(yōu)化為直接PHPRequire方式實現(xiàn)。上風：

　　(1)框架同一，接口收斂，業(yè)務解耦;

　　(2)機能晉升，易用性高，擴展性高;

　　六、UI拆分模型

　　此時獨立出來的子系統(tǒng)可以專注做其業(yè)務邏輯了，核心的系統(tǒng)也得到減負。但是核心系統(tǒng)的進級更新頻率是最高的，業(yè)務邏輯也最復雜。到了一定時期，核心系統(tǒng)又變得臃腫，難以維護。此時可以通過一些設計模式來降低程序的可擴展性和可維護性。但即便是如斯，仍是有一定的學習本錢，在一個App內部，開發(fā)同學或多或少需要關注其他模塊的代碼，逐漸發(fā)展為進級一點就需要排查良多點。這時候又到了進一步減負的時候。假如減負?分為兩部：

　　第一步：異步模型

　　頁面渲染分為兩個階段：主題頁面數(shù)據(jù)和其他非主題頁面數(shù)據(jù)。根據(jù)頁面的不同部門由不同的數(shù)據(jù)源提供數(shù)據(jù)。按此邏輯將app進一步做垂直拆分。

　　PHPService是由PHPmodule+一層很薄的UI，返回格局化數(shù)據(jù)。

　　第二步：同步模型

　　Module做拆分，不同業(yè)務邏輯拆分為不同的Module，區(qū)分為多個數(shù)據(jù)源，分別提供不同數(shù)據(jù)內容，由同一的UI調度不同的數(shù)據(jù)源后，同一進行渲染頁面返回響應。

　　如斯持續(xù)減負后，產品線內部的子系統(tǒng)和模塊將越來越多，需要維持部署和運維的同一。對團隊成員的分工很細，業(yè)務理解很專注和深入，合作、并行的效率也會更高，從而使整個開發(fā)周期縮短。

　　七、 小結

　　跟著業(yè)務邏輯的不端壯大，每個子系統(tǒng)或模塊的業(yè)務功能假如過于臃腫就需要不斷做減分，以保持在可控的規(guī)模內。如斯跟著產品的發(fā)展，產品線內部的子系統(tǒng)和模塊將越來越多，需要維持部署和運維的同一，保持簡樸。對團隊成員的分工更細，業(yè)務理解保持專注和深入，合作、并行的效率也會更高，從而使整個開發(fā)周期縮短。