轉： 從0到1的電商架構應該怎麼作？

from:  https://yq.aliyun.com/articles/54414

 

1. 摘要：

問題提出

今天在電商金融架構羣裏，來自螞蟻金服的於總拋出了一個問題：「徹底從0到1建設一個電商網站，技術上如何選型，如何快速上線？」

羣友們集思廣益

參與討論的電商公司背景：有來自傳統行業的「互聯網+」式的電商平臺，有目前正處在風口的「跨境電商」，也有來自知名大公司的電商實踐等。

 

UC的莫俊彬說：

我以爲...先把基礎設施弄好，上雲..搞業務..這樣精力就集中了」（給贊，還賣了一手好萌）。

 

北京的isnow分享了他的經歷：

「咱們是去年10月份(注：2014年)從0到1搭建的電商網站，作知識產權電商，2b2c的業務，開始在首都在線的雲上，前端是用bootstrap，使用nginx作負載均衡，後端用springmvc+spring+mybatis數據庫用mysql，支付接入第三方支付，支付寶和銀聯支付，網站分前端用戶訪問和後端業務系統，分開部署，前端部署在兩臺tomcat上，mysql一主一備，這大概是咱們的初版系統的架構。開始的時候產品線比較單一，將主打的產品上線，而後在後期迭代過程當中逐步上線其餘業務。」

 

於總心想我纔不相信大家沒遇到問題，說問題。

 

而後isnow就開始倒苦水模式:

1. 因爲人員和流程的問題，每次上線都是直接將變更的class文件部署上去，代碼管理沒跟上；
2. 隨着業務線的增多，發現最開始的業務架構沒法擴展，每次增長業務線代碼重用效率不高；
3. 因爲業務線中存在大量的文件，致使隨着訂單的逐漸增多，文件io變慢 ；
4. 隨着業餘訂單的變多，訂單訪問開始變慢；
5. 由於業務系統是o2o的模式，客戶那邊作業務的時候容易對業務常常狀態變更，現階段都是專人在數據庫上更改數據狀態，我的以爲太危險；
6. 業務方變更太大，咱們的產品暫時在市場上沒有可借鑑的(第一個吃螃蟹的)，所以在業務上一直都是在變更，而後就造成了一種業務混亂的感受。後來，招了cto，改第二版時候把大量的業務邏輯轉移到數據庫裏用存儲過程來解決，致使業務邏輯分散。
7. 感受創業公司其實技術過得挺艱難的，招不到好的人員，領導在新技術的嘗試上每每步伐沒那麼大，不敢輕易上他沒有把握的技術，有時候甚至爲了穩定去將就一些技術甚至業務上的坑」。

 

於總看到這裏瞬間不淡定了：「CTO的經驗決定技術堆棧啊！存儲過程是一個大坑，將來要分離，服務，可讀性都是問題」。

 

• 小剛插了一句：「硬件和網絡，直接買廠商的」(土豪任性)
• 來自金山的Kerwin說：「先想一個能擴展的框架」（果真是大公司的，家底就是厚呀）
• 北京的孔慶龍則說：徹底從0到1 建設一個電商網站？

 

1. 如何選型，首先要清楚本身想要什麼這個就要作好業務分析和業務架構和戰略整理，進而找到關鍵需求，經過關鍵需求來對市面上的技術或者套裝軟件進行選型——也就是應用架構選型。
2. 快速上線：這個涉及到的問題較多，如數據架構、基礎架構、應用架構、安全架構等一系列問題，若是安全架構不高那麼上雲是一個不錯的選擇，畢竟雲能夠提供一整套的PASS和SAAS解決方案。
3. 關於技術棧：主要是根據本身的團隊人員量身打造，從前到後有前端技術選型（jquery、Bootstrap等）、HTTP網關或LBS（nginx、F5等）、容器中間件（Tomcat、jboss、weblogic等）、應用（SSH、分佈式的dubbo等）、數據庫（mysql、redis、oracle、db2等），監控軟件（應用監控、網絡監控、數據庫監控、服務監控等）
4. 關於團隊：如何快速構建如何上實現DEVOPS（技術工具如：maven、svn/git、sonar、jenkins、Confluence、jira、nexus等）

 

• 於總補充到：「容器中間件（Tomcat、jboss、weblogic等），如今都是tomcat 和jetty，其餘的過重。」
• 剛開始作跨境電商的Jesse說：項目一個半月上線。

 

