如何提升中臺(tái)的效率？

發(fā)布：2018-11-30 16:37:57 瀏覽：4723

我們?cè)倩氐綐I(yè)務(wù)層上來具體看一下如何提升研發(fā)效率。說到研發(fā)效率還真不僅僅就是如何寫代碼這么簡單，讀過《人月神話》一書的人都知道，要開發(fā)一個(gè)產(chǎn)品，并不是人越多越好，而是涉及人與人之間的信息傳遞成本，有時(shí)候人與人的溝通成本甚至大平寫代明的成本，多外，當(dāng)系統(tǒng)查復(fù)雜r以后，代仍應(yīng)該寫在哪里，也就品人數(shù)去理解這個(gè)原有的系統(tǒng)也變得很困難，有個(gè)冷笑話，評(píng)信個(gè)業(yè)務(wù)需求，先羅找各后真正寫代碼只需要1天時(shí)間。由此可見，大部分時(shí)間并設(shè)有真正化在實(shí)現(xiàn)業(yè)務(wù)需求一個(gè)系統(tǒng)的產(chǎn)品經(jīng)理花上2周評(píng)估時(shí)間，然后開發(fā)同學(xué)再用2周時(shí)間評(píng)估怎么實(shí)現(xiàn)，最上，這樣的研發(fā)效率肯定是不合理的。

所以要考慮如何解決人性化，人與人溝通的問題，這是解決業(yè)務(wù)研發(fā)效率的關(guān)鍵所在。

1.溝通效率問題

有合作必然就有溝通，提升溝通效率最好的辦法就是形成默契，要形成默契就要通過規(guī)范和約定等手段把大家圈在同個(gè)語言頻道上。

需求階段的溝通比較多，如統(tǒng)術(shù)語，需求結(jié)構(gòu)化表達(dá)，統(tǒng)業(yè)務(wù)身份。

(1)統(tǒng)一術(shù)語。這在一個(gè)公司非常重要，比如在某些公司，“PM"這個(gè)詞是指產(chǎn)品經(jīng)理，而在另外些公司是指項(xiàng)目經(jīng)理；還有諸如應(yīng)用，系統(tǒng)，模塊這些基本的稱謂，如果大家理解不一樣的話會(huì)很糟糕。

在公司中形成術(shù)語也有些技巧。比如給產(chǎn)品取一個(gè)好名字，名字既可成為術(shù)講也可以是很好的傳播符號(hào)，像滴滴的個(gè)服務(wù)框架叫DiSF(didiserviceframework，滴師傅)，這個(gè)名字有內(nèi)容、有含義很容易被記住。在公司中與人溝通也是一樣，如果很難一句話向別人說清楚某個(gè)產(chǎn)品或者項(xiàng)目，那么推廣起來就會(huì)比較費(fèi)勁，因此，把自己的產(chǎn)品，項(xiàng)目或任何需要向別人表達(dá)的事情術(shù)語化可以減少溝通的成個(gè)。

(2)結(jié)構(gòu)化表達(dá)需求?；ヂ?lián)網(wǎng)公同中都是需求驅(qū)動(dòng)產(chǎn)品和技術(shù)的，提出需求的人大多都是運(yùn)營和產(chǎn)品經(jīng)理而非技術(shù)人員，這就不可避免地存在不同崗位人員的溝通理解問題。需求的結(jié)構(gòu)化表達(dá)就是把需求用“系列的術(shù)語、圖標(biāo)、頁面等可以更好理解和呈現(xiàn)的方式(一般產(chǎn)出就是PRD)在同一個(gè)語境中表達(dá)出來，讓對(duì)方更好的理解。溝通需求的過程就是把不確定性確定下來的過程，需求越具體溝通越容易。把需求結(jié)構(gòu)化，和把系統(tǒng)中需要經(jīng)常改動(dòng)的邏輯配置化要達(dá)到的效果是樣的，最終產(chǎn)生的結(jié)果就是一個(gè)變更記錄。

