電商網站的初期技術選型

 原文地址如下：

infoq

http://www.infoq.com/cn/articles/e-commerce-web-tech-stack

今天在架構師俱樂部3群（由ArchSummit全球架構師峰會運營）裡，大家圍繞著一個話題討論地很熱烈——完全從0到1建設一個電商網站，技術選型和注意事項有哪些？群友們都結合自己的實際工作經歷分享了很多經驗教訓，這裡是其中的精選。

青島海爾Jan給大家分享了一個失敗案例的教訓：

1. 沒有準確估計實際業務量或者說就沒有估計過，導致技術選型直接參考京東、淘寶一線大公司，實現較複雜，技術鋪的也很大。（教訓：技術夠用就好，選型的目標是能夠快速實現產品的迭代）
2. 因為缺少經驗，前期業務沒有明確的規劃，技術選型也沒有考慮高內聚、低耦合，導致系統之間依賴太強，導致現在想拆分很難。
3. 選擇了一些較新的技術框架，過於依賴幾位關鍵的技術牛人，結果這些人一旦離職，就陷入迷茫。（教訓：關鍵人員一定要留住，或者有備份人選）

還有群友表示，對於早期的技術選型，不要抄大公司經驗，按需求出發，先活下來再說。要考慮到哪些是可以省的，那些是可以用現成的，哪些是需要有特色自己開發的。早期手段可以粗糙，儘量考慮雲。雲服務真的可以解決很多創業初期的一些棘手問題，而且可以省下成本。

0到1解決的是賣什麼、怎麼賣、賣給誰的問題。思考的角度分為技術化域和商業化域。技術域， 是實用生存為主， 不求高大上， 但求快速實用； 商業域，就是經營變現了， 細分領域奪城拔寨。重要的是，尋找到盈利點，建立合適的商業模式，然後通過技術來實現，除非技術驅動產品這樣的公司完全以技術為核心，掌握核心就掌握市場。

如果不及時考慮盈利問題，可能面臨以下的問題：公司跟風耗費巨資投入一個專案，技術部門找了很多人，並且採用了各種高大上的專案，結果盈利沒跟上來，最終公司決定不再急需投入，專案就黃了，研發團隊也解散了......

上海微肯CTO孔燕斌則認為，流量是電商的最大成本和成功的關鍵因素之一，關於流量的問題其實就是怎麼賣和賣給誰的問題。現線上上流量的成本是非常高的，而且傳統的線上流量都是一次性的，為什麼叫一次性，是因為即使是同一個使用者，要再次喚醒，大部分時候還是搖支付額外的成本，流量的成本誰一值跟著運營高企不下。這裡非常推薦微信上的流量，微信的流量有幾個好處，一個是使用者充足，第二個是有公眾號，可以免費喚醒使用者，第三個是有社交屬性，可以通過朋友圈、券、微信支付等微信能力進行營銷。其中對初創的企業最最重要的是可以通過微信的近場能力線上下拉人，使用很低的成本高效地拉人，快速驗證。

線下拉人的最大好處是可以通過選擇地點，來圈定自己的潛在使用者。要做到這一點，系統架構的時候需要增加微信的模組，實現和微信的和和相關的營銷功能。快速找到第一批客戶驗證業務，完成0到1，完成之後是1到100，1000，10000的複製都可以在微信這個流量裡面很好地展開，並且有效地降低運營中的流量的成本。基於篇幅的限制，在此不一一展開。

Jan認為，關於網站的流量，嚴格來說流量≠客戶量，當然這也得看如何定義。流量更多看的是網站訪問者或是App使用者的訪問情況，從進入第一個頁面到最後退出，這樣一個全流程。客戶量，相對於網站來說，我的註冊客戶多少，日訪問客戶多少(流量分析工具可以實現)，成交客戶量等等，需要結合實際公司的對客戶量的定義，結合流量分析。

初期除了購買流程上不能有技術短板外，產品為核心的營銷資料流也很重要。提升流量，用流量測試轉化率和動銷率，然後想辦法提升這兩點。一旦轉化率穩定，才是買大流量的時候。這些都要有資料支撐試錯。

