大家好，歡迎來到小蔣聊技術。小蔣準備和大家一起聊聊技術的那些事。

小蔣最近在深入學習電商這個行業的業務和它的軟件系統之間的内在聯系，電商在最近的10年也是快速發展壯大，在這麼多年的系統建設和運維過程中也總結了很多最佳實踐，小蔣将會在學習的過程中，持續的為大家分享。

咱們先來了解一下概念：

· 問：什麼是電商系統的核心流程？

· 答：電商系統的核心流程就是，那些不太會變化的流程，也可以簡單理解為主流程。

· 問：為什麼要先定義核心流程？

· 答：因為在需求還不太明确的情況下，要定義那些不太會變化的核心流程，先把這些核心流程搭建出來，盡量簡單地實現出一個最小化的系統，然後再逐步叠代完善。

· 問：定義核心流程不是産品經理的事兒嘛？和架構師有什麼關系？

· 答：架構師要在有限的資源情況下，保證産品方案和技術方案落地。核心流程就是系統的最小範圍。所以，不考慮資源和需求範圍的架構師，技術就算再厲害方案最後都很難落地。

需求分析在大廠，一般是由産品經理來承擔的。大部分情況下，核心流程的定義是産品經理、業務負責人、架構師和技術共同定義的。但是，在小公司，往往核心流程的定義會落在開發身上。

小蔣不分享需求分析的方法和理論，這個産品經理比我懂。小蔣我隻分享一個關鍵的點：技術同學，不要一上來就設計功能和定義方法，而是先要嘗試回答下面兩個問題：

1. 這個系統（或者是功能）是給誰用的？

2. 這些人使用這個系統（或者是功能）來解決什麼問題？

電商業務，小蔣認為在這個每天都用手機購物的時代，每個人都很熟悉，很容易回答這兩個問題。這兩個問題的答案，我把他稱為業務需求。

這個系統（或者是功能）是給誰用的？

買東西的人，我們叫用戶。賣東西的人，我們叫運營人員。還有誰會用這個系統？老闆 啊！技術同學得記住，你在設計任何一個系統的時候，千萬不要把領導或者老闆給忘了，他們是給你錢的人，他們的意見非常重要！

這些人使用這個系統（或者功能）來解決什麼問題呢？

· 用戶用系統來買東西；

· 運營用系統來賣東西；

· 老闆在系統中了解他賺了多少錢；

這兩個問題的答案就是業務需求，咱們可以用下面這個Use Case圖來清晰的表述：

用戶、運營人員、老闆在Use Case 中叫參與者，那為什麼要識别參與者呢？

咱們站在商家的視角來分析：

· 電商系統的用戶，肯定希望是越多越好。用戶越多，根據轉換率，訂單就會越多，銷售額就會越大。

· 電商系統的運營人員，肯定是希望越少越好。請運營人員是需要花成本的，需要的運營人員越少肯定成本就越低。

咱們切換一下視角，站在架構師的視角再來分析：

· 根據需求，電商系統的用戶，未來肯定是海量級别的或者是互聯網級别的。從技術上需要考慮高可用和高并發，以及存儲容量。

· 電商系統的運營人員，如果是企業商城，運營人員應該是有限級别的或者是企業級别的。從技術難度上來說，不會像互聯網級别那麼高。如果是淘寶或者天貓這種電商平台，商家入駐的模式。那運營人員就是互聯網級别了。但，它的增量速度肯定不會有用戶這麼快。從架構上來看，也是需要分别對待的。

識别參與者，是為了了解系統參與者的數量級和未來增量的情況。根據參與者的數量級别，采用互聯網應用架構還是企業級應用架構。電商系統之所以要拆分模塊或者子系統，就是因為需求不同，所以功能對系統的性能指标和架構要求都不一樣。如果功能都寫在一起，最後的結果技術同學可想而知。

做業務需求的主要目的，是理解清楚業務場景。這對我們技術同學來說十分重要，因為這些場景決定了我們的功能模塊究竟該設計成什麼樣子才合适。

電商系統的核心業務流程，肯定是 購物這個流程。小蔣分享一下經典的流程圖：

在上面這個圖中我們可以看到，這是一個電商購物的流程。電商系統，一般都是這樣一個流程。

流程從用戶選購商品開始，用戶先從你的 App 中浏覽商品；找到心儀的商品之後，把商品添加到購物車裡面；都選好了之後，打開購物車，下一個訂單；下單結算之後，就可以支付了；支付成功後，運營人員接下來會給每個已經支付的訂單發貨；郵寄商品給用戶之後，用戶确認收貨，到這裡一個完整的購物流程就結束了。

那我們通過時序圖（Sequence Diagram）再來看看，對象之間是怎麼交互的。

1. 用戶開始浏覽商品，需要有一個 商品模塊 來支撐，給用戶展示商品的介紹、價格等等這些信息。

2. 用戶把選好的商品加入購物車，這個步驟，也需要一個 購物車模塊 來維護用戶購物車中的商品。

3. 用戶下單肯定需要一個 訂單模塊 來創建這個新訂單。訂單創建好了之後，需要把訂單中的商品從購物車中删除掉。