(3)統(tǒng)業(yè)務(wù)身份。業(yè)務(wù)身份是管理一個(gè)業(yè)務(wù)在各個(gè)業(yè)務(wù)城中定義的業(yè)務(wù)規(guī)則索引，是一串平臺(tái)可識(shí)別的編碼，該編碼由構(gòu)成業(yè)務(wù)的要素經(jīng)過一定組合關(guān)系運(yùn)算生成，在平臺(tái)的運(yùn)行城中，各個(gè)業(yè)務(wù)域的系統(tǒng)根據(jù)輸人的參數(shù)條件，進(jìn)行業(yè)務(wù)身份判斷運(yùn)算，最終根據(jù)識(shí)別出的業(yè)務(wù)身份結(jié)果，執(zhí)行該業(yè)務(wù)在本系統(tǒng)定義的業(yè)務(wù)規(guī)則。要實(shí)現(xiàn)統(tǒng)一業(yè)務(wù)身份必須要解決:

系統(tǒng)之間同一項(xiàng)業(yè)務(wù)的聯(lián)通性問題，讓系統(tǒng)自動(dòng)呈現(xiàn)業(yè)務(wù)整體視圖；

業(yè)務(wù)條件沒有生命周期管理、系統(tǒng)長期維護(hù)困難的問題，要統(tǒng)一業(yè)條件識(shí)別；

業(yè)務(wù)上下線相互影響、回歸工作量大和效率較低的問題。這就要對(duì)業(yè)務(wù)邏輯進(jìn)行能力抽象，建立封閉性，從而隔離業(yè)務(wù)。要對(duì)業(yè)務(wù)身份進(jìn)行統(tǒng)一管理，需要實(shí)現(xiàn):

對(duì)業(yè)務(wù)身份標(biāo)識(shí)的統(tǒng)一注冊(cè)和管理，一般需要構(gòu)建一個(gè)運(yùn)營平臺(tái)；。有業(yè)務(wù)規(guī)則的配置界面；規(guī)則的執(zhí)行引擎。

所以統(tǒng)一業(yè)務(wù)身份需要人口的注冊(cè)管理、規(guī)則的配置與變更，以及規(guī)則的運(yùn)行域，缺一不可。

2.開發(fā)效率

如何高效地寫代碼是程序員永恒的話題。這涉及很多因素，如程序員對(duì)代碼語言本身的掌握程度(比如JDK8中引人閉包代碼可以使代碼更簡潔)，寫代碼所用的IDE以及快捷鍵的使用程度，等等。筆者在這里先拋開這些問題，闡述下從開發(fā)到測(cè)試再到運(yùn)維的整個(gè)效率問題。

開發(fā)，人員都不希望別人亂碰自己寫的代碼，對(duì)代碼有絕對(duì)的控制權(quán)，所以一般都喜歡掌控(Owner)系統(tǒng)，即這個(gè)系統(tǒng)我說了算。在這種情況下，曾有一段時(shí)間我們把系統(tǒng)拆得很小，結(jié)果誕生了很多同質(zhì)的系統(tǒng)，越來越多地在做重復(fù)的事情；此后又經(jīng)歷了系統(tǒng)合并的階段。但是，系統(tǒng)合并也會(huì)帶來新問題，即開放過程中沖突比較厲害，包括打包部署的效率都很低，在這種情況下會(huì)有兩種解決方案:一是開發(fā)態(tài)和運(yùn)行態(tài)分離；二是對(duì)系統(tǒng)進(jìn)行分層和抽象建模。

所謂開發(fā)態(tài)和運(yùn)行態(tài)分離，就是大家線下的開發(fā)都是獨(dú)立進(jìn)行的，包括打包和部署，接口的調(diào)用分開，走遠(yuǎn)程調(diào)用。但是在線上部署時(shí)，都是部署在同一個(gè)容器中，把遠(yuǎn)程調(diào)用變成本地調(diào)用。這種思路我們?cè)凇昂喜⒉渴稹币徽轮杏薪榻B，本質(zhì)上可以做到開發(fā)態(tài)和運(yùn)行態(tài)的分離，同時(shí)兼顧開發(fā)效率和運(yùn)行效率。

3.測(cè)試效率

整個(gè)軟件生命周期涉及很多環(huán)節(jié):需求、開發(fā)、測(cè)試、上線、運(yùn)維…涉及很多協(xié)作。這些環(huán)節(jié)都會(huì)對(duì)效果有影響。其中，測(cè)試效率非常重要，因?yàn)闇y(cè)試花費(fèi)的時(shí)間幾乎和開發(fā)所花的時(shí)間是一樣的。關(guān)于如何提升測(cè)試效率，我們總結(jié)了一些實(shí)踐經(jīng)驗(yàn)，分述如下。

(1)全鏈路Beta測(cè)試