LAANTO王巍表示，架構其實是妥協的結果，受投入、團隊技術水平多方面影響的，夠用就好。從基礎做好上雲的準備，比如用memcache，redis等分散式快取系統，把應用改造成與狀態無關，一方面可以做到容易擴容，隨時增加節點，另一方面可以足夠的可靠性，從而降低各方面成本；在成本有限的情況下，使用成熟技術，達到最優價效比即可，力爭達到good，不放棄對perfect的追求；片面要求百分百可靠的都是異端。滿足80%的高質量使用者需求就夠了。技術還得結合投入的多寡，凡是都有個投入產出比，因此要管理好老闆的期望和使用者的期望，所謂量力而行，做人如此，技術也是如此，做企業更是如此。秉承恰當的技術做恰當的事的理念。

就App而言，很多時候做App是為了估值。當然，依附與微信等高流量入口可以快速獲取使用者，缺陷在於人家的地盤聽人家的，有著諸多限制，當使用者積累到一定程度，業務受限於其平臺的時候，做APP就成了必然的選擇，所謂因時而動，順勢而為。

孔燕斌：從0到1的時候需求上的假設都沒有驗證，沒必要去折騰App，集中力量，快速把微信搞定，驗證需求，累積使用者，收集使用者反饋。然後才能確定是否真的需要App，絕大部分的App都是偽命題。一個App如果需求不找對，並且沒有競爭對手，可以自然增長，靠補貼的話，一個使用者20塊錢都不一定夠。所以需求需要驗證的，覺得很美妙的未必可行，不咋樣的其實會很不錯，是驢子是馬都得拉出來溜過才知道。

 速普母嬰Martin說，我是做母嬰電商這塊的，從去年4月份到現在，也是經歷了團隊從0到1，產品從0到1的過程，說說我的一點理解：

1. 人是最重要的，有個靠譜的CTO其實已經成功了一大半，CTO的經驗決定了未來產品的技術棧啊。 一些小創業公司仰慕某些巨頭的技術架構，技術專家，然後不惜花重金請來，專家出了各種高大上的方案，對麼？巨頭專家當然說的方案不能說不對，但是創業公司有可能還沒到那個體量和基礎，最重要的是，幹活的技術人員，有可能連最基本的優化邏輯都沒掌握呢。
2. 業務。產品初期能正常下單，庫存能鎖住，伺服器穩定高可用就可以了。
3. 技術。我的理解是拿來主義，有現成的或者自己能掌握的技術千萬不要去用那些最新的，一是新技術會引入時間成本，創業公司一般耗不起啊，另外新技術的把控不住可能會在未來造成難以預估的災難。
   
   我們第一期做的比較簡單，主要分三塊：前端、業務層、資料層。前端分移動端（Android、IOS）、PC端，業務層開放restful介面給前端呼叫，http協議json傳輸資料，前後端分離，分開部署，介面文件工具採用了阿里的rap，減少前端後端人員的溝通成本。其中前端主要nginx分流，當然，還沒用現在主流電商採用的nginx+lua，因為lua大家都沒底把控不了。其次圖片類的靜態檔案對接了三方的檔案儲存系統（又拍）。
   
   後端業務層採用了springmvc+mybatis，應用伺服器是tomcat，搜素業務採用了solr，還有幾臺佇列伺服器rabbitmq（用在訂單業務上）。至於資料層，則分為分散式快取和持久化資料。分散式快取採用了豌豆莢開源的codis方案，那時候redis3.0剛出來，不敢踩坑果斷放棄了，其實也可以直接用ssdb雙主，畢竟redis太耗記憶體了，尤其對創業型公司來說，省錢是最主要的，ssdb和redis對比，讀效能差的不大，並且ssdb採用leveldb做檔案儲存（當然也可以用rocksdb儲存），擺脫了記憶體的限制，在京東等一些網站都有成功的案例。
   
   至於持久化資料這層（mysql），考慮到電商業務初期，採用了讀寫分離，選擇了MHA方案（LVS+Atals+MHA），還有資料庫設計，不要用資料庫特有的，比如儲存過程，還有反正規化設計，減少表的關聯查詢，對後期的分離、服務、可讀性做考慮。

謝文淵表示，從0到1建電商上面同學把一些關鍵點都說了非常清楚，我做過幾個這種從0到1的電商，說說我的幾點看法：

從0到1，說明是一個企業的一個新的IT領域，很多業務策略和基礎根基都是不成熟，不管是業務還是技術架構，同時還有個共同特徵：上線週期短，新團隊在上面的情況下，有幾個方面是需要重點關注的：

 1. 業務流程

