從0到1的電商架構(gòu)，初期該怎么做？

來源：中生代技術(shù)群

問題提出

今天在電商金融架構(gòu)群里，來自螞蟻金服的于總拋出了一個問題：“完全從0到1建設(shè)一個電商網(wǎng)站，技術(shù)上如何選型，如何快速上線？”

群友們集思廣益

參與討論的電商公司背景：有來自傳統(tǒng)行業(yè)的“互聯(lián)網(wǎng)+”式的電商商城平臺，有目前正處在風(fēng)口的“跨境電商”，也有來自知名大公司的電商實踐等。

• UC的莫俊彬說：“我覺得...先把基礎(chǔ)設(shè)施弄好，上云..搞業(yè)務(wù)..這樣精力就集中了”（給贊，還賣了一手好萌）。
• 北京的isnow分享了他的經(jīng)歷：“我們是去年10月份(注：2014年)從0到1搭建的電商網(wǎng)站，做知識產(chǎn)權(quán)電商，2b2c的業(yè)務(wù)，開始在首都在線的云上，前端是用bootstrap，使用nginx做負載均衡，后端用springmvc+spring+mybatis數(shù)據(jù)庫用mysql，支付接入第三方支付，支付寶和銀聯(lián)支付，網(wǎng)站分前端用戶訪問和后端業(yè)務(wù)系統(tǒng)，分開部署，前端部署在兩臺tomcat上，mysql一主一備，這大概是我們的第一版系統(tǒng)的架構(gòu)。開始的時候產(chǎn)品線比較單一，將主打的產(chǎn)品上線，然后在后期迭代過程中逐步上線其他業(yè)務(wù)。”

于總心想。。我才不相信你們沒遇到問題，說問題。。

然后isnow就開始倒苦水模式。。。

1. 由于人員和流程的問題，每次上線都是直接將變動的class文件部署上去，代碼管理沒跟上；
2. 隨著業(yè)務(wù)線的增多，發(fā)現(xiàn)最開始的業(yè)務(wù)架構(gòu)無法擴展，每次增加業(yè)務(wù)線代碼重用效率不高；
3. 由于業(yè)務(wù)線中存在大量的文件，導(dǎo)致隨著訂單的逐漸增多，文件io變慢 ；
4. 隨著業(yè)余訂單的變多，訂單訪問開始變慢；
5. 因為業(yè)務(wù)系統(tǒng)是o2o的模式，客戶那邊做業(yè)務(wù)的時候容易對業(yè)務(wù)經(jīng)常狀態(tài)變動，現(xiàn)階段都是專人在數(shù)據(jù)庫上更改數(shù)據(jù)狀態(tài)，個人覺得太危險；
6. 業(yè)務(wù)方變動太大，我們的產(chǎn)品暫時在市場上沒有可借鑒的(第一個吃螃蟹的)，因此在業(yè)務(wù)上一直都是在變動，然后就形成了一種業(yè)務(wù)混亂的感覺。后來，招了cto，改第二版時候把大量的業(yè)務(wù)邏輯轉(zhuǎn)移到數(shù)據(jù)庫里用存儲過程來解決，導(dǎo)致業(yè)務(wù)邏輯分散。
7. 感覺創(chuàng)業(yè)公司其實技術(shù)過得挺艱難的，招不到好的人員，領(lǐng)導(dǎo)在新技術(shù)的嘗試上往往步伐沒那么大，不敢輕易上他沒有把握的技術(shù)，有時候甚至為了穩(wěn)定去將就一些技術(shù)甚至業(yè)務(wù)上的坑”于總看到這里瞬間不淡定了：“CTO的經(jīng)驗決定技術(shù)堆棧??！存儲過程是一個大坑，未來要分離，服務(wù)，可讀性都是問題”。

