在當(dāng)前這個互聯(lián)網(wǎng)業(yè)務(wù)飛速發(fā)展時期，新的產(chǎn)品如雨后春筍般涌出，老產(chǎn)品線新業(yè)務(wù)也在不斷突破和嘗試。這就對快速開發(fā)迭代提出了更高的要求。
一、基礎(chǔ)運行環(huán)境
針對新產(chǎn)品的開發(fā)，必須能夠快速搭建一套LAMP架構(gòu)。那么無外乎選擇一個webserver，選擇一個php版本，選擇一個mysql版本，再選擇一個PHP開發(fā)框架和選擇一些php通用擴展和基礎(chǔ)庫等。這個過程讀者可能覺得已經(jīng)很快了，能不能更快?
選擇的過程要求研發(fā)同學(xué)對相關(guān)技術(shù)方向有一定的積累，權(quán)衡利弊和優(yōu)先點，又是一番調(diào)研和學(xué)習(xí)。如果有一鍵安裝程序，提供自動化安裝webserver，php，mysql，以及攜帶高性能靈活的php開發(fā)框架，并提供標(biāo)準(zhǔn)化、安全、常用的配置文件，可以大大縮短產(chǎn)品線LAMP系統(tǒng)調(diào)研的成本，縮短工作周期。
一鍵安裝四步驟：(1)下載;(2)少量配置;(3)make install;(4)start;(當(dāng)然有end啦，簡單的運維工具)，運行環(huán)境OK。
二、業(yè)務(wù)開發(fā)框架
社區(qū)產(chǎn)品線各自為政，封閉得開發(fā)各自的業(yè)務(wù)邏輯。而事實上，各個產(chǎn)品線之間存在很多通用業(yè)務(wù)邏輯處理，如session驗證、權(quán)限判斷、參數(shù)驗證、日志打印等。不同產(chǎn)品線，所有請求都需要做這些處理，能不能不重復(fù)開發(fā)?無線業(yè)務(wù)開發(fā)和PC上的業(yè)務(wù)邏輯有很多的不同，但不同產(chǎn)品線之間也有很多通用性。能不能不重復(fù)開發(fā)?
產(chǎn)品線在內(nèi)部通常對這些通用邏輯的處理做了一定的抽象，設(shè)計為ActionChain的形式或者通過基類的方案?？蚣軐⒏鼜氐祝簩⑦@些所有請求都要處理的通用邏輯以業(yè)務(wù)邏輯框架的形式提供，研發(fā)同學(xué)只需要關(guān)注用戶請求專有的邏輯處理。
一個用戶請求的處理邏輯如下圖：藍(lán)色部分是控制器框架處理流程，綠色部分和控制器框架相結(jié)合，處理所有請求通用的業(yè)務(wù)邏輯。而真正需要研發(fā)同學(xué)關(guān)注和開發(fā)的該用戶請求專有的業(yè)務(wù)處理，即黃色部分(當(dāng)然一個不僅僅是一個Action腳本，一個請求的處理會橫向做mvc分層，這塊后續(xù)會有涉及。)
業(yè)務(wù)邏輯框架繼承在一鍵安裝程序中提供，簡簡單單就可以獲得。
原生的PHP業(yè)務(wù)和模板耦合很深，沒有做任何的分層設(shè)計，其結(jié)果是代碼的復(fù)用性差。這樣的原始的PHP系統(tǒng)現(xiàn)在已幾乎消亡。PHP開發(fā)框架統(tǒng)一處理路由、渲染、AutoLoad，通用業(yè)務(wù)邏輯的抽象和基礎(chǔ)庫的抽象，專有業(yè)務(wù)MVC分層，已大大加快了產(chǎn)品線業(yè)務(wù)邏輯的開發(fā)。如下圖所示：
從上而下，分別是接入層(高性能webserver)，PHP開發(fā)框架(路由、自動加載、視圖引擎等)，應(yīng)用和基礎(chǔ)庫，存儲引擎。
三、通用服務(wù)
社區(qū)產(chǎn)品線存在很多共同的需求，如日志處理、配置文件的處理、字符串處理、數(shù)據(jù)庫交互、網(wǎng)絡(luò)交互等。這些算法和工具封裝成phplib給產(chǎn)品線使用已比較成熟。
社區(qū)類產(chǎn)品線的業(yè)務(wù)功能存在很多的通用性，諸如評論功能、Tag功能、好友功能、圖冊、任務(wù)系統(tǒng)等，在眾多社區(qū)產(chǎn)品線都有類似的新功能新需求，各自設(shè)計開發(fā)?
這些需求在各產(chǎn)品線的UI上有個性化需求，但是后端實現(xiàn)方案大同小異，具有一定的通用性。功能服務(wù)化，提供API接口給不同產(chǎn)品線使用，產(chǎn)品線只需要關(guān)注展現(xiàn)邏輯和私有數(shù)據(jù)的處理邏輯即可，且服務(wù)統(tǒng)一運維，降低產(chǎn)品下的系統(tǒng)復(fù)雜度。
四、垂直拆分子系統(tǒng)
那么隨著我們業(yè)務(wù)的拓展，單個應(yīng)用內(nèi)部的ui和module的數(shù)量越來越多，Action和Logic(對應(yīng)MVC中的M層，內(nèi)部可以再進(jìn)一步做分層處理，此次不詳述)的交互，logic和logic之間的交互變得越來越復(fù)雜。開發(fā)同學(xué)需要了解整個應(yīng)用的邏輯，某個logic的升級，需要排查整個應(yīng)用下是否存在其他ui或logic的反向依賴。在快速開發(fā)的要求下，開發(fā)同學(xué)對logic之間的相互耦合關(guān)系的梳理不清楚，勢必引發(fā)越來越多的問題，影響項目質(zhì)量，難以開始開發(fā)。
單一系統(tǒng)的問題暴露越來越多，就到了系統(tǒng)拆分的時候了。如何拆?按業(yè)務(wù)邏輯垂直拆分。將功能獨立的業(yè)務(wù)邏輯剝離出來，做成獨立的子系統(tǒng)。這個時候還需要考慮業(yè)務(wù)的通用性，是否可以服務(wù)化?應(yīng)用已有相同需求的通用服務(wù)?此時通用業(yè)務(wù)邏輯封裝成通用服務(wù)或使用了通用服務(wù)，旁路的業(yè)務(wù)邏輯獨立成子系統(tǒng)，如此一來就將原先單一龐大的系統(tǒng)做了大量減負(fù)。完成此階段的重構(gòu)后，系統(tǒng)加入變成如下：
單一系統(tǒng)被拆分成多個APP(APP內(nèi)部仍然有橫向的MVC分層)，并復(fù)用大量的通用服務(wù)。如此一來研發(fā)團隊在人員分工并行開發(fā)上都得到了極大提高。
五、跨系統(tǒng)調(diào)用框架
然而真實的現(xiàn)狀，在拆分后的子系統(tǒng)之間并不能完全消除依賴。為了解決多個子系統(tǒng)之間數(shù)據(jù)依賴的關(guān)系，需要一套統(tǒng)一的解決方案：API框架。子系統(tǒng)成為獨立的應(yīng)用(APP)，APP之間存在相互的數(shù)據(jù)依賴，這些依賴以API的形式對外提供。如下圖：
當(dāng)APP1依賴APP2或APP3的數(shù)據(jù)后，APP2和APP3會將一部分?jǐn)?shù)據(jù)接口以API的形式提供，數(shù)據(jù)做統(tǒng)一的打包，通過標(biāo)準(zhǔn)規(guī)范的URL提供產(chǎn)品線內(nèi)部其他APP調(diào)用。這種形式非常類似于一個產(chǎn)品對外開放API(對第三方開放API，我們稱為openAPI，遵守統(tǒng)一的協(xié)議，并經(jīng)過必要的權(quán)限驗證)，而解決內(nèi)部子系統(tǒng)之間數(shù)據(jù)依賴的API接口可以進(jìn)一步簡化。
APP提供的API解決提供接口描述(輸入、輸出)，處理API的URL，Logic的轉(zhuǎn)發(fā)實現(xiàn)。API_LIB統(tǒng)一來管理所有的API接口，并提供統(tǒng)一的API_Server::call接口供調(diào)用。完全對上屏蔽內(nèi)部的轉(zhuǎn)發(fā)和實現(xiàn)細(xì)節(jié)。通常產(chǎn)品線內(nèi)部為了達(dá)到運維的簡化和統(tǒng)一，所有的子系統(tǒng)是同機部署的，API接口的會帶來額外的網(wǎng)絡(luò)消耗，以及增大qps。在此部署前提下，API_Server的實現(xiàn)方式可以通過HTTP調(diào)用或優(yōu)化為直接PHPRequire方式實現(xiàn)。優(yōu)勢：
(1)框架統(tǒng)一，接口收斂，業(yè)務(wù)解耦;
(2)性能提升，易用性高，擴展性高;
六、UI拆分模型
此時獨立出來的子系統(tǒng)可以專注做其業(yè)務(wù)邏輯了，核心的系統(tǒng)也得到減負(fù)。但是核心系統(tǒng)的升級更新頻率是最高的，業(yè)務(wù)邏輯也最復(fù)雜。到了一定時期，核心系統(tǒng)又變得臃腫，難以維護。此時可以通過一些設(shè)計模式來降低程序的可擴展性和可維護性。但即便是如此，還是有一定的學(xué)習(xí)成本，在一個App內(nèi)部，開發(fā)同學(xué)或多或少需要關(guān)注其他模塊的代碼，逐漸發(fā)展為升級一點就需要排查很多點。這時候又到了進(jìn)一步減負(fù)的時候。如果減負(fù)?分為兩部：
第一步：異步模型
頁面渲染分為兩個階段：主題頁面數(shù)據(jù)和其他非主題頁面數(shù)據(jù)。根據(jù)頁面的不同部分由不同的數(shù)據(jù)源提供數(shù)據(jù)。按此邏輯將app進(jìn)一步做垂直拆分。
PHPService是由PHPmodule+一層很薄的UI，返回格式化數(shù)據(jù)。
第二步：同步模型
Module做拆分，不同業(yè)務(wù)邏輯拆分為不同的Module，區(qū)分為多個數(shù)據(jù)源，分別提供不同數(shù)據(jù)內(nèi)容，由統(tǒng)一的UI調(diào)度不同的數(shù)據(jù)源后，統(tǒng)一進(jìn)行渲染頁面返回響應(yīng)。
如此持續(xù)減負(fù)后，產(chǎn)品線內(nèi)部的子系統(tǒng)和模塊將越來越多，需要維持部署和運維的統(tǒng)一。對團隊成員的分工很細(xì)，業(yè)務(wù)理解很專注和深入，合作、并行的效率也會更高，從而使整個開發(fā)周期縮短。
七、 小結(jié)
隨著業(yè)務(wù)邏輯的不端壯大，每個子系統(tǒng)或模塊的業(yè)務(wù)功能如果過于臃腫就需要不斷做減分，以保持在可控的規(guī)模內(nèi)。如此隨著產(chǎn)品的發(fā)展，產(chǎn)品線內(nèi)部的子系統(tǒng)和模塊將越來越多，需要維持部署和運維的統(tǒng)一，保持簡單。對團隊成員的分工更細(xì)，業(yè)務(wù)理解保持專注和深入，合作、并行的效率也會更高，從而使整個開發(fā)周期縮短。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
