摘要：，大家好，很榮幸有這個(gè)機(jī)會(huì)可以通過(guò)寫博文的方式，把這些年在后端開發(fā)過(guò)程中總結(jié)沉淀下來(lái)的經(jīng)驗(yàn)和設(shè)計(jì)思路分享出來(lái)模塊化設(shè)計(jì)根據(jù)業(yè)務(wù)場(chǎng)景，將業(yè)務(wù)抽離成獨(dú)立模塊，對(duì)外通過(guò)接口提供服務(wù)，減少系統(tǒng)復(fù)雜度和耦合度，實(shí)現(xiàn)可復(fù)用，易維護(hù)，易拓展項(xiàng)目中實(shí)踐例子

Hi，大家好，很榮幸有這個(gè)機(jī)會(huì)可以通過(guò)寫博文的方式，把這些年在后端開發(fā)過(guò)程中總結(jié)沉淀下來(lái)的經(jīng)驗(yàn)和設(shè)計(jì)思路分享出來(lái)

根據(jù)業(yè)務(wù)場(chǎng)景，將業(yè)務(wù)抽離成獨(dú)立模塊，對(duì)外通過(guò)接口提供服務(wù)，減少系統(tǒng)復(fù)雜度和耦合度，實(shí)現(xiàn)可復(fù)用，易維護(hù)，易拓展

項(xiàng)目中實(shí)踐例子：

Before：

在返還購(gòu)APP里有個(gè)【我的紅包】的功能，用戶的紅包數(shù)據(jù)來(lái)自多個(gè)業(yè)務(wù)，如：邀請(qǐng)新用戶注冊(cè)領(lǐng)取100元紅包，大促活動(dòng)雙倍紅包，等各種活動(dòng)紅包，多個(gè)活動(dòng)業(yè)務(wù)都實(shí)現(xiàn)了一套不同規(guī)則的紅包領(lǐng)取和紅包獎(jiǎng)勵(lì)發(fā)放的機(jī)制，導(dǎo)致紅包不可管理，不能復(fù)用，難維護(hù)難拓展

After：

重構(gòu)紅包業(yè)務(wù)

紅包可后臺(tái)管理

紅包信息管理，可添加，可編輯，可配置紅包使用的規(guī)則，可管理用戶紅包

紅包獎(jiǎng)勵(lì)發(fā)放統(tǒng)一處理

應(yīng)用業(yè)務(wù)的接入只需要專注給用戶進(jìn)行紅包發(fā)放即可

設(shè)計(jì)概要

Before VS After

產(chǎn)品有時(shí)提出的業(yè)務(wù)需求沒有往這方面去考慮，結(jié)合場(chǎng)景和未來(lái)拓展需要，在需求討論的時(shí)候提出模塊化設(shè)計(jì)方案，并可以協(xié)助產(chǎn)品進(jìn)行設(shè)計(jì)

在項(xiàng)目開發(fā)中經(jīng)常會(huì)遇到些類似的功能，但是不同的開發(fā)人員都各自實(shí)現(xiàn)，或者因?yàn)椴荒軓?fù)用又重新開發(fā)一個(gè)，導(dǎo)致了類似功能的重復(fù)開發(fā)，所以我們需要對(duì)能夠抽離獨(dú)立服務(wù)的功能進(jìn)行抽離，達(dá)到復(fù)用的效果，并且可以不斷拓展完善，節(jié)約了后續(xù)開發(fā)成本，提高開發(fā)效率，易于維護(hù)和拓展

項(xiàng)目中實(shí)踐例子：

Before

在業(yè)務(wù)中經(jīng)常需要對(duì)用戶進(jìn)行信息通知，如：短信定時(shí)通知，APP消息推送，微信通知，等

