電商網站的初期技術選型

今天在架構師俱樂部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全球架構師峰會 運營的技術社區，如果大家想參與分享和學習，并且是具有架構經驗的技術人，可以加入我們的架構師俱樂部微信群，微信搜索關注laocuixiabian，回復“ 架構師俱樂部 ”，即可獲得入群方法。

ArchSummit全球架構師峰會2016（深圳站）將于7月15-16日召開，涉及的議題包括研發體系構建、云服務、數據挖掘、智能硬件、技術創業、虛擬現實、機器人技術等，這是一場架構師和技術專家的高端私人聚會，7折票價限時開啟中，官網點擊 這里 。