全流程開發 | 高并發電商服務系統 | 第1關

為什麼寫這個專欄？

有些小白“自學”過程中百分之一千會有這樣的疑惑：

我學完了 Python / Java，但仍然做不出一個網站（項目）。

而且關于學習這個問題（尤其是自學），某乎上面的回答都很全，但還不夠實用。因為缺乏具體場景做出的回答實用性不強。

我隻講答案。（我也是這麼過來的，我知道 你的 不知道）

你應該先學習 全局 / 全流程 做事的 套路，然後在去做事。

這裡面的邏輯就是 學習 做事 再去 做事。

然後，基于這套做事的邏輯，你是要做一個網站，還是一個APP，做事的目标要明确。

剩下的問題就是 找學習資源 ---> 使用資源 ---> 完成目标。

(目錄)

0. 開門見山

通過本專欄，‌‌你不僅可以學到完整的電商邏輯開發，還可以學到‌‌企業項目通用的解決方案。

從兩個大方向來劃分，架構核心、架構基礎服務，‌‌架構核心我們可以學到容器，依賴注入，門面模式，中間件，服務，事件路由，驅動，‌‌這些基本上都是架構的核心和靈魂。

從架構基礎服務當中我們可以學到控制器的巧用，模型‌‌，視圖，請求，響應，異常處理，日志，錯誤，調試，驗證，‌‌多應用，緩存等等，這些内容都會在我們的專欄項目當中一一涵蓋。‌

‌還會分享一套代碼分層架構，‌‌能夠做到高度解耦多複用的能力。

其中包括5層架構，

控制器層，controller

業務邏輯層，business

内部基礎庫層，lib

視圖層，view

模型層，model。

每一層都有它相應的職責。‌‌比如說控制器層它隻負責接收請求的參數，然後對參數進行相應的校驗，‌‌然後去調用業務邏輯層的内容，業務邏輯層它隻負責去‌‌擷取模型層傳回的資料，然後對模型層的資料進行相應的組裝，‌‌它還會去請求内部基礎庫層的資料，同樣也會進行相應的封裝，然後把資料呈現給控制器層，‌‌模型層它隻負責去調取資料庫裡面的資料，它的職責很明确，隻負責去‌‌調資料庫裡面的資料就可以了，它并不對資料庫裡面的資料拿到之後再次的進行封裝，它的職責不會這樣去做。‌

‌而lib層是一些基礎庫的封裝，視圖層它隻負責一些相應的模闆引擎，‌‌比如說我們的後端頁面是采用了 layui 前端架構，那麼這個時候我們就可以結合‌‌ 模闆引擎 來處理視圖層的邏輯，‌‌這樣的話控制器層會去調用視圖層的内容，然後視圖層将内容傳回給控制器層，最終呈現給我們的使用者，‌‌是這樣的一種思想。

‌接下來我們再來看一下我們項目當中電商核心的技術點，其中包括反作弊場景，‌‌關于反作弊它是電商系統不可缺少的一個環節，‌‌因為我們可以利用它來解決黑産進行抛羊毛的場景，‌‌是以說它是我們系統當中一個重要環節。‌

‌消息隊列，關于消息隊列，我們會從‌‌最基礎的什麼是消息隊列？為什麼要使用消息隊列？消息隊列的使用場景，‌‌以及我們使用消息隊列之後，我們能帶來什麼收益？并且我們還會利用 redis 來做最簡單的消息隊列，最後過渡到 kafka，‌‌循序漸進的方式來講解這個消息隊列。‌‌

redis 叢集 ，負載均衡，限流，在限流當中，我們會采用‌‌ nginx+lua+redis 來做我們的限流場景，服務容災，系統降級，性能優化，‌‌商品搶購，并發鎖，分布式session，服務評估。‌

‌在服務評估當中，我們會‌‌根據不同的 qps 來評估我們系統的架構，比如說當我們 qps 達到5000的時候，達到1萬的時候，‌‌達到2萬的時候，達到5萬的時候等等，我們如何去架構我們的系統服務，這是我們的關鍵‌‌。

壓力測試，排隊機制。‌

‌優秀的開發者能力往往會展現在調試過程中問題挖掘，‌‌如何快速定位系統問題是一個非常重要的環節，‌‌本專欄也會帶領大家手把手的教你如何去挖掘系統存在的一些問題。