開發(fā)人員在接到需求中有通知功能的時(shí)候沒有考慮后續(xù)拓展，就接入第三方信息通知平臺(tái)，然后簡(jiǎn)單封裝個(gè)信息通知方法，后續(xù)也有類似信息通知需求的時(shí)候，另一個(gè)開發(fā)人員發(fā)現(xiàn)當(dāng)前這個(gè)通知方法無(wú)法滿足自己的需求，然后又自己去了解第三方平臺(tái)重新封裝了通知方法，或者后續(xù)需求加了定時(shí)通知的功能，開發(fā)人員針對(duì)業(yè)務(wù)去實(shí)現(xiàn)了個(gè)定時(shí)通知功能，但是只能自己業(yè)務(wù)上使用，其他業(yè)務(wù)無(wú)法接入，沒有人去做這塊功能的抽離，久而久之就演變成功能重復(fù)開發(fā)，且不易于維護(hù)和拓展

After

接觸到這種可以抽離通用服務(wù)需求的時(shí)候，就會(huì)與產(chǎn)品確認(rèn)這種需求是否后續(xù)會(huì)存在類似的需要，然后建議這把塊需求抽離成通用服務(wù)，方便后續(xù)維護(hù)和拓展

設(shè)計(jì)概要

Before VS After

項(xiàng)目開發(fā)過(guò)程中有些需求是與所在項(xiàng)目業(yè)務(wù)無(wú)關(guān)，如：收集用戶行為習(xí)慣，收集商品曝光點(diǎn)擊，數(shù)據(jù)收集提供給BI進(jìn)行統(tǒng)計(jì)報(bào)表輸出，公用拉新促活業(yè)務(wù)（柚子街和返還公用），類似這種需求，我們結(jié)合應(yīng)用場(chǎng)景，考慮服務(wù)的獨(dú)立性，以及未來(lái)的拓展需要，架構(gòu)獨(dú)立項(xiàng)目進(jìn)行維護(hù)，在服務(wù)器上獨(dú)立分布式部署不影響現(xiàn)有主業(yè)務(wù)服務(wù)器資源

項(xiàng)目中實(shí)踐例子：

架構(gòu)用戶行為跟蹤獨(dú)立服務(wù)，在開發(fā)前預(yù)估了下這個(gè)服務(wù)的請(qǐng)求量，并會(huì)有相對(duì)大量的并發(fā)請(qǐng)求

架構(gòu)方案：

項(xiàng)目搭建選擇用nodejs來(lái)做服務(wù)端

單進(jìn)程，基于事件驅(qū)動(dòng)和無(wú)阻塞I/O，所以非常適合處理并發(fā)請(qǐng)求

負(fù)載均衡：cluster模塊/PM2

架構(gòu)nodejs獨(dú)立服務(wù)

提供服務(wù)接口給客戶端

接口不直接DB操作，保證并發(fā)下的穩(wěn)定性

數(shù)據(jù)異步入庫(kù)

通過(guò)程序把數(shù)據(jù)從：消息隊(duì)列=>mysql

nodejs+express+redis(list)/mq+mysql

用戶行為跟蹤服務(wù)的服務(wù)架構(gòu)圖

高并發(fā)除了需要對(duì)服務(wù)器進(jìn)行垂直擴(kuò)展和水平擴(kuò)展之外，作為后端開發(fā)可以通過(guò)高并發(fā)優(yōu)化，保證業(yè)務(wù)在高并發(fā)的時(shí)候能夠穩(wěn)定的運(yùn)行，避免業(yè)務(wù)停滯帶來(lái)的損失，給用戶帶來(lái)不好的體驗(yàn)

服務(wù)端緩存

內(nèi)存數(shù)據(jù)庫(kù)

* redis
* memcache

方式

* 優(yōu)先緩存
    * 穿透DB問題  
* 只讀緩存 
    * 更新/失效刪除

注意

* 內(nèi)存數(shù)據(jù)庫(kù)的分配的內(nèi)存容量有限，合理規(guī)劃使用，濫用最終會(huì)導(dǎo)致內(nèi)存空間不足
* 緩存數(shù)據(jù)需要設(shè)置過(guò)期時(shí)間，無(wú)效/不使用的數(shù)據(jù)自動(dòng)過(guò)期
* 壓縮數(shù)據(jù)緩存數(shù)據(jù)，不使用字段不添加到緩存中
* 根據(jù)業(yè)務(wù)拆分布式部署緩存服務(wù)器

