幾年前做前后端分離項(xiàng)目的原因，是node剛剛橫空出世，業(yè)界開始考慮如何真正的用js去寫后端服務(wù)，于是就借鑒阿里中途島項(xiàng)目去嘗試，主要還是用到了node的密集io場景下的轉(zhuǎn)發(fā)。

[[205939]]

我們的新項(xiàng)目是采用前后端分離的方式進(jìn)行開發(fā)，這一點(diǎn)主要是基于產(chǎn)品特點(diǎn)考慮而來，產(chǎn)品本身會(huì)有很強(qiáng)的富客戶端的特點(diǎn)。

我們后端服務(wù)面向的客戶端包含：iOS，Android，iPad，H5，還有一些游戲場景。所以最好的方式就是后端提供通用的restapi進(jìn)行數(shù)據(jù)傳輸，而前端展示邏輯則交由不同客戶端自己實(shí)現(xiàn)。

前后端分離項(xiàng)目主要基于微服務(wù)架構(gòu)開發(fā)，既然是微服務(wù)，所以分布式系統(tǒng)所應(yīng)該面對(duì)的問題一個(gè)也漏不掉。

JAVA微服務(wù)開發(fā)場景下，SpringBoot可謂神器，我們基于SpringBoot開發(fā)了一個(gè)可以快速開發(fā)的腳手架，腳手架本身包含了常用及通用的基本功能，如auth驗(yàn)證，功能鑒權(quán)，Mysql，Mq，Redis及通用配置的依賴，這樣開發(fā)工程師在需要開發(fā)新功能時(shí)，直接從對(duì)應(yīng)的代碼庫拉下來，編譯之后便可跑起來一個(gè)hello world的restapi項(xiàng)目。剩下的工作就是圍繞業(yè)務(wù)邏輯去寫repository，service，controller代碼了。

通信

服務(wù)之間的通信主要可以通過HTTP，RPC方式，眾所周知RPC調(diào)用的效率要高HTTP好幾個(gè)等級(jí)，所以推薦使用RPC，但是綜合考慮系統(tǒng)性能及可用性，快速開發(fā)等因素，我們也大量使用HTTP進(jìn)行服務(wù)調(diào)用，同時(shí)我們也通過Golang對(duì)一些核心api，比如支付，交易類接口進(jìn)行了重寫，所以需要在系統(tǒng)效率及開發(fā)效率之間做好平衡。

接口規(guī)范

雖然是前后端分離項(xiàng)目，大部分是通過restapi方式給客戶端暴露數(shù)據(jù)，但是也不可避免在系統(tǒng)中會(huì)存在自己的view頁面，所以在api及controller命名上會(huì)建立：AuthApi，AuthController，約定大于配置，可以幫助我們后端對(duì)不同的請(qǐng)求做隔離和控制。

任務(wù)類系統(tǒng)

項(xiàng)目中不可避免存在大量的任務(wù)程序，主要需要做好數(shù)據(jù)備份，考慮分布式場景下的任務(wù)調(diào)度，資源分配問題，主要根據(jù)場景不同進(jìn)行開發(fā)。
我們采用Zk+定時(shí)任務(wù)自研的調(diào)度系統(tǒng)，也可以采用開源的Elastic-Job方案。

依賴梳理

這個(gè)是一個(gè)項(xiàng)目開發(fā)過程中最重要的一點(diǎn)，梳理好系統(tǒng)上下游所依賴的服務(wù)，同時(shí)梳理好服務(wù)之間的等級(jí)關(guān)系。

依賴關(guān)系主要分為兩部分：依賴別人，被別人依賴；

依賴別人的服務(wù)，包含其他系統(tǒng)API及底層的數(shù)據(jù)庫，Redis，MQ等服務(wù)，需要做好對(duì)方服務(wù)不可用的準(zhǔn)備，隨時(shí)做好降級(jí)，限流及開關(guān)功能，最好做成可配置，自動(dòng)化。
被別人依賴的服務(wù)做成高可用，冪等性，響應(yīng)數(shù)據(jù)的可讀性好等特點(diǎn)。

同時(shí)對(duì)服務(wù)依賴性梳理，哪些系統(tǒng)屬于強(qiáng)依賴，哪些屬于若依賴。

不同依賴的標(biāo)準(zhǔn)做好開關(guān)，降級(jí)，重試等功能，強(qiáng)依賴比如DB掛了，可以寫日志，寫到MQ。弱依賴可以做成柔性降級(jí)，比如寫日志到ES中，ES不可用，可以直接降級(jí)即可。

對(duì)于黃金等級(jí)服務(wù)，則一定保證服務(wù)高可用，可以做災(zāi)備，比如依賴集群，多個(gè)機(jī)房，也就是這個(gè)服務(wù)是不可降級(jí)的，必須準(zhǔn)備多套方案保證服務(wù)可用。

關(guān)于依賴降級(jí)可以使用Hystrix做。

用戶友好性

做好最壞的打算，如果后端服務(wù)全部不可用，前端轉(zhuǎn)發(fā)問題等，一定不要給用戶一個(gè)錯(cuò)誤頁面，一定建立多級(jí)緩存，有數(shù)據(jù)托底，無論如何保證頁面上有內(nèi)容的。

總結(jié)

綜上所述，做好工具，梳理好服務(wù)依賴，對(duì)服務(wù)做等級(jí)劃分，弱依賴可以通過降級(jí)，限流方式處理。強(qiáng)依賴則必須通過多種災(zāi)備手段保證高可用，不要給用戶感到恐慌的頁面，要有數(shù)據(jù)托底。