支付的服務化，‌‌支付會采用阿裡支付，微信支付，‌‌并且我們還會把它單獨抽離出來，做成一個微服務的思想，進而做到高度解耦。‌

‌以上是我們電商核心的技術點，這些内容都會在我們的後面的實戰内容中一一的進行講解，‌‌在我們課程當中會講解企業級開發流程，讓大家對企業級開發流程有一個初步的認知，‌‌并且後面的實戰也是嚴格按照這種流程進行相應的開發。‌

‌我們的開發流程會包括需求評審，‌‌需求評審它會涉及到很多人員，包括産品經理、開發工程師、開發工程師會包括前端工程師、‌‌後端工程師、測試工程師、UE設計師等等這些人員，‌‌大家坐在一起進行需求的評審，看一下哪些需求合理，哪一些需求不合理，不合理的我們剔除掉。‌

‌還有一種場景就是沒有考慮到的需求，我們也可以在需求評審完這個地方加進去。‌‌我們的需求評審完之後，這個時候的話并不是一次就過了，可能會涉及到兩次三次等等以上，‌‌最終會定一個需求評審的最終版本。‌

‌然後接下來‌‌設計師就會根據最終的需求進行相應的設計，設計相應的圖，比如說我們的電商項目，‌‌設計師的話就會去布局我們的電商的圖，有哪些功能，如何進行相應的互動等等，這都是設計師需要做的。‌

‌UE設計師把這個圖設計好之後，接下來還需要進行評審，看一下這個圖‌‌是否滿足我們的需求，這個時候同樣需要包括 UE 設計師、開發工程師、産品經理、‌‌測試工程師等等，我們坐在一起進行 UE 圖的評審，最終我們會定一個初版，然後慢慢的‌‌進行一個最終版本的确定。‌

‌UE圖确定好之後，接下來的話我們前端工程師和後端工程師‌‌就需要去定我們的接口了。因為我們的項目當中會涉及到很多 API 接口，這個時候我們需要雙方工程師進行相應的‌‌協商，看一下某一個功能需要什麼接口，通路什麼字段，這是兩類工程師一起‌‌才能确定下來。比如說你後端工程師，一個人定的接口沒有任何意義，‌‌因為你定的接口不一定适合前端工程師，知道嗎？是以這是很關鍵的因素，需要大家一起決定。‌

‌定完之後，雙方工程師就可以進行開發了，比如說後端工程師直接去開發它的接口，前端工程師‌‌就去布局它的頁面，後端工程師如果開發完了，他首先需要進行自測，我在我本地測試沒問題，‌‌這個時候我就發起聯調，我把我的接口給前端，然後我們一起進行相應的聯調，‌‌聯調完之後，同樣前端工程師和後端工程師要整體的對目前功能進行一個相應的測試，‌‌測試完之後，開發工程師覺得沒有問題了，這個時候方可進行提測，提測給誰 就提測給‌‌ QA 工程師，‌‌或者說叫測試工程師，‌‌而測試工程師就會對我們整個的功能或者項目進行第一輪測試，‌‌測試肯定會遇到一些小小的問題，這個時候測試工程師就會發一些測試報告，說你這個地方有什麼問題需要修改，‌‌這個時候像後端工程師都要針對于測試工程師提的這些建議，bug 進行相應的修複，修複完之後‌‌再進行相應的提測，最終 QA 工程師認為沒有問題了，才能夠方可上線。‌

‌這個時候 QA 工程師必須要去發一個測試報告，認為本次功能沒有問題，‌‌可以上線，這個時候我們的前後端工程師才能夠進行相應的上線，那麼這是我們整個開發的流程‌‌。‌

‌接下來我們來看一下我們的頁面展示，‌‌

體驗位址：http://39.107.30.137:8089/

這個地方我們隻展示項目當中的前端頁面，我們的前端頁面是采用 VUE 進行相應的建構，‌‌ta直接會去請求我們的後端 API 服務，這是我們的首頁，我們的首頁會包括分類、‌‌搜尋、‌‌購物車、輪播圖，商品某個分類的推薦，‌‌這是我們的商品詳情頁，點選某一個商品會進入到商品詳情頁，我們會展示‌‌單個商品的詳細資訊，并且還會支援 sku ，立即購買，加入購物車，爆款推薦，‌‌