客戶端緩存

方式

* 客戶端請(qǐng)求數(shù)據(jù)接口，緩存數(shù)據(jù)和數(shù)據(jù)版本號(hào)，并且每次請(qǐng)求帶上緩存的數(shù)據(jù)版本號(hào)
* 服務(wù)端根據(jù)上報(bào)的數(shù)據(jù)版本號(hào)與數(shù)據(jù)當(dāng)前版本號(hào)對(duì)比
* 版本號(hào)一樣不返回?cái)?shù)據(jù)列表，版本號(hào)不一樣返回最新數(shù)據(jù)和最新版本號(hào) 

場(chǎng)景：

* 更新頻率不高的數(shù)據(jù)

服務(wù)端緩存架構(gòu)圖

異步編程

方式：

多線程編程

nodejs異步編程

場(chǎng)景：

參與活動(dòng)成功后進(jìn)行短信通知

非主業(yè)務(wù)邏輯流程需要的操作，允許異步處理其他輔助業(yè)務(wù)，等

業(yè)務(wù)異步處理

方式

業(yè)務(wù)接口將客戶端上報(bào)的數(shù)據(jù)PUSH到消息隊(duì)列（MQ中間件），然后就響應(yīng)結(jié)果給用戶

編寫?yīng)毩⒊绦蛉ビ嗛喯㈥?duì)列，異步處理業(yè)務(wù)

場(chǎng)景：

大促活動(dòng)整點(diǎn)搶限量紅包

參與成功后委婉提示：預(yù)計(jì)X天后進(jìn)行紅包發(fā)放

并發(fā)量比較大的業(yè)務(wù)，且沒有其他更好的優(yōu)化方案，業(yè)務(wù)允許異步處理

注意：

把控隊(duì)列消耗的進(jìn)度

保證冪等性和數(shù)據(jù)最終一致性

缺陷：

犧牲用戶體驗(yàn)

【業(yè)務(wù)異步處理】架構(gòu)圖

【業(yè)務(wù)異步處理】除了可以在高并發(fā)業(yè)務(wù)中使用，在上面通用服務(wù)的設(shè)計(jì)里也是用這種架構(gòu)方式

在類秒殺的活動(dòng)中通過(guò)限制請(qǐng)求量，可以避免超賣，超領(lǐng)等問題
高并發(fā)的活動(dòng)業(yè)務(wù)，通過(guò)前端控流，分散請(qǐng)求，減少并發(fā)量

服務(wù)端限流

redis 計(jì)數(shù)器

如：類秒殺活動(dòng)

客戶端控流

通過(guò)參與活動(dòng)游戲的方式

紅包雨/小游戲，等方式

當(dāng)服務(wù)器資源消耗已經(jīng)達(dá)到一定的級(jí)別的時(shí)候，為了保證核心業(yè)務(wù)正常運(yùn)行，需要丟卒保車，棄車保帥，服務(wù)降級(jí)是最后的手段，避免服務(wù)器宕機(jī)導(dǎo)致業(yè)務(wù)停滯帶來(lái)的損失，以及給用戶帶來(lái)不好的體驗(yàn)

業(yè)務(wù)降級(jí)

從復(fù)雜服務(wù)，變成簡(jiǎn)單服務(wù)

從動(dòng)態(tài)交互，變成靜態(tài)頁(yè)面

分流到CDN

從CDN拉取提前備好的JSON數(shù)據(jù)

引導(dǎo)到CDN靜態(tài)頁(yè)面

停止服務(wù)

停止非核心業(yè)務(wù)，并進(jìn)行委婉提示

高并發(fā)優(yōu)化概要圖