1. 服務器與數據庫直接買現成的，減小運維成本。目前咱們是ECS加RDS，全是阿里雲。 框架是Spring+Mybatis，服務器是tomcat
2.  圖片存儲用的是OSS，自定義域名，CDN加速（也是阿里雲的）首頁優化包括動靜分離，異步加載，用戶首頁打開速度從7秒多縮短到了3秒之內。 因爲上線匆忙，不少細節來不及優化和肯定。因此對於一些常常變更的模塊直接用新的工程。這樣要修改不會影響到其餘模塊。 代碼管理用Git。沒有service話，感受用不到。
3. 緩存直接是EHCache，每一個機器都保存一份。沒有用memcache，由於目前memcahche仍是會增長管理成本。
4. 負載均衡也是直接上阿里雲的負載均衡
5. 快速上線的一個問題就是好多技術設計的細節沒有考慮完善，代碼比較粗糙，可是又不能作大的調整，並且還要兼顧新的功能。目前的作法是，業務須要更改哪個模塊，就去在作業務的過程當中去重構，並且作灰度發佈。
6. 業務上跨境電商的一個最大問題就是貨幣問題。不一樣國家的用戶登陸顯示的貨幣要不同。對於產品，報關是個大問題，如今這一塊都是運營手動報關發貨。如今還作不出來那種跨境DRP，即便購買現成的服務也不知道該咋用。 匯率是採用一個月取平均值。要判斷是哪一個國家的話。。先作成讓用戶本身選。。但其實如今就是中文和英文

 

• UC的莫俊彬接着問了一個問題：「初期數據支撐，這塊感受很差作，不知道有沒專作這塊服務的公司。」
• 來自北京的俞斌說：「咱們所有阿里雲。」
• 來自深圳的小剛說： 咱們的業務纔剛起步，技術上沒有太多的創新。

1. 硬件帶寬：非核心業務，阿里雲；
2. 總體架構：分層模式+微服務模式，可複用的核心功能下沉、抽成服務。
3. 技術選型

            3.1.  網站前端php+yii+thrift+阿里ocs+mysql；

            3.2.  後臺服務spring+mybatis+thrift+dubbo+mysql

 

• 最後來自友羣的朋友分享了他們的經驗：

咱們如今電商平臺，算是從0-1，我全程參與過，技術選型也都參與討論過，如今來看的話，犯過如下幾個錯誤：

 

1. 沒有準確估計實際業務量或是就沒估計，致使技術選型直接參考京東，淘寶等一線公司，實現較複雜，技術鋪的也很大。
2. 由於缺乏經驗的緣由吧，前期業務沒有明確的規劃，技術選型也沒有考慮高內聚，低耦合，致使系統之間依賴太強，如今想拆分很難
3. 選擇了一些較新的技術框架，依賴於1~2個技術牛人，牛人離職，一片茫然。。。
4. 初期除了購買流程上不能有技術短板外，產品爲核心的營銷數據流也很重要。提高流量，用流量測試轉化率和動銷率，而後想辦法提高這兩點。一旦轉化率穩定，纔是買大流量的時候。這些都要有數據支撐試錯。

 

總結

 

最後咱們總結了一下咱們的討論：

 

快速上線，知足目標不要作過多設計，大概用到的技術堆棧有：

電商平臺通常都分爲面向客戶的客戶端網站系統、面向公司內(或第三方平臺)的業務系統以及運維平臺(雲平臺)。

 

對於面向客戶端的網站系統主要包括如下幾個模塊：

    1. 用戶管理系統

    2. 商品管理系統

    3. 支付系統

    4. 訂單管理系統

    5. 評價系統

 

對於面向公司內(或第三方平臺)的業務系統主要包括如下幾個模塊：

人員管理以及權限管理系統

• 客戶服務系統
• 訂單管理系統
• 財務管理系統
• 商品維護系統
• 數據統計系統
• 運營支撐系統

 

主要架構圖：

 

 

從圖中咱們能夠很清晰的看到大概的技術棧：

1. 前端系統:

     1.1 Web端技術選擇:

            1.1.1 JS框架搭建

            1.1.2 PHP框架搭建

            1.1.3 JSP/Freemarker模板+UI框架(Bootstrap等)+Jquery工具

    1.2 移動端

           1.2.1 Android平臺

           1.2.2 IOS平臺

           1.2.3 Mobile(H5)平臺

