電商網站的初期技術選型

青島海爾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，註明「姓名-公司-城市」，申請入羣。

 

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