大多數(shù)公司的產(chǎn)品設(shè)計(jì)和程序猿對(duì)于推廣活動(dòng)業(yè)務(wù)的防刷意識(shí)不強(qiáng)，在活動(dòng)業(yè)務(wù)設(shè)計(jì)和開發(fā)的過(guò)程中沒有把防刷的功能加入業(yè)務(wù)中，給那些喜歡刷活動(dòng)的人創(chuàng)造了很多的空子
等到你發(fā)現(xiàn)自己被刷的時(shí)候，已經(jīng)產(chǎn)生了不小的損失，少則幾百幾千，多則幾萬(wàn)

隨著利益的誘惑，現(xiàn)在已經(jīng)浮現(xiàn)了一個(gè)新的職業(yè)“刷客”，專業(yè)刷互聯(lián)網(wǎng)活動(dòng)為生，養(yǎng)了N臺(tái)手機(jī)+N個(gè)手機(jī)號(hào)碼+N個(gè)微信賬號(hào)，刷到的獎(jiǎng)勵(lì)金進(jìn)行提現(xiàn)，刷到活動(dòng)商品進(jìn)行低價(jià)轉(zhuǎn)手處理，開辟了一條新的灰色產(chǎn)業(yè)鏈

我們要拿起武器(代碼)進(jìn)行自我的防御，風(fēng)控，加高門檻，通過(guò)校驗(yàn)和限制減少風(fēng)險(xiǎn)發(fā)生的各種可能性，減少風(fēng)險(xiǎn)發(fā)生時(shí)造成的損失

這里列出常用套路（具體應(yīng)用結(jié)合業(yè)務(wù)場(chǎng)景）：

校驗(yàn)請(qǐng)求合法性

請(qǐng)求參數(shù)合法性判斷

請(qǐng)求頭校驗(yàn)

user-agent

referer

... ...

簽名校驗(yàn)

對(duì)請(qǐng)求參數(shù)進(jìn)行簽名

設(shè)備限制

IP限制

微信unionid/openid合法性判斷

驗(yàn)證碼/手機(jī)短信驗(yàn)證碼

犧牲體驗(yàn)

自建黑名單系統(tǒng)過(guò)濾

業(yè)務(wù)風(fēng)控

限制設(shè)備/微信參與次數(shù)

限制最多獎(jiǎng)勵(lì)次數(shù)

獎(jiǎng)池限制

根據(jù)具體業(yè)務(wù)場(chǎng)景設(shè)計(jì)... ...

應(yīng)對(duì)角色

普通用戶

技術(shù)用戶

專業(yè)刷客

目前還沒有很好的限制方式

防刷/防羊毛黨套路概要圖

附加

APP/H5中簽名規(guī)則應(yīng)該由客戶端童鞋開發(fā)，然后拓展API給前端JS調(diào)用，在H5發(fā)起接口請(qǐng)求的時(shí)候調(diào)用客戶端拓展的簽名，這樣可以避免前端JS里構(gòu)造簽名規(guī)則而被發(fā)現(xiàn)破解

多操作

場(chǎng)景：

當(dāng)==同用戶==多次觸發(fā)點(diǎn)擊，或者通過(guò)模擬并發(fā)請(qǐng)求，就會(huì)出現(xiàn)多操作的問題，比如：簽到功能，一天只能簽到一次，可以獲得1積分，但是并發(fā)的情況下會(huì)出現(xiàn)用戶可以獲得多積分的問題

剖析：

簡(jiǎn)化簽到邏輯一般是這樣的：

查詢是否有簽到記錄 --> 否 --> 添加今日簽到記錄 --> 累加用戶積分 --> 簽到成功
查詢是否有簽到記錄 --> 是 --> 今日已經(jīng)簽到過(guò)

假設(shè)這個(gè)時(shí)候用戶A并發(fā)兩個(gè)簽到請(qǐng)求，這時(shí)會(huì)同時(shí)進(jìn)入到 【查詢是否有簽到記錄】，然后同時(shí)返回否，就會(huì)添加兩條的簽到記錄，并且多累加積分

解決方案：