• 小剛插了一句：“硬件和網(wǎng)絡(luò)，直接買廠商的”(土豪任性)
• 來自金山的Kerwin說：“先想一個能擴展的框架”（果然是大公司的，家底就是厚呀）
• 北京的孔慶龍則說：完全從0到1 建設(shè)一個電商網(wǎng)站：
• 如何選型，首先要清楚自己想要什么這個就要做好業(yè)務(wù)分析和業(yè)務(wù)架構(gòu)和戰(zhàn)略整理，進而找到關(guān)鍵需求，通過關(guān)鍵需求來對市面上的技術(shù)或者套裝軟件進行選型——也就是應(yīng)用架構(gòu)選型。
• 快速上線：這個涉及到的問題較多，如數(shù)據(jù)架構(gòu)、基礎(chǔ)架構(gòu)、應(yīng)用架構(gòu)、安全架構(gòu)等一系列問題，如果安全架構(gòu)不高那么上云是一個不錯的選擇，畢竟云可以提供一整套的PASS和saas解決方案。
• 關(guān)于技術(shù)棧：主要是根據(jù)自己的團隊人員量身打造，從前到后有前端技術(shù)選型（jquery、Bootstrap等）、HTTP網(wǎng)關(guān)或LBS（nginx、F5等）、容器中間件（Tomcat、jboss、weblogic等）、應(yīng)用（SSH、分布式的dubbo等）、數(shù)據(jù)庫（mysql、redis、oracle、db2等），監(jiān)控軟件（應(yīng)用監(jiān)控、網(wǎng)絡(luò)監(jiān)控、數(shù)據(jù)庫監(jiān)控、服務(wù)監(jiān)控等）
• 關(guān)于團隊：如何快速構(gòu)建如何上實現(xiàn)DEVOPS（技術(shù)工具如：maven、svn/git、sonar、jenkins、Confluence、jira、nexus等）
• 于總補充到：“容器中間件（Tomcat、jboss、weblogic等），現(xiàn)在都是tomcat 和jetty，其他的太重?！?/li>
• 剛開始做跨境電商的Jesse說：項目一個半月上線。
• 服務(wù)器與數(shù)據(jù)庫直接買現(xiàn)成的，減少運維成本。目前我們是ECS加RDS，全是阿里云。 框架是Spring+Mybatis，服務(wù)器是tomcat
• 圖片存儲用的是OSS，自定義域名，CDN加速（也是阿里云的）首頁優(yōu)化包括動靜分離，異步加載，用戶首頁打開速度從7秒多縮短到了3秒以內(nèi)。 由于上線匆忙，很多細節(jié)來不及優(yōu)化和確定。所以對于一些經(jīng)常變動的模塊直接用新的工程。這樣要修改不會影響到其他模塊。 代碼管理用Git。沒有service話，感覺用不到。
• 緩存直接是EHCache，每個機器都保存一份。沒有用memcache，因為目前memcahche還是會增加管理成本。
• 負載均衡也是直接上阿里云的負載均衡
• 快速上線的一個問題就是好多技術(shù)設(shè)計的細節(jié)沒有考慮完善，代碼比較粗糙，但是又不能做大的調(diào)整，而且還要兼顧新的功能。目前的做法是，業(yè)務(wù)需要更改哪一個模塊，就去在做業(yè)務(wù)的過程中去重構(gòu)，而且做灰度發(fā)布。
• 業(yè)務(wù)上跨境電商的一個大問題就是貨幣問題。不同國家的用戶登錄顯示的貨幣要不一樣。對于產(chǎn)品，報關(guān)是個大問題，現(xiàn)在這一塊都是運營手動報關(guān)發(fā)貨。現(xiàn)在還做不出來那種跨境DRP，即使購買現(xiàn)成的服務(wù)也不知道該咋用。 匯率是采用一個月取平均值。要判斷是哪個國家的話。。先做成讓用戶自己選。。但其實現(xiàn)在就是中文和英文
• UC的莫俊彬接著問了一個問題：“初期數(shù)據(jù)支撐，這塊感覺不好做，不知道有沒專做這塊服務(wù)的公司?！?/li>
• 來自北京的俞斌說：“我們?nèi)堪⒗镌??！?/li>
• 來自深圳的小剛說：我們的業(yè)務(wù)才剛起步，技術(shù)上沒有太多的創(chuàng)新。
• 硬件帶寬：非核心業(yè)務(wù)，阿里云；
• 整體架構(gòu)：分層模式+微服務(wù)模式，可復(fù)用的核心功能下沉、抽成服務(wù)。
• 技術(shù)選型： 3.1. 網(wǎng)站前端php+yii+thrift+阿里ocs+mysql；
• 3.2. 后臺服務(wù)spring+mybatis+thrift+dubbo+mysql
• 最后來自友群的朋友分享了他們的經(jīng)驗：我們現(xiàn)在電商商城平臺，算是從0-1，我全程參與過，技術(shù)選型也都參與討論過，現(xiàn)在來看的話，犯過以下幾個錯誤：
• 沒有準確估計實際業(yè)務(wù)量或是就沒估計，導(dǎo)致技術(shù)選型直接參考京東，淘寶等一線公司，實現(xiàn)較復(fù)雜，技術(shù)鋪的也很大。
• 因為缺少經(jīng)驗的原因吧，前期業(yè)務(wù)沒有明確的規(guī)劃，技術(shù)選型也沒有考慮高內(nèi)聚，低耦合，導(dǎo)致系統(tǒng)之間依賴太強，現(xiàn)在想拆分很難
• 選擇了一些較新的技術(shù)框架，依賴于1~2個技術(shù)牛人，牛人離職，一片茫然。。。
• 初期除了購買流程上不能有技術(shù)短板外，產(chǎn)品為核心的營銷數(shù)據(jù)流也很重要。提升流量，用流量測試轉(zhuǎn)化率和動銷率，然后想辦法提升這兩點。一旦轉(zhuǎn)化率穩(wěn)定，才是買大流量的時候。這些都要有數(shù)據(jù)支撐試錯。