這是我們的登入頁面，我們的登入頁面會采用手機号加短信驗證碼的方式進行登入，‌‌短信驗證碼我們是使用阿裡雲短信的方式，這是我們的訂單清單頁，這是我們的個人中心頁面，‌‌個人中心頁面我們會有個人資料，收貨位址等等這些内容，

這個是我們的支付頁面。‌

‌關于支付頁面，我們會使用支付寶和微信支付的方式，并且在課程當中我們會把‌‌支付寶，微信支付這些支付的場景會單獨抽離出來，做成一個服務化，‌‌進而做到高度解耦。

因為這樣的話，後續比如說我們的電商可以使用，活動也可以去使用支付，‌‌很友善。

‌接下來我們再來看一下我們 項目的功能點。

從兩個大方向來劃分的話，包括電商前端和電商後端，‌‌

前端我們會包括首頁、商品詳情頁、注冊登入頁、購物車頁、訂單頁面、‌‌支付頁面、商品清單頁面、個人中心，

後端我們會包括登入、商品管理、分類管理、‌‌訂單管理等等。‌

‌首頁會包括商品展示，搜尋分類，支援‌‌無限極分類，購物車，頁面靜态化，redis 緩存，

商品詳情頁會包括sku設計，‌‌購買，加入購物車，爆款推薦，高并發下商品的搶購。‌

‌登入頁面會包括手機号加驗證碼的方式進行登入。分布式session解決方案，

支付頁面我們會包括微信支付，‌‌支付寶支付，在前期過程當中，我們的微信支付、支付寶支付會在我們電商‌‌系統當中開一個小小子產品，後續為了高度解耦，我們把微信支付和支付寶支付單獨抽離成一個‌‌服務，進行高度解耦。

個人中心包括個人資料、收貨位址，我的訂單等等。‌

‌後端當中，‌‌我們的商品管理其實還會包括很多的功能，比如說 sku 的設計和管理，圖檔上傳，多圖上傳，‌‌分頁搜尋等等，

分類管理，我們支援無限極分類等等，

這些都是我們‌‌需要或者說常見的一些功能點。

1. 開發流程和規範

‌本小節我們來學習和了解 開發流程和規範的說明。‌‌

那麼一般來說，開發流程基本上都是會‌‌按照如下的方式去進行，

首先會有一個需求，那麼這個需求是來自哪裡？基本上是‌‌我們的産品經理确認，‌‌确認好需求之後，我們會進行一些需求評審，需求評審的時候會有哪一些人員參與？‌

‌比如說有産品經理，然後有開發工程師，那麼開發工程師它會分很多類，比如說有後端的‌‌前端的，前端又包括比如說FE以及AP端的，比如說iOS開發工程師，‌‌安卓開發工程師等等這些，可能還會涉及到你們的負責人對吧？‌

‌你們的經理我們都可能會在一起，‌‌比如說在一個小會議室，我們一起來讨論一下這個需求是否合理，哪一些需求我們需要砍掉，哪一些需求，我們比較着急，‌‌在本次開發中我們需要去完成，那麼這個是需求評審要做的事情。‌

‌評審完之後，我們确定最終這一版我們需要開發的内容，‌‌這個時候的話我們的設計師就會根據我們的需求去設計相應的圖，那麼這個時候就是第二點，‌‌UE圖設計，那麼 TA 會根據我們之前評審的最終的需求去設計相應的圖，‌‌設計完之後，這個時候我們還會去進行一些評審，‌‌評審最終的設計師設計的圖是否和産品經理最終定的需求是否一緻，這個也是需要去‌‌評審的，不然的話 UE 設計完這個圖之後，并不是産品經理最終想要的這種情況，這樣的話也是沒用的，是以這個中間也會有一個‌‌ UE 圖的評審過程，設計圖完之後，我們就可以接下來對我們最終的内容‌‌或者說需求進行一些接口的定義。‌

‌比如說我們目前這個需求有10個功能，‌‌這 10 個功能可能會涉及10~15個API，‌‌這個時候我們後端工程師和前端工程師需要協商，我先定一套接口，把接口先定義好，‌‌定義好之後我們才能夠進行接下來的開發。‌‌因為你接口沒有定義好，你就去開發，這個時候其實是會有一些問題的，并且這個接口定義是需要前端工程師和後端工程師‌‌一起讨論，最終定一個相應的接口文檔。‌

