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

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

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

項目中實踐例子：

Before：

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

After：

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

紅包可后臺管理

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

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

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

設(shè)計概要

Before VS After

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

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

項目中實踐例子：

Before

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

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

After

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

設(shè)計概要

Before VS After

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

項目中實踐例子：

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

架構(gòu)方案：

項目搭建選擇用nodejs來做服務(wù)端

單進程，基于事件驅(qū)動和無阻塞I/O，所以非常適合處理并發(fā)請求

負載均衡：cluster模塊/PM2

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

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

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

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

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

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

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

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

服務(wù)端緩存

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

* redis
* memcache

方式

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

注意

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

客戶端緩存

方式

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

場景：

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

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

異步編程

方式：

多線程編程

nodejs異步編程

場景：

參與活動成功后進行短信通知

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

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

方式

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

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

場景：

大促活動整點搶限量紅包

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

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

注意：

把控隊列消耗的進度

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

缺陷：

犧牲用戶體驗

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

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

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

服務(wù)端限流

redis 計數(shù)器

如：類秒殺活動

客戶端控流

通過參與活動游戲的方式

紅包雨/小游戲，等方式

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

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

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

從動態(tài)交互，變成靜態(tài)頁面

分流到CDN

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

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

停止服務(wù)

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

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

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

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

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

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

校驗請求合法性

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

請求頭校驗

user-agent

referer

... ...

簽名校驗

對請求參數(shù)進行簽名

設(shè)備限制

IP限制

微信unionid/openid合法性判斷

驗證碼/手機短信驗證碼

犧牲體驗

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

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

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

限制最多獎勵次數(shù)

獎池限制

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

應(yīng)對角色

普通用戶

技術(shù)用戶

專業(yè)刷客

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

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

附加

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

多操作

場景：

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

剖析：

簡化簽到邏輯一般是這樣的：

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

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

解決方案：

最理想簡單的方案，只需要在簽到記錄表添加【簽到日期】+【用戶ID】的組合唯一索引，當(dāng)并發(fā)的時候只有會一條可以添加成功，其他添加操作會因為唯一約束而失敗

庫存負數(shù)

場景：

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

剖析：

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

中獎 --> 查詢獎品庫存 --> 有 --> 更新獎品庫存 --> 添加中獎紀錄 --> 告知中獎
中獎 --> 查詢獎品庫存 --> 無 --> 告知無中獎

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

解決方案：

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

總結(jié)：

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

Apache JMeter

Charles Advanced Repeat

Visual Studio 性能負載

普遍方案

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

模擬接口請求

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

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

使用selenium+Headless自動化測試框架

開發(fā)

推薦用python開發(fā)

python+selenium+headless

控制請求頻率，避免被平臺限制請求

使用代理IP，繞過請求IP限制

優(yōu)點

無需模擬接口請求

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

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

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

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

可以用戶操作/選中/點擊/模擬登陸，等

登陸失效后可以模擬登陸

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

應(yīng)用場景：

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

淘寶商品價格和自建商品庫后臺價格監(jiān)控

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

... ...

反反爬蟲

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

反爬蟲可以分為以下兩種

服務(wù)端限制

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

前端限制

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

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

模擬設(shè)置請求頭

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

破解簽名

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

控制請求平率

* 調(diào)整請求時間，延遲請求

代理IP

* 切換請求的代理IP，自建/第三方

登錄限制

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

驗證碼限制

* 識圖，基于庫/第三方

投毒破解

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

破解前端限制：

font-face，自定義字體干擾

* 找到ttf字體文件地址，然后下載下來，使用font解析模塊包對ttf文件進行解析，與文字編碼進行映射出中文

偽元素隱藏式

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

backgroud-image移量

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

html標(biāo)簽干擾

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

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

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

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

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

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

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

知識很重要，她雖然不能直接給你財富，但是可以給你很多機會，活到老學(xué)到老

首發(fā)于SFLYQ博客