總結(jié)

最后我們總結(jié)了一下我們的討論：

快速上線，滿足目標不要做過多設(shè)計，大概用到的技術(shù)堆棧有：

電商商城平臺一般都分為面向客戶的客戶端網(wǎng)站系統(tǒng)、面向公司內(nèi)(或第三方平臺)的業(yè)務(wù)系統(tǒng)以及運維平臺(云平臺)。

• 對于面向客戶端的網(wǎng)站系統(tǒng)主要包括以下幾個模塊：1. 用戶管理系統(tǒng) 2. 商品管理系統(tǒng) 3. 支付系統(tǒng) 4. 訂單管理系統(tǒng) 5. 評價系統(tǒng)
• 對于面向公司內(nèi)(或第三方平臺)的業(yè)務(wù)系統(tǒng)主要包括以下幾個模塊：
• 人員管理以及權(quán)限管理系統(tǒng)
• 客戶服務(wù)系統(tǒng)
• 訂單管理系統(tǒng)
• 財務(wù)管理系統(tǒng)
• 商品維護系統(tǒng)
• 數(shù)據(jù)統(tǒng)計系統(tǒng)
• 運營支撐系統(tǒng)
• 主要架構(gòu)圖：從圖中我們可以很清晰的看到大概的技術(shù)棧：

1. 前端系統(tǒng):

1.1 Web端技術(shù)選擇:

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. 后端系統(tǒng)

2.1 負載均衡系統(tǒng)

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容器集群(最基礎(chǔ)的集群，一主一備)

2.2.1 傳統(tǒng)模式，將所有模塊定義到同一個項目中發(fā)布到web容器中

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

2.3 文件服務(wù)器

2.3.1 儲存方式

2.3.2 儲存容量

2.3.3 安全性與存取權(quán)限控管

2.3.4 存取效能

2.4 緩存服務(wù)器

2.4.1 分布式Redis緩存

2.4.2 Memcache緩存

2.4.3 EHCache等

2.5 消息系統(tǒng)

2.5.1 ActiveMQ

2.5.2 分布式消息系統(tǒng)Kafka、Rocketmq等

2.6 數(shù)據(jù)持久層

2.6.1 關(guān)系型數(shù)據(jù)庫

(1). PostgreSQL

(2). Mysql

(3). Oracle、DB2等

2.6.2 Nosql

(1). MongoDB

(2). HBase等

注：硬件解決方案的優(yōu)點是：有專業(yè)的維護團隊來對這些服務(wù)進行維護、缺點就是花銷太大。軟件解決方案的優(yōu)點是費用低廉，缺點是開源系統(tǒng)，可能出問題得自己想辦法找解決方案