最理想簡(jiǎn)單的方案，只需要在簽到記錄表添加【簽到日期】+【用戶ID】的組合唯一索引，當(dāng)并發(fā)的時(shí)候只有會(huì)一條可以添加成功，其他添加操作會(huì)因?yàn)槲ㄒ患s束而失敗

庫(kù)存負(fù)數(shù)

場(chǎng)景：

當(dāng)==多用戶==并發(fā)點(diǎn)擊參與活動(dòng)，如：抽獎(jiǎng)活動(dòng)，這個(gè)時(shí)候獎(jiǎng)品只有一個(gè)庫(kù)存了，理論上只有一個(gè)用戶可以獲得，但是并發(fā)的時(shí)候往往會(huì)出現(xiàn)他們都成功獲得獎(jiǎng)品，導(dǎo)致獎(jiǎng)品多支出，加大了活動(dòng)成本

剖析：

有問題的邏輯流程一般是這樣的：

中獎(jiǎng) --> 查詢獎(jiǎng)品庫(kù)存 --> 有 --> 更新獎(jiǎng)品庫(kù)存 --> 添加中獎(jiǎng)紀(jì)錄 --> 告知中獎(jiǎng)
中獎(jiǎng) --> 查詢獎(jiǎng)品庫(kù)存 --> 無(wú) --> 告知無(wú)中獎(jiǎng)

假設(shè)抽獎(jiǎng)活動(dòng)，當(dāng)前獎(jiǎng)品A只有最后一個(gè)庫(kù)存，然后用戶A、B、C，同時(shí)參與活動(dòng)同時(shí)中獎(jiǎng)獎(jiǎng)品都是A，這個(gè)時(shí)候查詢商品庫(kù)存是存在1個(gè)，就會(huì)進(jìn)行更新庫(kù)存，添加中獎(jiǎng)紀(jì)錄，然后就同時(shí)中獎(jiǎng)了

解決方案：

最理想根本就不需要用多做一個(gè)庫(kù)存的SELECT獎(jiǎng)品庫(kù)存操作，只需要UPDATE 獎(jiǎng)品庫(kù)存-1 WHERE 獎(jiǎng)品庫(kù)存>=1，UPDATE成功后就說(shuō)明是有庫(kù)存的，然后再做后續(xù)操作，并發(fā)的時(shí)候只會(huì)有一個(gè)用戶UPDATE成功

總結(jié)：

在開發(fā)業(yè)務(wù)接口的時(shí)候需要把==同用戶==和==多用戶==并發(fā)的場(chǎng)景考慮進(jìn)去，這樣就可以避免在并發(fā)的時(shí)候產(chǎn)生數(shù)據(jù)異常問題，導(dǎo)致成本多支出
可以使用下面的工具進(jìn)行模擬并發(fā)測(cè)試：

Apache JMeter

Charles Advanced Repeat

Visual Studio 性能負(fù)載

普遍方案

獲取平臺(tái)數(shù)據(jù)接口

模擬接口請(qǐng)求

數(shù)據(jù)解析過(guò)濾

數(shù)據(jù)構(gòu)造入庫(kù)

使用selenium+Headless自動(dòng)化測(cè)試框架

開發(fā)

推薦用python開發(fā)

python+selenium+headless

控制請(qǐng)求頻率，避免被平臺(tái)限制請(qǐng)求

使用代理IP，繞過(guò)請(qǐng)求IP限制

優(yōu)點(diǎn)

無(wú)需模擬接口請(qǐng)求

無(wú)法攻克數(shù)據(jù)接口模擬請(qǐng)求(加密簽名等)

接口版本頻繁變化(需要重新調(diào)研)

平臺(tái)接口/頁(yè)面版本變化，可以快速調(diào)整

只需要調(diào)整采集數(shù)據(jù)所在的HTML元素的位置(class/id)

可以用戶操作/選中/點(diǎn)擊/模擬登陸，等

登陸失效后可以模擬登陸

可以發(fā)送登陸二維碼到釘釘進(jìn)行掃碼登錄

應(yīng)用場(chǎng)景：

競(jìng)品數(shù)據(jù)采集