這一塊是所有工作的基礎，包括調研和梳理業務流程，主要涵蓋正向流程如：採購、會員管理、商品價格、上下架、購買、訂單管理、發貨、財務等，逆向的更麻煩，如退換貨、退款等另一個核心就是促銷規則，如套餐、團購、滿贈、買贈、折扣、優惠券等，這個可先從簡單入手，只是在架構設計考慮擴充套件專案週期原因，必須的關鍵活動：會員註冊、登入、購買支付、訂單稽核、發貨、對帳。

 2. 應用架構

一開始業務量小，應用拆分適可而止，初期建議有商城前端、後臺管理、訂單管理、物流發貨商城前端的演變將會是快速的，不管是業務模式還是使用者量規模，都會促使商城前端的快速迭代，其技術要求也是最高的，大多數在行業內分享的技術也都集中在這一塊後臺管理主要處理運營商城的需求，線上配置是重點，包括CMS訂單管理也是後臺應用，介面相對也多一些，如與ERP、WMS等，很多企業也在第三方電商平臺上銷售，如天貓、亞馬遜等，可以介面接入物流發貨比較規範，可以考慮外購，如WMS，也可外包，可省很多事。

 3. 技術領域

具體的技術細節不談了，非常同意前面同學說的夠用即可，不要追求高大上，也不要去學大平臺的架構，這些架構也是從最簡單的架構開始的，到現在這樣也是被業務迫使的。一定要用團隊最熟悉的技術或架構師最熟悉的，有幾點可以參考：確定技術標準，如分層，開發規範，採用的開源框架等，並培訓抽取基礎包或框架包，這個可以在邊開發應用邊抽取，如通用的Util、快取操作類、資料訪問等（這個好象所有軟體專案都是這樣，但很關鍵）初期不建議按模組拆分系統，做好模組劃分，在配置管理上做區分即可雖然拒絕過度設計，但擴充套件性和安全性一定要考慮，提前考慮擴充套件性會讓你在後續演變過程中如魚得水，尤其是商城前端的水平擴充套件，通常受到資料(配置或可賣數等)和會話的一致性限制，會話可以用memcache來管理，資料可載入到快取如redis，一個可減少DB壓力，二個能遮蔽DB層的演變，如分表分庫等。

安全性是網際網路上應用的永恆主題，可在框架層置入XSS和SQL隱碼攻擊的過濾器靜態資源和動態內容做分離，商品詳情頁可做成偽靜態化，靜態和偽靜態資源都可釋出到CDN上，對使用者體驗還是很有幫助的，萬一流量大時，也能保護後臺服務，並且可減少頻寬CMS可以從一些開源框架上做些改造來用，主要針對一些活動、首頁的一些配置，如果有WAP和APP，可以用下阿里的RAP來管理介面，會大大提高介面的可管理性值得好好設計的幾個地方：商品模型、促銷規則引擎、多型別訂單模型、第三方訂單接入適配層部署上一般採用LVS(土豪可用商用的，如F5/Array) nginx(or other web server) app server DB(or cache)，一開始一般每層搞個雙節點就好了。

另外，為了提高業務連續性，可以採用灰度釋出，可以簡單寫些指令碼，不一定要高大上的工具如果僅僅是從0到1，甚至在效能上都是可演進的，很多在併發容量、效能及高可用方面，是1之後的事情了以上只是簡單從0-1的描述，但實際上細節還是挺多的。對了，電商也算是網際網路應用，對流量統計和轉化率是運營的抓手，這些資料一定要有，流量可以用百度的就行，轉化率得從後臺出資料了，做些簡單報表也是必須的。

本次討論還包括其他群友的分享，一併感謝，在這裡就不一一列出名字了。

架構師俱樂部是由ArchSummit全球架構師峰會運營的技術社群，如果大家想參與分享和學習，並且是具有架構經驗的技術人，可以加入我們的架構師俱樂部微信群，微信搜尋關注群主cuikang10，註明“姓名-公司-城市”，申請入群。

ArchSummit全球架構師峰會2016（深圳站）將於7月15-16日召開，涉及的議題包括研發體系構建、雲服務、資料探勘、智慧硬體、技術創業、虛擬現實、機器人技術等，這是一場架構師和技術專家的高階私人聚會，7折票價限時開啟中，官網點選這裡。