• 
  

2.CTO(技術(shù)負責(zé)人)會很大程度上影響技術(shù)發(fā)展

CTO 在創(chuàng)業(yè)公司扮演了的角色很獨特，創(chuàng)業(yè)公司CTO不僅負責(zé)業(yè)務(wù)上的開發(fā)任務(wù)，還負責(zé)扛住外界(其他部門負責(zé)人)的壓力等。對內(nèi)還要負責(zé)團隊人員的合理搭配和安排，對外負責(zé)開發(fā)任務(wù)的安排和調(diào)控。 同時CTO在技術(shù)選型上更多時候考慮的是自身熟悉的技術(shù)以及穩(wěn)定的技術(shù)，或許創(chuàng)業(yè)公司有更多的試錯機會，但畢竟是身處創(chuàng)業(yè)的環(huán)境，外界環(huán)境不可能給予團隊多次失誤的機會， 因此在技術(shù)選型上包括公司技術(shù)走向上更多的取決于CTO對技術(shù)的熟練程度。

3.發(fā)展過程中遇到的問題

問題：

1. 由于創(chuàng)業(yè)公司迭代非常頻繁，因此運維上線的問題是大一個很大的問題我們開始的解決是每次將修改后的class文件直接替換線上環(huán)境，這種方案是非常危險的。后期我們搭建了自動部署平臺，基于Git和Jenkins進行代碼自動化部署。
2. 前期由于各種各樣的原因?qū)е聵I(yè)務(wù)邏輯上耦合程度高，開發(fā)新業(yè)務(wù)線的成本很高這個沒辦法，前面挖的坑后面慢慢填，然后在重構(gòu)的時候，一點點的將業(yè)務(wù)獨立出來，使用微服務(wù)方式進行架構(gòu)。
3. 前期未將系統(tǒng)中文件同代碼分離出來，導(dǎo)致隨著用戶量增多，服務(wù)器IO越來越慢搭建文件服務(wù)器，將所有文件移到文件服務(wù)器中，減輕web應(yīng)用服務(wù)器的壓力。
4. 隨著訂單的增多，后臺業(yè)務(wù)系統(tǒng)訂單訪問變慢第一步，從sql優(yōu)化的角度，看是否能夠通過加索引等方式加快速度。第二步，計算訂單相關(guān)表的讀寫比，進行分庫分表操作。(目前我們團隊還未到達這一步)
5. 業(yè)務(wù)方需求變動太快或產(chǎn)品思路不清晰，每次迭代都是在挖坑這個沒辦法，第一，尋找更加懂業(yè)務(wù)的產(chǎn)品經(jīng)理。第二，業(yè)務(wù)開會須有核心業(yè)務(wù)開發(fā)人員參與，對需求或產(chǎn)品的發(fā)展做出中肯的評審

4.我們的關(guān)于從0到1的電商商城平臺建設(shè)的一些建議

1. 對核心業(yè)務(wù)思路要成熟，不要人云亦云，千萬不要說"淘寶、京東就是這么搞的"。要結(jié)合自己的產(chǎn)品和業(yè)務(wù)去架構(gòu)自己的平臺。
2. 在技術(shù)選擇上，盡量選擇開源穩(wěn)定的方案，不要選特別新的技術(shù)。
3. 前期可以將非核心數(shù)據(jù)或服務(wù)托管在穩(wěn)定可靠的云服務(wù)平臺上，集中精力將核心業(yè)務(wù)完成核心業(yè)務(wù)的開發(fā)和產(chǎn)品迭代，到團隊有一定的積累后，可選擇自主開發(fā)某些托管在云平臺的服務(wù)。
4. 能選擇將業(yè)務(wù)分離開，則盡量分離開，以方便后期產(chǎn)品的重構(gòu)。

分享標題：從0到1的電商架構(gòu)，初期該怎么做？
網(wǎng)站網(wǎng)址：http://muchs.cn/news/103556.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、網(wǎng)頁設(shè)計公司、響應(yīng)式網(wǎng)站、做網(wǎng)站、網(wǎng)站導(dǎo)航、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)