淘寶商品價(jià)格和自建商品庫(kù)后臺(tái)價(jià)格監(jiān)控

淘寶領(lǐng)券金額和自建商品庫(kù)后臺(tái)券金額監(jiān)控

... ...

反反爬蟲

在做數(shù)據(jù)采集的過(guò)程中，有些平臺(tái)會(huì)對(duì)重要數(shù)據(jù)的請(qǐng)求設(shè)置反爬蟲策略，避免數(shù)據(jù)被競(jìng)品挖掘和利用，以及消耗大量資源拖垮服務(wù)器，
反爬蟲和反反爬蟲是技術(shù)之間的較量，這場(chǎng)沒有硝煙的戰(zhàn)爭(zhēng)永不停息。（程序員何必為難程序員）

反爬蟲可以分為以下兩種

服務(wù)端限制

* 服務(wù)器端行請(qǐng)求限制，防止爬蟲進(jìn)行數(shù)據(jù)請(qǐng)求 

前端限制

* 前端通過(guò)CSS和HTML標(biāo)簽進(jìn)行干擾混淆關(guān)鍵數(shù)據(jù)，防止爬蟲輕易獲取數(shù)據(jù)

破解服務(wù)端限制：

模擬設(shè)置請(qǐng)求頭

* Referer
* User-Agent
* Authorization
* .....

破解簽名

* 簽名規(guī)則
    * 在JS中找到簽名規(guī)則

控制請(qǐng)求平率

* 調(diào)整請(qǐng)求時(shí)間，延遲請(qǐng)求

代理IP

* 切換請(qǐng)求的代理IP，自建/第三方

登錄限制

* 帶上登錄成功后的Cookie/Authorization

驗(yàn)證碼限制

* 識(shí)圖，基于庫(kù)/第三方

投毒破解

* 為了防止被投毒，需要對(duì)數(shù)據(jù)進(jìn)行抽樣校驗(yàn)

破解前端限制：

font-face，自定義字體干擾

* 找到ttf字體文件地址，然后下載下來(lái)，使用font解析模塊包對(duì)ttf文件進(jìn)行解析，與文字編碼進(jìn)行映射出中文

偽元素隱藏式

* 在CSS里找到xxxx::before {content: "中文";}對(duì)應(yīng)的中文

backgroud-image移量

* 通過(guò)背景圖片的position位置偏移量和圖片中的內(nèi)容進(jìn)行映射

html標(biāo)簽干擾

* 過(guò)濾掉干擾混淆的HTML標(biāo)簽，或者只讀取有效數(shù)據(jù)的HTML標(biāo)簽的內(nèi)容 

作為后端開發(fā)者，不僅是完成需求功能開發(fā)，要結(jié)合業(yè)務(wù)場(chǎng)景進(jìn)行合理設(shè)計(jì)，架構(gòu)未來(lái)，對(duì)核心業(yè)務(wù)進(jìn)行壓測(cè)優(yōu)化，以保證業(yè)務(wù)在并發(fā)下能夠正常運(yùn)行，同時(shí)要考慮安全問題以及防刷，防羊毛黨，在編碼上避免壞代碼味道，面相抽象開發(fā)，適當(dāng)使用設(shè)計(jì)模式，避免技術(shù)債

開發(fā)應(yīng)該銘記于心的精句：

技術(shù)的存在價(jià)值，是讓技術(shù)推動(dòng)業(yè)務(wù)增長(zhǎng)，實(shí)現(xiàn)公司盈利增長(zhǎng)

沒有最好的架構(gòu)只有最適合的架構(gòu)

開發(fā)語(yǔ)言只是工具，在適合的場(chǎng)景中使用適合的工具

抽象思維是從具體存在的各不相同的問題當(dāng)中洞察問題的本質(zhì)，理解產(chǎn)品需求的深層次模型，治本而不是治標(biāo)

知識(shí)很重要，她雖然不能直接給你財(cái)富，但是可以給你很多機(jī)會(huì)，活到老學(xué)到老

首發(fā)于SFLYQ博客