4. 訂單創建完成後，需要引導用戶付款，也就是發起支付流程，這裡需要有一個 支付模塊 來實現支付功能，用戶成功完成支付之後，需要把訂單的狀态變更為 「已支付」。

5. 之後運營人員就可以發貨了，在系統中，發貨這個步驟，需要扣減對應商品的庫存數量，這個功能需要 庫存模塊 來實現，發貨完成後，還需要把訂單狀态變更為「已發貨」。

6. 最後，用戶收貨之後，在系統中确認收貨，系統把訂單狀态變更為「已收貨」，流程結束。

這個流程涉及到的功能模塊有：商品、購物車、訂單、支付和庫存， 這幾個模塊就是一個電商系統中的核心功能模塊。

這隻是其中一個 購物 流程，還有其他的流程，如：運營人員進貨、老闆查看報表等沒有覆蓋到。

其他功能的分析也是如此，就不一一做分析了，直接給出電商系統的功能模塊劃分:

整個系統按照功能，劃分為十個模塊，除了購物流程中涉及到的：商品、訂單、購物車、支付、庫存五個模塊以外，還補充了促銷、用戶、賬戶、搜索推薦和報表這幾個模塊，這些都是構建一個電商系統必不可少的功能。小蔣來簡單介紹一下每個模塊需要實現的功能。

· 商品：維護和展示商品信息和價格。

· 訂單：維護訂單信息和訂單狀态，計算訂單金額。

· 購物車：維護用戶購物車中的商品。

· 支付：負責與系統内外部的支付渠道對接，實現支付功能。

· 庫存：維護商品的庫存數量和庫存信息。

· 促銷：制定促銷規則，計算促銷優惠。

· 用戶：維護系統的用戶信息

＊注意用戶模塊它是一個業務模塊，一般不負責用戶登錄和認證，這是兩個完全不同的功能。

· 賬戶：負責維護用戶的賬戶餘額。

· 搜索推薦：負責商城中，搜索商品和各種列表頁和促銷頁的組織和展示

簡單的說就是決定讓用戶優先看到哪些商品。

· 報表：實現統計和分析功能，生成報表，給老闆來做經營分析和決策使用。

特别說一下，促銷模塊 是電商系統中，最複雜的一個模塊。各種優惠卷、滿減、返現等促銷規則，都非常複雜。再進行疊加，小蔣舉個例子，最開始的時候京東内部的業務促銷定制人員甚至都搞不清楚 疊加後的促銷會變成什麼樣子，被薅羊毛的事件也是頻有發生。後來，增加了 風控模塊 這個情況才有所好轉。

在創建訂單時，訂單模塊 把商品和價格信息 傳給促銷模塊，促銷模塊返回 一個可以使用的 促銷列表，用戶選擇好促銷和優惠，訂單模塊把商品、價格、促銷優惠這些信息，再次傳給促銷模塊，促銷模塊則返回促銷價格。

至此，一個電商系統的概要設計就結束了。

在需求不明确情況下，系統設計往往需要靠預判。但是預判都是有概率的，不可能每次都對，甚至能有6成概率正确，就已經是大師級水平了。策略的作用就是讓我們在對的時候，能夠多實現一點，而錯的時候能少修改一點，不斷通過多做少修改，提高勝率。

小蔣還是比較強調策略的。判斷這個東西，理解個思路就好，策略才是提高勝率的東西。

如果你是商城系統的設計者，小蔣建議把促銷的變化和複雜性封禁在促銷模塊内部。不能讓一個促銷模塊把整個電商系統都搞得非常複雜，一定要根據企業現階段的業務情況，去設計和實現。一個設計方案，必須考慮方案的可行性和可落地性。

互聯網系統的另外一個策略就是 小步快跑 通過不斷地小版本的叠代，不停地進行商業可行性的驗證。這個階段，不要過多的考慮性能問題。隻有商業模式可行性通過後，也就是系統可以穩定的賺錢了，才會擴大推廣。所以，商業模式穩定後，才要開始考慮系統的性能問題，也就是所謂的高可用、高并發、系統容量、技術架構等等問題。小步快跑能夠有效的控制投入。就好比你一下子開發了一個大系統，用的時候才發現根本就不是那麼回事，系統要滿足現實業務，需要重構。俗話說“步子邁大了，容易拉胯”，這是一個道理。

這就是策略的作用，未來小蔣将會和大家一起完善我們的架構策略。

小蔣帶着大家，咱們一起了解了電商系統的概要設計，那麼接下來咱們一起來思考一個問題，如果讓你自己設計一個電商系統，你會如何考慮。

咱們做産品的同學需要思考一下：

1. 商城系統中的會有哪些角色？

2. 核心業務流程是什麼？

3. 需要劃分成幾個模塊？為什麼？

咱們做技術同學需要思考一下：

1. 使用那些技術棧？分别解決業務中哪個場景的問題？

2. 需要哪些第三方的框架和雲服務？

3. 我們的存儲系統該怎麼選型？

這些問題，小蔣将會在後面的分享中，繼續與大家交流的。

年齡的增長不可怕，可怕的是從未成長！

感謝大家支持小蔣，小蔣希望和大家共同成長，謝謝。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!