‌因為不然你後端工程師自己下定義并不适合于前端工程師的‌‌規範，這也是不合理的，是以必須兩類工程師坐在一起讨論，最終定一個約定書成的接口文檔。‌【swagger，yapi，showdoc，自己寫的markdown，語雀，石墨】

‌那麼這個接口文檔它其實是有一個‌最基本的規範，比如說有一個狀态碼，有一個消息提示，還有一些‌‌資料字段，這個時候可以有status代表狀态碼，‌‌message代表消息提示，然後有個list或者說data代表第三個字段的資料，這個後續我們會做詳細的介紹。‌

‌這裡的話大家隻需要了解一下就可以，這個文檔定好之後，這個時候的話我們前後端工程師就可以‌‌去開發内容了，後端工程師就根據某些功能，然後開發不同的‌‌接口進行相應的開發，前端工程師就會根據 UE 設計的圖，然後進行相應的布局‌‌等等這些内容，然後我們後端工程師把接口開發完之後，就可以把接口提供給前端工程師。‌

‌怎麼提供？一般來說，後端工程師會把相應的功能或者說API服務會部署到‌‌比如說測試環境，看你們的情況而定，一般我們是會部署到測試環境，‌‌後端工程師開發的時候會在自己的本地進行相應的開發，‌‌開發完之後，如果要和前端進行聯調這個事的話，需要部署一個測試環境或者說聯調環境，‌‌不然的話多人開發的時候可能就會沖突，對吧？‌

‌是以一般是這樣的，那麼這個時候就涉及到前後端聯調，‌‌前後端聯調我們需要部署一個獨立的環境，專門是進行相應的聯調的，因為這樣的話，‌‌我後端工程師我開發的時候就不會影響前端工程師聯調的進度，不然如果我們後端工程師，比如說我自己要修改一個内容，‌‌這個時候伺服器崩掉或者挂掉，前端工程師他去聯調的時候接口通路不了，‌‌其實是會影響他的進度的，是以說我們聯調環境一定要去獨立單獨開一個環境出來，直接放聯調環境上面，那麼前端工程師‌‌就很好的進行相應的聯調就可以了。‌

‌聯調完之後，這個時候我們需要關注是什麼？首先我們需要的是前後端工程師‌‌自己去整體的測試一下這個流程，你得確定我們自己開發的功能沒有bug，‌‌雖然不能百分之百的把握，但是我們必須要自行的去測試，在自己的範圍之内保證沒有任何問題。‌

‌這就是自測，自測完之後，我們就需要提測，提測給公司級的 QA，也就是測試工程師‌‌。一般的公司都會有測試工程師專門進行功能測試，他會根據産品經理定的需求，然後他會去寫一些測試用例，‌‌然後最終我們提供給他一個測試環境，‌‌他就會進行相應的測試，相對來說他的測試場景會比我們前後端工程師自測的場景要專一一點。‌

‌他測試完之後，這個時候，他就會針對于有一些不合理的場景，或者說有一些隐藏的bug，他會提出來，‌‌提出完之後，我們前後端工程師就根據自身的情況‌‌去進行相應的修複，修複完之後繼續提測，那麼直到我們的功能沒有任何問題了，‌‌這個時候方可上線。‌

‌在上線之前必須要經過我們的 QA 工程師進行确認，‌‌比如說他認為目前的功能沒有任何問題了，他會發一個測試報告，目前‌‌有多少bug，修複了多少bug，然後最終我們的功能沒有任何問題，‌‌達到上線的标準，類似于這麼一個測試報告抄送給‌‌我們的後端前端工程師以及經理，這個時候我們才能夠去上線。‌

‌上線完之後，這個時候還需要前後端工程師以及 QA 進行相應的測試，看一下線上是不是有問題。‌

‌那麼關于這個上線一般中大型公司它都會分級釋出，‌‌比如說先小流量上一台機器，然後觀看一下機器是否有問題，然後在小流量‌‌的比如說10台或者20台先上一下，‌‌最後進行全量，一般的流量是這樣的，它會有一個分級釋出，先上一台，再上10~20台，再上最後的全量，‌‌那麼中間你還上多少無所謂，大緻的流程是這樣的，他會先分級釋出，先上線一點，再上一點，最終全量，是這麼一個邏輯。‌

