來源：中生代技術群

問題提出

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

群友們集思廣益

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

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

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

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

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

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

總結

最后我們總結了一下我們的討論：

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

電商商城平臺一般都分為面向客戶的客戶端網站系統、面向公司內(或第三方平臺)的業務系統以及運維平臺(云平臺)。

• 對于面向客戶端的網站系統主要包括以下幾個模塊：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等

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

• 
  

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

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

3.發展過程中遇到的問題

問題：

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

4.我們的關于從0到1的電商商城平臺建設的一些建議

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

分享題目：從0到1的電商架構，初期該怎么做？
文章出自：http://m.newbst.com/news6/103556.html

成都網站建設公司_創新互聯，為您提供自適應網站、商城網站、定制網站、App設計、定制開發、品牌網站設計

廣告

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