2. 後端系統

     2.1 負載均衡系統

        2.1.1 硬件類負載均衡器

              (1). NetScaler

              (2). F5

              (3). Radware

              (4). Array

       2.1.2 基於Linux免費開源的負載均衡軟件策略

              (1). Nginx

              (2). LVS/HAProxy

              (3). Lighttpd、Apache-mod_proxy、Squid、Socks、TIS FWTK、Delegate等

     2.2 web容器集羣(最基礎的集羣，一主一備)

        2.2.1 傳統模式，將全部模塊定義到同一個項目中發佈到web容器中

        2.2.2 SOA模式(微服務模式),根據業務模塊將系統進行拆分，分開部署，系統間使用rpc或rest方式調用。具體可參考dubbo(dubbox)、Spring-boot等框架。

    2.3 文件服務器

        2.3.1 儲存方式

        2.3.2 儲存容量

        2.3.3 安全性與存取權限控管

        2.3.4 存取效能

     2.4 緩存服務器

         2.4.1 分佈式Redis緩存

         2.4.2 Memcache緩存

         2.4.3 EHCache等

     2.5 消息系統

         2.5.1 ActiveMQ

         2.5.2 分佈式消息系統Kafka、Rocketmq等

     2.6 數據持久層

         2.6.1 關係型數據庫

              (1). PostgreSQL

              (2). Mysql

              (3). Oracle、DB2等

         2.6.2 Nosql

              (1). MongoDB

              (2). HBase等

 

注：硬件解決方案的優勢是：有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大。軟件解決方案的優勢是費用低廉，缺點是開源系統，可能出問題得本身想辦法找解決方案。

 

CTO(技術負責人)會很大程度上影響技術發展

 

CTO 在創業公司扮演了的角色很獨特，創業公司CTO不只負責業務上的開發任務，還負責扛住外界(其餘部門負責人)的壓力等。對內還要負責團隊人員的合理搭配和安排，對外負責開發任務的安排和調控。 同時CTO在技術選型上更多時候考慮的是自身熟悉的技術以及穩定的技術，或許創業公司有更多的試錯機會，但畢竟是身處創業的環境，外界環境不可能給予團隊屢次失誤的機會， 所以在技術選型上包括公司技術走向上更多的取決於CTO對技術的熟練程度。

 

發展過程當中遇到的問題

 

問題：

1.因爲創業公司迭代很是頻繁，所以運維上線的問題是最大一個很大的問題

咱們開始的解決是每次將修改後的class文件直接替換線上環境，這種方案是很是危險的。後期咱們搭建了自動部署平臺，基於Git和Jenkins進行代碼自動化部署。

 

2.前期因爲各類各樣的緣由致使業務邏輯上耦合程度高，開發新業務線的成本很高

這個沒辦法，前面挖的坑後面慢慢填，而後在重構的時候，一點點的將業務獨立出來，使用微服務方式進行架構。

 

3.前期未將系統中文件同代碼分離出來，致使隨着用戶量增多，服務器IO愈來愈慢

搭建文件服務器，將全部文件移到文件服務器中，減輕web應用服務器的壓力。

 

4.隨着訂單的增多，後臺業務系統訂單訪問變慢

第一步，從sql優化的角度，看是否可以經過加索引等方式加快速度。第二步，計算訂單相關表的讀寫比，進行分庫分表操做。(目前咱們團隊還未到達這一步)

 

5.業務方需求變更太快或產品思路不清晰，每次迭代都是在挖坑

 這個沒辦法，第一，尋找更加懂業務的產品經理。第二，業務開會須有核心業務開發人員參與，對需求或產品的發展作出中肯的評審

 

 咱們的關於從0到1的電商平臺建設的一些建議

 

1. 對核心業務思路要成熟，不要人云亦云，千萬不要說"淘寶、京東就是這麼搞的"。要結合本身的產品和業務去架構本身的平臺。
2. 在技術選擇上，儘可能選擇開源穩定的方案，不要選特別新的技術。
3. 前期能夠將非核心數據或服務託管在穩定可靠的雲服務平臺上，集中精力將核心業務完成核心業務的開發和產品迭代，到團隊有必定的積累後，可選擇自主開發某些託管在雲平臺的服務。
4. 能選擇將業務分離開，則儘可能分離開，以方便後期產品的重構。