‌開發流程基本上中大型公司都是按照這種場景來做的。‌‌

那麼我們還需要去嚴格遵守我們的規範說明。

我們的開發當中必須要有接口文檔，‌‌這個文檔是非常有必要的。‌‌為什麼這麼說？因為它能夠解決很多問題，首先我們可以通過前後端一起約定一個文檔，‌‌這樣的話就能夠減少很多不必要的麻煩，對吧？因為比如說你背景工程師如果随便寫一個接口，‌‌根本不适合前端，這個時候是做了很多無用功的，是以他能夠節省很多時間，并且也很規範，

還有一點非常有用，也就是說如果你們目前項目組有新加入的同學，這個時候如果我有接口文檔也很規範，‌‌這個時候的話他上手的話也是非常‌‌快速的，有這個文檔之後，我們還需要有聯調環境，因為我們說了聯調環境主要是給‌‌前後端進行相應聯調的時候用的，然後需要有測試環境，測試環境主要是我們把前後端的‌‌代碼放到測試環境，最終提供給 QA 工程師進行測試的，‌‌這些環境最好都是獨立，最後 QA 測試工程師測試的我們工程之後，他需要有一個測試報告，‌‌這就能夠說明我們目前的一種權威性，然後就方可上線。‌

‌那麼以上這些‌‌我們開發流程和規範的說明。

2. 學習學習再學習

先講套路，

多看，

多練，

多總結。（尤其是部落格，markdown筆記）

多看 究竟 看什麼？

首先需要多看看網上的學習教程（B站，慕課網，YouTube，公衆号，部落格），‌‌或者一些大牛出的書籍（沒有名氣的作者出的書别買，這是坑）

看看别人是如何去實作這個功能的，這樣的話能夠給你帶來很多收益，‌‌并且少走很多彎路。

我們需要去多看一些文檔，‌‌這個文檔包括比如說你對 Go語言 Gin架構中 提取網頁的标簽資訊（類似于 Python 中的 BeautifulSoup 實作的功能）不了解，‌‌我認為你需要去多看一些 Gin 的官方文檔，看一下它怎麼去實作，‌‌怎麼去較好的應用到某些場景。‌

這都是技術群裡的小夥伴具體遇到的問題。

多看它的文檔，‌‌然後去一一實作裡面的一些場景，我認為這樣堅持下去，‌‌你對Gin 使用的場景或者說它的知識點肯定是掌握非常不錯的。‌

我們還需要去多看一些技術文章，‌‌可以通過 51CTO ， CSDN，部落格園，掘金等等這些官方網站去了解一些最新的技術。‌‌

我們還需要去多閱讀一些優秀的源碼，‌‌比如說你可以通過 GitHub 上去找一些關于 Go 的開源項目的源碼，‌‌通過閱讀它們的源碼，我們可以發現自己身上的不足，‌‌我認為閱讀源碼是能夠快速提升我們技術水準的一種手段。‌

‌第二大塊我們需要去多思考多實戰，怎麼去了解呢？‌‌

比如說公衆号中有些大佬寫的内容，我們一定要去反問幾個為什麼這樣做，‌‌為什麼不能這樣做？

如果我這樣做會達到一種什麼效果，并且我們還需要舉一反三‌‌，他講的場景，我能不能把他的這種思路運用到其他場景，并且我們還需要進行相應的擴充，‌‌比如說他的文章當中某一些功能點沒有去講，‌‌我需要自行的通過他之前文章講解的内容/思想/提示，我把這種場景運用過去，自行去完善擴充其他功能，‌‌

我們還需要去多實戰，你光看人家寫的東西，其實是沒用的，一定要去邊看邊想，然後再去敲代碼，‌‌這樣的話才能夠有更好的收益。‌【輸入 輸出 相結合】

‌第三大塊我們需要去多讨論，在哪裡讨論，我們可以在 QQ 群 / 微信群裡面‌‌和夥伴一起讨論學習相關的一些内容，多讨論也是能夠提升我們技術水準的一種方式。‌