繼續(xù)保持Beta環(huán)境與線上環(huán)境的一致性，將核心鏈路上的應(yīng)用，Beta環(huán)境HSF打通，減少90%由于環(huán)境問題導(dǎo)致的P1、P2故障。

打通之后，可以實(shí)現(xiàn)以下效果

測(cè)試環(huán)境可以做到召之即來，揮之即去；

在分批發(fā)布前，可以在極短的時(shí)間內(nèi)有針對(duì)性地驗(yàn)證核心功能；也可以選擇性地屏蔽Cache的訪問；數(shù)據(jù)軌跡可以實(shí)時(shí)透出。

4.運(yùn)維效率

運(yùn)維包括線上和線下兩部分，運(yùn)維效率會(huì)在兩個(gè)環(huán)節(jié)表現(xiàn)得最明顯，一個(gè)是線下的打包編譯步驟、代碼分發(fā)步驟；一個(gè)是線上的下線一重啟一上線步驟、發(fā)布檢查步驟和回滾步驟。下面我們分別看看在這些環(huán)節(jié)有哪些地方可以優(yōu)化。

1)打包編譯環(huán)節(jié)

優(yōu)化流程。環(huán)境分配，可以預(yù)先分配好代碼copy，要主動(dòng)準(zhǔn)備而不用每次編譯代碼時(shí)再做環(huán)境方面的準(zhǔn)備工作；

預(yù)處理。監(jiān)控代碼版本修改，當(dāng)代碼被修改后，自動(dòng)觸發(fā)代碼合并沖突檢查做代碼編譯和打包操作，不要等到用戶點(diǎn)擊再觸發(fā)；每個(gè)分支代碼更新主動(dòng)和主干做Merge，發(fā)現(xiàn)有沖突要主動(dòng)通知相應(yīng)開發(fā)人員修改，不要等到打包部署時(shí)再臨時(shí)修改；

代碼編譯優(yōu)化。規(guī)則檢查，業(yè)務(wù)依賴的包要做依賴規(guī)范化管理，通過工具識(shí)別依賴；減少應(yīng)用依賴SNAPSHOT版本Jar，可以節(jié)省Maven編譯時(shí)間；Maven打包優(yōu)化，優(yōu)化Maven配置減少不必要的消耗；

增量編譯。減少編譯時(shí)間的辦法之一就是只編譯變化的部分；比較代碼修改時(shí)間和編譯的代碼更新時(shí)間可以區(qū)分那些修改的類，并針對(duì)它們做增量編譯，大大減少編譯時(shí)間。

打包機(jī)器硬件升級(jí)。提升編譯速度的另一個(gè)辦法是升級(jí)機(jī)器硬件，使用更多的CPU或者更多的內(nèi)存可以明顯提升編譯速度；多組機(jī)器standby以處理并發(fā)修改情況，并始終保持應(yīng)用處于可用狀態(tài)，減少開發(fā)上廁所的次數(shù)。

(2)代碼分發(fā)步驟

代碼分發(fā)主要考慮兩個(gè)問題，一個(gè)是代碼的下載，最好是支持P2P下載，這樣的下載效率最高(雖然大部分情況是HTTP下載較多，但真心不建議采用)；二是如果代碼包比較大且同時(shí)下載的機(jī)器比較多時(shí)，要考慮下載機(jī)器的網(wǎng)卡流量是否滿足，這點(diǎn)必須特別留意。

(3)下線、重啟、上線步驟

下線環(huán)節(jié)。下線被動(dòng)等待15秒健康檢查失敗，能否主動(dòng)通知LVS下線，而不是被動(dòng)等待3次3秒的檢查失敗后再下線；

重啟。初始化各種服務(wù)，去掉不必要的服務(wù)初始化，將一些服務(wù)改成慢加載，部分服務(wù)可以并行初始化。

(4)回滾

回滾等于重新發(fā)布，直接利用本機(jī)的老war包快速重啟，不需要再走包分發(fā)網(wǎng)站建設(shè)步驟，要有手動(dòng)回滾腳本。如果回滾時(shí)間長則減少回滾批次，采用發(fā)布一批機(jī)器就下線一批機(jī)器的方式:下線的機(jī)器保持standby，老代碼不提供服務(wù)，出現(xiàn)問題后再立即下線新發(fā)布的機(jī)器，將standby的機(jī)器立即上線。這樣可以快速達(dá)到回滾的目的，在30秒內(nèi)就能完成回滾。