1、電子商務網站一般架構有哪些
大型電子商務網站架構，摘抄 7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?===客戶是自己公司，使用標准方法即可
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?===采購成熟的規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
==電子商務一般要使用MQ，推薦IBM MQ；使用MSMQ也可
第一點是資料庫要設計好，要達到什麼級別，你可能需要考慮哪些表需要拆分，哪些表的核心數據需要冗餘，如果是mysql，還要考慮其他的問題，比如存儲引擎。
新聞肯定是要生成純靜態頁，對資料庫壓力就小很多，不過靜態頁也有管理上的不方便，更新刪除添加都要對磁碟文件進行操作
做一個自定義緩存層，對緩存邏輯進行控制，可以採用第三方緩存模塊，如果使用.net來做，可以層層緩存，頁面緩存，數據緩存（memcache，不過在win下效率不高）
電子商務網站特點就是對事務的嚴格，需要資料庫設計的時候要求高性能，也需要合適的索引，支持高並發，經常對產品表用戶表等進行索引檢查，是否有很多索引掃描和表掃描（即使是局部的，也要將逗局部地控制到最小范圍）
mssql語句對不需要事務的查詢要附帶上with(nolock),以利於並發更新。
有些功能模塊不能按照想當然的方式開發，比如產品訪問次數，切不可將這些更新非常頻繁的欄位置於核心表內，明確的做法是將其剝離開來 還有就是切不可經常性將欄位設計成bool類型，這樣會給以後的擴展留出路，即使是男女這種欄位，也建議採用tiny類型
其他還有就是在產品設計的時候充分考慮seo，網站目錄結構清晰可讀，而不是帶著一串串的查詢參數。
對安全要有整體的把握，最好全都是用存儲過程，在項目上線前將資料庫存儲過程全部導出再查找貌似exec的語句，查找是否需要替換成sp_executesql。
另外，如果採用mssql，全文搜索直接用mssql fte就可以，速度和精確度都還是可以的，最重要的是維護和管理開發很簡單。
打折的處理可以按照電信的一次，二次批價功能，如果你做過電信方面的系統。
當然也可以設計得更簡單的一些。 靜態的頁面建議使用CDN加速，以解決網通和電信之間訪問速度的問題；
數據的緩存方面建議考慮用memcache，另外也可以分別在表現層和數據層利用.net中的現存緩存機製作業可；
簡單執行的sql可以不用存儲過程，存儲過程會佔用資料庫伺服器的處理時間，造成死鎖；
mvc建議還是做些CMS的項目上應用，電子商城不是很適合，個人觀點。url上可以做轉義，使url顯示更友好；
資料庫建議建立分布資料庫，這樣可以轉移查詢和大訪問量對資料庫帶來壓力；
圖片可以考慮單獨放在一台伺服器上；1.三層架構
2.使用手寫sql,手寫entity(生成也可),緩存反射綁定(不是緩存數據哦,緩存映射關系),要考慮網站的長期發展還是手寫吧 靈活 性能也好
3.沒有這種問題,商業驅動的,純購物就好了,千萬別搞什麼圈子,wiki
4.純.net的mvc不建議,webform不搞viewstate,不搞服務端控制項(除repeater)再加點mvc的思想已足夠用了
5.不需要緩存數據(除搜索產品部分),要考慮多台伺服器的程序快速部署,config文件會很多,config要序列化緩存
6.當然是先生成好了,參照jd吧,按業務每張圖片對應幾個不同大小的圖
7.據經驗,電子商務網站僅靠中英雙語來達到多語言是不靠譜的(文化 用戶習慣不是簡單的語言切換),如果想真正運營英語的就要重新開發一個版本
8.不搞模式
9.負載均衡(web,db)+ssb非同步處理數據
10.你是業務類型的日誌還是異常日誌? 前台訂單流程上異常日誌不需要了,找個工具錄個腳本不停的跑 保證隨時發現問題發郵件就可以了
11.找第三方搜索組件 類似endeca的
12.負載均衡挺簡單的,初期靠軟體就可以,一切圖片找第三方放cdn,前台網站用到ajax的地方很少,如果用的話jquery 1，一個電子商務網站用戶99.5%的行為時Find
2、對於商品檢索部分，能不用資料庫就不用資料庫（網上切詞等相關的開源平台很多）
3、分布式緩存（Memcached 、Volecity），個人測試volecity 3還是不錯的
4、系統設計時必須要考慮可運營。從這個角度去設計系統
5、對於電子商務網站改動很頻繁，必須考慮架構設計如何適應頻繁的版本更新
6、必須設計一個好的單點登錄系統。
7、建議能不用sqlserver就不用它。
8、對於大型電子商務網站來說，系統的I/O是起決定因素而不是CPU和內存。1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
項目劃分其實不重要，重要的的是你在寫代碼的時候是否能把代碼合理的分到對應的項目里。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
開發效率優先，訪問量大了以後，我相信是有錢投到硬體上的，在你程序寫的不是很爛的情況下，升級硬體遠比優化程序節省成本。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
那就做成自定義控制項啦。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
推薦使用使用webform的,前台使用mvc，對於前台來說使用mvc能更好的提升性能，更方便的更換頁面表現形式。後台界面相對穩定，用webform可以提高開發效率。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
初期建議用hashtable，因為簡單，將來升級到Memcached 。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成縮略圖的好處是節約性能。httpmodle相反，每次瀏覽圖片的時候都會生成新的圖片，伺服器壓力大，建議直接生成。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
多語言建議使用asp.net自帶的資源文件的方式實現，當前語言保存在cookie裡面。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
使用MQ隊列
10.日誌方面,log4net?
log4net只能記錄程序運行日誌，主要目的是用來調試程序的，系統業務操作日誌還你是得自己建一個表來保存。
11.電子商務的全文檢索,這也是個頭疼的問題
lucene，微軟索引服務，sqlserver全文檢索，方案很多的。
12.負載均衡方面,有什麼好的文章推薦碼?
可以看windows 2003 集群方面的文章 1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
目前我也是這樣分的,不過當數據表結構有修改時,會帶動其它層的聯級修改,非常不方便，所以開發之前最好將資料庫設計地完善一點。另外，當網站分成多個以後，其它項目生成的DLL文件要部署到每個網站的bin文件夾里，更新一次都要重新部署，這也是個挺煩人的事，當然可以將DLL部署到GAC里來解決這個問題，不過這樣的話本地調試起來就不太方便了，因為項目一有改動，就要將生成的DLL重新拷貝到GAC里才能看到效果。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
這個我也在考慮。目前我還沒有採用ORM框架，都是在DAL里直接訪問DB的。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
自定義控制項。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
正在學習這一塊。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
現在我用的比較多的是.net自帶的數據緩存。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成好，快一點。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
我沒涉及到這一塊，不過我覺得資源文件應該就是用來處理這個問題的。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
這些都放在邏輯層好了。
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
MSMQ
10.日誌方面,log4net?
目前我是自已寫代碼存在庫里的。
11.電子商務的全文檢索,這也是個頭疼的問題
用lucene.net分詞建索引，再直接從索引庫里搜索，又快又准。
12.負載均衡方面,有什麼好的文章推薦碼?
不清楚了。 這樣的設計要達到新蛋的效果肯定不可能的，新蛋少說幾百台伺服器，不同資料庫之間的發布訂閱鏈路都有幾千條。有復雜的緩存，負載均衡機制。新蛋所有的通訊都是基於WCF的。另外對於這么大型的網站來說，資料庫一刻都不停止，所以讀寫分離也很重要，因為你也不可能讓資料庫停下來進行備份。總歸要做到新蛋這樣的大型電子商務網站，靠你上面畫的這點好像遠遠不夠。
不過關於公共的header,footer,我不建議做成自定義控制項，這個維護起來不方便，稍有變動就要發布dll，麻煩的。
如果你的header和footer不是很大的話，建議採用js+css的方式。然後加上壓縮和cdn緩存，應該效率上能接受。
2、電商APP 運營有哪些重要指標
[核心提示] 想最大化獲取粉絲經濟的價值，一定要有取有舍，特別要抵抗短期利益的誘惑。 編者按：1 年前第一次見呂晉傑是在騰訊開放平台的大會上，當時他在騰訊開放平台上經營歡樂淘，一個電商導購平台。不久前我在《一路上有你》、《快樂大本營》、《非你莫屬》等平台上不斷看到楚楚街這個品牌亮相時，我沒有想到這個 85 後的年輕小伙已經成功轉型。而在此前的很長一段時間里，他閉關不接受任何媒體的采訪，及其低調的保護著楚楚街這個品牌，這一年他離開騰訊開放平台，做了自己的獨立 APP——楚楚街，還在義烏呆了半年，做了一次淘寶皇冠賣家。 呂晉傑卻經歷了中國互聯網 3 個重要的變革期，從個人站長、校內網開放平台到移動互聯網時期，他從本科開始就持續創業，是中國第一波社交應用的開發者，第一批大號粉絲，也是最早做阿里媽媽淘寶客的一批人。 從個人站長時代的 200 萬 UV 到校內網時代積累了 4、5 千萬用戶，到騰訊 qq 空間的 5000 萬粉絲，再到 1 年之內為楚楚街積累 4 千萬用戶，這個「數學+金融」專業的年輕創業者有著對用戶運營的獨特思考。本文是楚楚街CEO呂晉傑自己對用戶的思考。 個人站長時代：讀懂流量邏輯 窺探產品思維。 我是 1986 年出生，2003 年上大學，2004 年在大學里就開始了互聯網創業。這個時候的創業大多都是做個人草根站長。從本科到研一，我做了 4 年個人站長。 個人站長時期鍛煉出的經驗是，一個網站，從域名、虛擬主機、CMS、代碼到運維、SEO，賺錢，這些全部的流程都得由自己一個人搞定。 個人站長根本沒有產品思維，而且由於流量分配機制，決定了個人站長「投機倒把」地以追求流量為主。為了讓百度很容易搜索到你，一個人甚至要做十幾個到幾十個網站，形成一個站群。我做過奧運會宣傳中國的英文網站，電影網站，各種各樣內容。從 qq 群、百度貼吧引來更多流量。每天做到幾十個網站共計 200 萬 UV。 這個過程的最大的缺陷是你沒有辦法專注用戶，因為要把 95% 的精力都花在細節和步驟上，真正的產品可能只有 5% 的精力投入其中。當時 30 萬的個人站長，今天成功轉型的為數不多，除了蔡文勝個別教父級的個人站長，大多數站長由於做的事情太雜，逐漸走向沒落。 現在的互聯網已經不需要這些了，跟用戶相關的產品、運營比較重要。好的產品融資後，用戶自然成長，雲服務也讓企業減少了技術和人力投入。 2008 年，出現了國內第一個開放平台——校內網，「偷菜」這些游戲使好友買賣變得火爆。什麼是開放平台?校內網聚集了幾千萬用戶，有幾千名員工，但這幾千名員工全部投入在支撐的系統架構、研發相冊、論壇等功能。幾千萬用戶需要十萬個不同種類的應用，校內網不可能完成這么多開發，就必須設定一套機制開放給外面的人來做。這就是開放平台，開放平台給第三方用戶，第三方給開放平台提供產品，開放平台向第三方支付人人豆，第三方可以通過人人豆或者通過廣告獲得利益。校內網的幾千員工通過開放平台做了 30 萬人公司做的事情。當時的百度也只有音樂、貼吧等幾個產品。 開放平台的時代開啟，使開發者可以專注產品，因為只要產品做到好，就一定能夠得到傳播。 校內網的粉絲被我承包了，拒絕每月 300 萬 我當時的第一感覺使這是草根站長時代的轉折點，盡管當時大部分個人站長都沒有「轉」過來。 2008 年，我把所有網站全部放棄掉，專門在校內網上做應用，在社交平台上培養產品思維。當時有一個特別大的好處，我還是個學生，身邊都是用戶，直接就可以看到用戶喜歡的是什麼，讀書時也沒有太大壓力，到 2010 年，開發的應用總計已經擁有 4、5 千萬用戶，而當時的校內網總共也就有 4、5 千萬用戶。當時網站前 10 名應用中的 6 個是我用不同的名字做的。這其實是個人站長時代積累下來的經驗，不把雞蛋放到一個籃子里，防止校內網的封殺。 期間我開發的應用有很多，包括一些星座、智商測試，當時校內網上比較火的「人品測試」、「點名」都是我們做的。我在校內網上做的第一款游戲—— 整蠱專家，只做了 3 個月就不做了，因為用戶漲得太快了，一周來 100 多萬用戶，每天 100 萬的訪問量。現在 20 個人做一款游戲，而當時只有我一個人。從早年的虛擬主機到 VPS 再到 Windows 伺服器，技術容量實在上不去了，用戶來了都打不開網頁，訪問量太大。當時沒有雲服務，眼睜睜看著用戶這么多，打不開網頁。這也是我後來一直以來偏愛做應用的原因，一個人頂幾百萬個用戶是沒有問題的。 2011 年，校內網推出了個人公共主頁，我通過開發的應用給主頁導了 1600 萬個粉絲，數量龐大而且非常純潔的粉絲，隨便用一個 2 百萬粉絲的賬號發一條信息，瀏覽量都是 50 萬以上。用 2 百萬粉絲的賬號發一條阿里媽媽的廣告，可以賺 2 萬傭金，這背後意味著給阿里巴巴帶來 40 萬交易額。當時校內網粉絲數量前 6 名是我的，而且甩開第二名很遠。 09 年的時候，每個賬號每天發一條廣告，一個月我能賺 300 萬。但是從個人站長時代走來，我明白每 1 萬 UV 的獲取都是非常難的事，發一個信息就能導來 30、40 萬 UV，這背後的價值是無限的。如果一直發廣告就是殺雞取卵，就會傷害用戶，讓用戶流失。 我決定不賺這 300 萬。 工作一年錯過新浪微博，焉知是福 盡管我肯定自己是一定要創業的，但研究生畢業時我還是想先找一份工作。 當時我的手上有 4、5 千萬用戶，2 千萬粉絲，隨便給網站導點 UV 都沒問題。但當時立馬創業，我可能就會成為一個獨行俠了，個人站長很多都是一個人，他們買房買車，有錢但沒有團隊，而創業是需要團隊的，一個人再牛也比不過一個團隊。 我判斷自己將來還要做一個事業，而剛畢業對什麼都還沒了解，必須要學習正規化的企業文化。我在一家咨詢公司做了一年，作為助理整理了上千人的訪談資料，上到大國企下到小民企，上到大老闆，下到前台。天天寫行業研究報告，培養起行業思維。草根創業學會的是聚焦，而行業思維則是要看看天花板有多高，樹立一個大框架。 就在這一年，2010 年我第一次接觸新浪微博，當時最大的草根粉絲大號有 10 萬粉絲，我在校內網上有 1600 萬粉絲，我做了個實驗，在校內網上邀請大家關注我的新浪微博賬號，一個晚上漲了 2 萬粉絲。 當時算了下，如果我一周如果每個賬號每天都發一條信息，請大家關注我的新浪微博賬號，那麼新浪微博粉絲最多的前 10 名的賬號可能都是我的。但是，我只試過這一條。在學習和新浪微博機遇中，我只能選擇其中之一。 今天看，工作這一年最大的收獲是被動得躲開了新浪微博的危機，如果陷進去就真的陷進去了，自己會被財務指標、漲粉捆綁，完全沒有額外得精力，也可能就錯過了我的下一個機遇——騰訊開放平台。 從一度放棄到交易額超過拍拍 錯過了新浪微博我卻趕上了騰訊開放平台。 四年前，我們今天運營的楚楚街 APP 就注冊了，當時的 chuchujie，每天也能夠達到 100 萬流量。但當時美麗說蘑菇街也做了 1 年了，並沒有顯現出太大優勢。我們怕砸了楚楚街這個品牌，就做了歡樂淘和 9 塊 9 包郵 2 個品牌，專門做選品和運營。僅僅做了半年，雙十一當天就賺了 387 萬傭金，這意味著背後幾千萬的交易額。那個時候一天的交易額比拍拍都高，騰訊對我們進行了 B 輪投資。 只做移動端：押注 90 後 放棄騰訊 4 倍流量 在做導購的半年時間里，我們碰到用戶咨詢最多的問題是：怎麼注冊淘寶?怎麼支付寶轉賬?我們把錢給你們，你們把貨發給我們吧! 這讓我們突然意識到，其實我們在為淘寶拉新用戶。 去年阿里巴巴上市，招股說明書披露淘寶的活躍用戶在 14 年達到 2.7 億，這個數字在 12 年是 2 億。彼時 qq 空間有 7 億活躍用戶，意味著當時 2 億淘寶用戶完全重疊在 qq 空間里。隨便從 qq 空間「抓」一把用戶，七分之五是沒用過淘寶的。而用美麗說的多是有淘寶賬號的用戶，是因為用的不爽，才用美麗說精選細選東西。 其實，淘寶最缺的是騰訊的用戶，或者說是 90 後的用戶。 這背後的原因也很顯而易見。90 後的用戶往往在 4、5 歲時就用起了 qq，有了 qq 空間，到了 23、24 歲，qq 還在用，qq 空間卻已經不用了。10 年前淘寶就成立，10 年前用淘寶的用戶絕對不是 70 後，因為他們在那個時候沒有電腦，10 年前有電腦絕大多數的都是 80 後，80 後在 07、09 逐漸畢業、漲工資、生孩子，淘寶的貨品也伴隨著這代人從 10 年前的雜亂差，到了追求品質——淘品牌，線下大牌，國際品牌，母嬰品牌。 過去 10 年，淘寶的快速增長也和這一代人有關，淘寶為什麼在過去 10 年飛速成長?過去 10 年是 80 後 22 歲-30 歲之間，是收入，消費快速上升的黃金階段。淘寶抓住了 80 後，但最缺的用戶一定是 90 後。 楚楚街被動地抓住了這一波用戶，現在淘寶、京東 20% 的用戶是 90 後，而我們 75% 是 90 後，很多 90 後把人生的第一次網購獻給了我們。 12 年騰訊投了我們，騰訊董事會決定想給我們 4 倍流量，但我們做了個決定不僅不要騰訊的流量，而且全公司放棄騰訊開放平台以及 pc 端的導購業務，只做移動端。跟之前放棄賺 1000 萬的道理一樣，騰訊給四倍流量，馬上要賺錢，但移動端出來後，這個時間點很微妙，早做先天優勢沒多少，晚做就死了。 過去的經驗是做事情必須專注，何不專注於做移動，pc 扔掉，做起來了，其實抓住未來，短期看丟掉一塊肥肉。對未來 2 年 3 年利益非常大，今天美麗說蘑菇街仍放不下。 把用戶習慣培養成移動端，砍掉 50%pc 端並不是砍掉 50%，而是剩下 50 的用戶直接移到 pc 端。這樣公司能夠更專注的做事情，pc 和移動是 2 套體系，而且是未來趨勢看清出來就應該這么做。 在生意蒸蒸日上之際，騰訊投資了我們，而且希望再給我們現有 4 倍的流量。這時我們拒絕了。 我們決定放棄 PC 端，只做移動端，從電商導購網站真正轉型做一個電商平台。13 年上半年很痛苦，到年中技術產品上線後，5、6 月份做了一個宏觀判斷，如果年底到不了 1000 用戶，我們肯定死。因為到了 14 年移動端用戶獲取成本將更高，沒有免費的用戶。幸運的是到了 13 年底，在團隊+騰訊+外部一起努力下，我們攢足了 1000 萬用戶。 做平台意味著要有 2 方，用戶和賣家。做了一個平台用戶太少，商家賣不出去東西，商家就跑了。用戶來了發現沒什麼商家，用戶也跑了。當時的我們用戶太少，商家也不來。 其次，平台和導購有 90% 不一樣，導購只是拉客，平台涉及到選址、物流、裝修、設計、進貨、記賬。我們最缺乏的電商的經驗能力，而且沒有物流和產品能力。 於是，14 年上半年，我拉著一個合夥人去義烏呆了半年。從租地下室倉庫開始，開了一個淘寶店經營居家類用品，從店鋪裝修到一家家拜訪，到買貨賣貨送貨，我自己打了 1 萬多個包，到貼快遞單，聊 5000 個客服，到最後自動化打單，倉庫管理整個流程半年做到一個金冠。 此刻，北京這邊一年找到了 3、4 千萬用戶;加上與合夥人親身體驗了那不足的 90% 的能力。我們對對淘寶、商家和供應商的體系都懂了，回來正式轉型。 15 年 1 月份之前，所有的媒體采訪，我們一律不接待，一個公關稿不發，就是避免讓淘寶注意到，如果半年之前對外公布，勢必會遭到淘寶措手不及的封殺。 我們也用「9 塊 9 包郵」混淆大家的概念，做 9 塊 9 的太多了，這個概念就像超市雞蛋和大米，是賠錢賺吆喝，但你還要買其他的物品。新用戶第一次買 9 塊 9，第二次基本上就買其他的東西了。 我們為什麼要真正轉型做一個電商平台，而且 90 後是我們的目標用戶。首先，看一下淘寶、京東的未來在哪裡?現在全國的網購人群是 3 億多，淘寶和京東占據地差不多了，中國未來潛在 10 億 網路人群，剩下的 7 億就是他們的未來。 剩下的 7 億無非有兩個緯度，一是還沒有智能手機的，比如不是網路用戶變成網路用戶，二是小孩長大。淘寶和京東的農村戰略沒錯，7 億的主體一定在農村，但這其中的 1 億可能是 90 後，而且 90 後一定是這部分用戶的先行者。7 億變成 6 億，再到 5 億，一定是 90 後引領的。 其次，90 後一定會引領未來 5 年的電商格局，接下來 5 年 90 後要經歷平均年齡到 22-28 歲，是工資增長期和人生變化的時段。 淘寶一路走下來，體量已經非常大，阿里巴巴 3 萬員工很難支撐 10 億網民的電商需求，除非淘寶快速擴張員工到 100 萬，但阿里巴巴的組織架構決定這是不可能的，今年的天貓員工已經只出不進。 京東、唯品會、聚美優品以及越來越多的新電商平台一定會分淘寶的蛋糕。
3、電子商務網站一般架構有哪些
1. 電子商務網站的規劃與分析關繫到電子商務的經營效果，盲目的投入時間、人力、資金、經業務搬到網上運行，不但會造成浪費，更會與傳統渠道相沖突，影響客戶對公司的印象。
2. 電子商務網站的設計與開發的主要內容是根據網站的定位，確定網站的內容信息結構，風格基調和功能模塊。運用相關的開發技術和工具進行頁面設計與製作。以及在選定資料庫管理系統平台上進行資料庫的設計與管理
3.電子商務網站的好壞，都必須經過一定的測試來解決。測試的內容包括功能測試、性能測試、安全性測試、穩定性測試、瀏覽器兼容模式測試、連接測試等。進過測試後，就要把網站對外發布出去了。網站發布，簡單的說就是將構成整個網站的所有文件部署到WEB伺服器上，經過簡單的配置發布到互聯網上的過程。
4、電子商務網站一般架構有哪些
1．電子商務的基本概念 電子商務是利用計算機及互聯網開展的各種商務活動。其中電子是手段，商務是目的。是通過網站的商務運作和會員制收費，達到盈利的目的。電子商務包括以下三部分內容：
電子：指信息基礎設施及相關應用系統，其中信息基礎設施包括internet 網路基礎和信息技術，應用系統應包括支持電子商務活動的網站。
商務：指業務內容、流程及規則，這是電子商務網站系統設計的基礎和依據。
信息：指業務活動中的數據，應完整、全面、實時、動態。業務活動所使用的數據也是網站系統資料庫設計的依據。Internet技術、信息技術系統和商務過程的有機集成形成了一個新的商務模型，即電子商務模型。2．電子商務網站的基本架構設計電子商務網站是以商務活動為中心進行的，而網站的盈利一般通過網站的會員制收費進行，網站的盈利點是網站根據網站的商務活動內容確定的，所以網站的基本架構設計既要以商務活動的業務內容、流程、相關規則為基礎，又要兼顧電子商務網站的收費體系。網站基本架構的設計主要根據以下步驟進行：2.1 確定電子商務網站功能定位 確定網站所涉及的商務活動的內容、商務活動的流程。比如我們在進行房產信息網的設計中，首先考慮確定網站發布房產信息的種類，確定了房源信息包括中介所的房源信息和個人的出售、出租信息，網站負責信息的發布和信息的管理。同時在確定了信息發布種類後，確定了信息處理的流程為房源信息輸入、會員資格審核、信息審核，信息發布。2.2 確定網站的收費對象和收費規則在網站所涉及的商務內容確定了的情況下，確定收費的對象和如何進行收費，以此為依據確定網站的欄目。網站欄目的劃分實際上就是系統的功能模塊劃分。在房產網站的系統設計中，確定了網站只對房產中介所進行收費，個人用戶免費，所以網站的主要欄目分為個人專區和中介所專區兩個主要欄目，同時根據功能的逐步擴大，這樣也就基本確定了網站的信息服務內容和方式。2.3 確定網站的欄目的功能在確定了網站的收費項目後，要確定網站的主要欄目和功能，包括網站的管理功能模塊、網站的信息發布方式、網站商務活動的發布以及網站導航欄等。網站的功能欄目的設置和系統的主要功能模塊的劃分是相一致的。網站業務介紹性欄目，應包括內容應包括會員申請流程，收費標准，網站運行規程等，使用戶對網站的服務有一個明確的了解，是擴大網站的會員用戶數量和提高網站的使用率都是必不可少的欄目。網站的導航欄是網站的整體功能的全面介紹，使用戶對網站的功能有一個清晰的了解，也是網站不可缺少的欄目。同時也應有網站運行的相關提示信息，比如在房產網站的設計中，我們在確定了收費對象和主要功能後，確定了網站首頁的主要欄目為中介所專區、個人專區、寫字間專區、新房樓市等欄目，同時加入了上網導航欄目對網站的主要功能進行介紹。 2.4 確定網站的信息流和控制流 在確定了網站的主要功能和商務活動的主要規則後，應該確定網站的信息流圖和控制流圖，作為資料庫設計的基礎。在房產網的設計中，我們根據房產信息發布的功能和所確定的信息審核和控制流程，確定房產網的基本數據流圖為： 實例：一個網站的數據流圖在確定了一個網站的數據流圖和控制流後 ，系統的運行控制流程也就確定下來了。3．網站的後台管理在網站的基本功能和數據流確定後，為了保證網站信息的准確性和有效性，應有完善的後台管理和維護系統，進行相關數據的審核，定期進行資料庫的維護和備份，進行繳費會員資格的管理，有效的保證網站的商務運作。我們在房產信息發布網站的後台管理系統的系統設計中，設計了一套完整的網站後台管理系統，主要功能包括房源信息管理如：房產信息審核、房產信息刪除、房產信息刪除確認；網站運行提示信息的管理，主要是對網站與商務運營有關的信息進行管理，使網站的用戶對網站的運行情況進行管理；網站會員資格的審核，對逾期未繳費的用戶取消會員資格；網站系統管理員許可權管理，對不同的網站系統管理人員進行授權使用不同的後台維護功能。4．網站的資料庫設計在確定了網站的主要商務的業務對象和業務流程後，可以確定了網站的數據流，也就可以進行資料庫設計。 在進行資料庫設計時，同樣和一般的應用系統開發一樣，應該注意信息的完整性和數據的獨立性。我們在房產網站的開發過程中，在資料庫的設計階段，對系統的資料庫按房源的基本信息、中介所信息、個人信息分別進行庫表的設計，同時對系統的維護信息、許可權管理等控制信息設計獨立的庫表，主要的資料庫表為房源信息表、中介所信息表、會員信息表等，這樣可以方便網站的信息輸入、資料庫查詢同時也方便網站後台的資料庫管理和資料庫維護。資料庫表數據的獨立性和數據冗餘直接影響數據的存取效率，影響網站的運行速度，所以在資料庫設計時一定要避免數據的冗餘性，同時要避免長資料庫表的設計。總結：在電子商務網站開發過程中，網站的商業運作模式決定了網站系統設計，一個功能清晰的網站的設計，一定要從網站的系統設計入手。
5、軟體測試都學什麼？
小蝸這里根據行業變化以及企業用人需求整理了一份基於Python的軟體測試學習路線，主要學習以下知識點：
第一階段：專業基礎課程
階段目標：
1. 熟練掌握IT核心技術：編程，資料庫，操作系統，版本控制
2. 能夠熟練運用所學技術搭建各類伺服器環境
3. 深入理解軟體研發過程各種疑難雜症及處理手段
4. 掌握Python編程技術並熟練運用Python進行程序設計
知識點：
1、Web頁面元素，布局，CSS樣式，盒模型，JavaScript程序設計，函數，基礎演算法，正則表達式。
2、資料庫知識，範式，MySQL配置，命令，建庫建表，數據的增刪改查，約束，視圖，存儲過程，函數，觸發器，事務，游標，建模工具深入理解資料庫管理系統通用知識及MySQL資料庫的使用與管理。為軟體測試和測試開發打下基礎。
3、Linux安裝配置，文件目錄操作，VI命令，管理，用戶與許可權，環境部署，Shell編程Linux作為一個主流的伺服器操作系統，是每一個測試開發工程師必須掌握的重點技術，並且能夠熟練運用。
4、Python編程基礎，語法規則，函數，數據類型，PDBC，培養扎實的Python編程基本功，同時對Python核心對象編程有熟練的運用。
5、Python面向對象，異常處理，文件IO，多線程，網路編程，PyQT界面開發，深入理解面向對象編程，異常處理機制，多線程原理，網路協議知識，並熟練運用於項目中。
第二階段：專業核心課程
階段目標：
1. 熟練應用所學知識完成一個標準的軟體測試項目
2. 熟練運用Python完成GUI測試，介面測試和性能測試開發
3. 對測試開發技術體系和實現原理有深入的理解
4. 靈活運用測試開發技術解決項目中的各種問題
知識點：
1、軟體工程，軟體質量，系統測試流程，方法，專業術語，測試用例設計，禪道管理工具，測試報告，缺陷管理理解軟體工程的各類實際問題，理解系統測試的理論、方法與過程，熟練運用測試用例設計方法高效設計測試用例。
2、測試需求分析，測試方案設計，測試用例設計，測試項目實施，缺陷報告與測試報告，深入理解系統測試各個過程和關鍵環節，熟練完成系統測試項目。
3、SikuliX框架，UIAutomation框架，Selenium WebDriver框架，基礎框架，Android應用，Monkey測試，Appium移動端測試框架，UIAutomator2移動端測試框架綜合運用各類應用操作平台，完成各種自動化測試框架的學習和應用，深入理解GUI自動化測試技術及相應框架的測試開發。
4、Python單元測試框架，網路通信協議，HTTP與HTTPS協議，WebService與WebSocket協議，Python的介面測試庫，PostMan與SoapUI介面測試工具通過對代碼級介面測試和協議級介面測試的測試開發實戰，靈活運用Python開發介面測試腳本，熟練運用各類介面測試工具。
5、性能測試原理，指標體系，場景設計，實施過程，JMeter工具應用，BeanShell腳本開發，Python+Locust性能測試框架深入理解性能測試技術體系和方法論，熟練運用JMeter性能測試工具和Locust性能測試框架實施對任意系統的性能測試。
第三階段：綜合實戰項目
階段目標：
1. 將軟體測試和測試開發技術靈活運用於項目中
2. 具備較強的測試開發能力，獨立完成測試開發項目
3. 綜合運用軟體測試技術，滿足企業中高級人才需求
4. 對所學技術有深入的理解並具備獨立解決問題的能力
知識點：
1、測試需求分析，同行評審，測試計劃，測試方案，測試用例，配置管理，持續集成。通過對大型企業級應用系統的測試項目實戰，強化理解系統測試項目的實施過程與技術細節。
2、介面測試設計與實施，回歸測試，冒煙測試，安全性測試，RobotFramework框架應用，UI自動化實戰將各類自動化測試技術結合項目實戰演練，強化對自動化測試技術的運用，同時掌握更多的測試框架。
3、性能測試項目實戰，LoadRunner性能測試工具，總結通過綜合項目實戰，將全套測試技術融入到項目中，強化學習效果和項目經驗。
4、Python原生測試框架開發，包括Monkey，UI，圖像識別，雲測試平台，HTML測試報告，持續集成，KDT關鍵字驅動框架開發等原生技術實現通過大量的Python原生代碼開發，深入理解自動化測試開發技術的底層實現原理，完全拋棄對工具的依賴，做到真正的測試開發技術。
5、基於測試框架的設計思路和實現手段，自主實現一套測試框架能夠獨立完成一套自動化測試框架，並能夠直接用於實際項目中。
6、持續集成與Jenkins，安全性測試原理與工具，Python爬蟲開發與Scrapy框架，提升軟體測試其它類技術，增強知識面，提升競爭力，助力職業發展。
補充知識
1、 演算法進階，圖像處理，視頻處理，加密解密，壓縮演算法。
2、 UML統一建模語言、五種圖、類圖、類圖詳解、用例圖、時序圖。
3、Dubbo分布式開發框架，Oracle關系型資料庫管理系統，MongoDB非關系型資料庫管理系統。
4、 大數據開發框架Hadoop/MapRece/Spark。
5、 Android與iOS的原生應用開發與WebApp開發。
6、OpenCV圖像處理框架、TensorFlow深度學習框架，Lucene全文搜索引擎與中文分詞框架Ik-Analyzer，視頻處理演算法與框架等。
Python測試開發學習路線思維導圖
6、軟體測試主要是學什麼呢？
優就業軟體測試課程內容剛剛迭代升級，新增移動端測試，包括App兼容性測試，7*24小時穩定性測試，功耗性能測試，UI測試，交互測試等，課程主要學習的內容有：
1、功能測試
主要包括計算機基礎、軟體測試核心理論、Linux、資料庫，學習目標是掌握軟體測試核心理論，結合Linux、資料庫等可實現移動端、web端的功能測試。學完可勝任功能測試工程師的職位。
2、自動化測試
主要學習Python、自動化測試入門、Web自動化測試、App自動化測試，培養方向是掌握自動化測試各類元素定位和操作方法;掌握自動化測試框架unittest使用和斷言方法;掌握自動生成測試報告的方法。學完可勝任自動化測試測試工程師的職位。
3、介面測試
主要學習介面測試核心理論、介面測試工具Jmeter、介面測試工具Postman、抓包工具Fiddler、Jenkins持續集成、Python實現介面測試。
4、性能測試
性能測試理論、虛擬腳本生成器操作、場景設計、報告生成和分析，學習目標是掌握性能測試理論知識，能運用性能測試工具LoadRunner和Jmeter做性能測試，測試出系統的性能情況。
7、電子商務架構師是什麼
電子商務架構師在整個電子商務開發過程中都起著重要的作用，並隨著開發進程的推進而其職責或關注點不斷地變化，在需求階段，架構師主要負責理解和管理非功能性系統需求，比如軟體的可維護性、性能、復用性、可靠性、有效性和可測試性等等，此外，架構師還要經常審查和客戶及市場人員所提出的需求，確認開發團隊所提出的設計；在需求越來越明確後，架構師的關注點開始轉移到組織開發團隊成員和開發過程定義上；在軟體設計階段，架構師負責對整個軟體體系結構、關鍵構件、介面和開發政策的設計；在編碼階段，架構師則成為詳細設計者和代碼編寫者的顧問，並且經常性地要舉行一些技術研討會、技術培訓班等；隨著軟體開始測試、集成和交付，集成和測試支持將成為軟體架構師的工作重點；在軟體維護開始時，軟體架構師就開始為下一版本的產品是否應該增加新的功能模塊進行決策。
必備條件
架構師的形成是在實踐中鍛煉起來的，需要相當的技術水平和多年的實際經驗，而並非上了幾次培訓班，讀了幾本書就可以成功的。 顯而易見，在軟體開發過程中，一個優秀軟體架構師的重要性是不應低估的。那麼如何成為優秀的軟體架構師呢？
領導能力與團隊協作技能，軟體架構師必須是一個得到承認的技術領導，能在關鍵時候對技術的選擇作出及時、有效的決定。
- 具有很強的溝通能力，其時這一點好象什麼角色都最好具備，軟體架構師需要與各路人馬經常打交道，客戶、市場人員、開發人員、測試人員、項目經理、網路管理員、資料庫工程師等等，而且在很多角色之間還要起溝通者的作用。在技術能力方面，軟體架構師最重要也是最需求掌握的知識是構件通信機制方面的知識，比如遠程過程調用、JAVARMI、CORBA、COM/DCOM、各種標準的通信協議、網路服務、面對對象資料庫、關系資料庫等等，另外，架構師應時刻注意新軟體設計和開發方面的發展情況，並不斷探索更有效的新方法。開發語言、設計模式和開發平台不斷很快地升級，軟體架構師需要吸收這些新技術新知識，並將它們用於軟體系統開發工作中。當然，行業的業務知識對軟體架構師也是很重要的，有助於設計
- 出一個滿足客戶需求的體系結構，優秀的軟體架構師常常因為要盡快獲得對行業業務的理解而必須快速學習並且進行敏銳的觀察。
上面的描述是枯燥乏味的，但作為一個架構師，在整個軟體系統的開發過程中是樂趣無窮的，因為這個角色很具有挑戰性，有時需要左右逢源八面玲瓏，有時又需要果斷堅定不留情面。在國內，較少軟體企業擁有獨立的架構師，通常一個軟體高手身兼數職，既是項目經理，又是軟體架構師，還是軟體開發者，有時還要客串一個測試人員，這對軟體的開發周期和產品質量是不利的，有時一個人的觀點立場是很片面的，而且繁重的工作、沉重的壓力會影響一個人的情緒，情緒會影響決策，決策影響結果，所以值得我們三思而後行。
構架師不是通過理論學習可以搞出來的，不過不學習相關知識那肯定是不行的。總結構架師自我培養過程大致如下。
1、構架師胚胎（程序員）
學習的知識是語言基礎、設計基礎、通信基礎等，應該在大學完成，內容包括java、c、c 、uml、RUP、XML、socket通信（通信協議）——學習搭建應用系統所必須的原材料。
2、構架師萌芽（高級程序員）
學習分布式系統、組建等內容，可以在大學或第一年工作時間接觸，包括分布式系統原理、ejb、corba、com/com 、webservice（研究生可以研究網路計算機、高性能並發處理等內容）
3、構架師幼苗（設計師）
應該在掌握上述基礎之上，結合實際項目經驗，透徹領會應用設計模式，內容包括設計模式（c 版本、java版本）、ejb設計模式、J2EE構架、UDDI、軟體設計模式等。在此期間，最好能夠了解軟體工程在實際項目中的應用以及小組開發、團隊管理。
4、軟體構架師的正是成型在於機遇、個人努力和天賦軟體構架師其實是一種職位，但一個程序員在充分掌握軟構架師所需的基本技能後，如何得到這樣的機會、如何利用所掌握的技能進行應用的合理構架、如何不斷的抽象和歸納自己的構架模式、如何深入行業成為能夠勝任分析、構架為一體的精英人才這可不是每個人都能夠遇上的餡餅……
基本認證
眾所周知，Java是當前最熱門的軟體開發語言，它具有跨平台、面向對象、強大的網路功能等特性。你不僅能在電腦上使用Java程序，還能在手機、PDA、家用電器上使用Java程序，甚至舉世矚目的火星車也全部採用Java技術。Java在不到10年時間內已經變成最流行的軟體開發平台，最新的企業級Java 2.0版本（簡稱：J2EE）也成為企業應用系統上最受歡迎的開發標准。
事實上，全世界范圍內的J2EE架構師都是緊缺的人才，只是中國更加明顯而已。在英國，有經驗的J2EE架構師，目前平均年薪已經飆漲到七萬至十萬英鎊。全球著名的電子商務平台提供商SilverStream軟體公司的技術服務總監Mark Ashton對J2EE人才的短缺深有感受，他表示許多求職者的履歷表上都有把J2EE列進去，但是仔細查看或是面試之後就會發現大多數人只是聽過J2EE，並沒有真正用過這些技術。信息產業部電子信息產品管理司副司長丁文武近期也表示，目前我國Java人才還遠遠不夠，至少短缺20萬。特別是隨著大量軟體外包業務進入中國，許多外資或中資軟體企業也開始面臨著高級Java人才奇缺的問題，尤其是熟悉J2EE又能掌握一門相應外語的人才成為了眾多大公司爭搶的對象。
作為Java的發明者和Java開發標準的主要制定者——美國Sun公司對從事Java開發的技術人員提供了三級認證體系，即初級的程序員認證（SCJP）、中級的開發員認證（SCJD和SCWD）和高級的架構師認證（SCEA）。這也是軟體行業中最權威的國際認證之一。目前國內已經有針對美國Sun公司認證體系的培訓，但絕大多數主要針對初級的程序員認證，只有極少數專業培訓機構能夠提供三層完整培訓。
具備能力折疊編輯本段
一般來講，系統架構師應該擁有以下幾方面的能力：
1：具備 8 年以上軟體行業工作經驗；
2：具備 4 年以上 C/S 或 B/S 體系結構軟體產品開發及架構和設計經驗；
3：具備 3 年以上的代碼編寫工作經驗；
4：具備豐富的大中型開發項目的總體規劃、方案設計及技術隊伍管理經驗；
5：對相關的技術標准有深刻的認識，對軟體工程標准規范有良好的把握；
6：對 .Net/JAVA 技術及整個解決方案有深刻的理解及熟練的應用，並且精通WebService/J2EE 架構和設計模式，並在此基礎上設計產品框架；
7：具有面向對象分析、設計、開發能力(OOA、OOD、OOP)，精通 UML 和 ROSE，熟練使用 Rational Rose、PowerDesigner 等工具進行設計開發；
8：精通大型資料庫如 Oracle、Sql Server 等的開發；
9：對計算機系統、網路和安全、應用系統架構等有全面的認識，熟悉項目管理理論，並有實踐基礎；
10：在應用系統開發平台和項目管理上有深厚的基礎，有大中型應用系統開發和實施的成功案例；
11：良好的團隊意識和協作精神，有較強的內外溝通能力。
架構師的隱形職責
1、為技術部門提供技術支持
2、在最需要的時刻去攻克最艱巨的技術壁壘
3、幕後項目經理
4、業務部門與技術部門間的粘合劑
5、業務發展的催化劑
8、電子商務系統設計
電子商務系統是互聯網時代計算機系統的主流應用，是集成了數據管理、事務處理、業務流程重組、系統安全管理等技術的復雜系統。很多企業管理者和信息系統技術負責人在被電子商務系統的廣闊前景所吸引的同時，亦為不知如何開展電子商務系統的建設而煩惱。系統集成商參與項目開發的困難更多：用戶需求不準確、經常變化，開發人員與業務人員溝通困難、誤差極大。最後上網工程變成了網頁設計大賽，花費了大量人力物力建造的網站並沒有為企業帶來預期中的收益，反而變成了一個擺設，甚至因為要不斷投入維護費用而成了企業的負擔。 本文著重討論電子商務系統工程中系統需求分析和系統概要設計的基本方法，向項目經理和技術負責人介紹如何組織電子商務項目的開展。事實上電子商務系統一方面是一個相當復雜的工程，需要科學的系統規劃和項目管理，另一方面電子商務系統也只不過是一種應用計算機的系統工程，雖然涉及的技術內容和業務因素較多，但只要遵循合理的系統工程實施方法進行，仍然可以順利地完成電子商務系統的建設。 電子商務技術可能目前世界上最令人眼花暸亂的技術領域，新名詞、新技術、新術語每天都在出現，如何建設電子商務系統，似乎有無數種可能，令人無所適從，不知如何作出正確的決策。技術本身並不能為企業帶來效益，只有合理應用技術建造的系統才能幫助企業解決業務運作中的問題，幫助企業發展業務，所以設計電子商務系統時必須堅持一個原則：企業的需求是目的，任何技術都只是實現需求的手段，建設電子商務系統不是為了應用某項新技術，而是為了解決企業的實際問題。只有堅持這個原則才能避免常見的失誤：採用了很多不成熟或者復雜的技術，工程費用超標，項目進度無法保證，應用效果未如理想等等。電子商務系統的目標可以用以下幾個問題來總結。 應用環境：系統將為哪些用戶服務？他們使用什麼平台，如何訪問企業的電子商務系統？ 系統功能：系統為用戶提供了什麼服務？哪些是已經有的，哪些要修改，哪些要重新開發？ 數據資源：為了實現這些服務功能，系統將使用哪些數據？數據量多大，如何存儲？ 安全管理：系統的安全性如何保證？系統管理如何實施？其中系統功能是范圍最廣泛的問題，從最早的信息發布到現在很流行的B2C，B2B，ASP等都是系統功能的一種，按實現這些功能的技術核心可以分為三類： 1 信息共享與數據交換
數據存儲與數據通訊技術是實現這類功能的核心技術，這類系統幫助用戶通過電子郵件、搜索引擎、數據發布技術等高效地獲得信息，提高數據交換的速度與信息共享的效率。 信息共享型的電子商務系統可以降低企業內部由於信息溝通不靈而帶來的損耗，減少日常工作的文書往來，提高工作效率，更有效地管理企業內的信息使用情況。 2 電子商務交易
以電子化的方式實現商務交易過程中的每一個步驟，能適應業務的快速發展而變化是實現這類系統的關鍵，電子商務交易系統是目前最具挑戰性的領域，技術核心是應用系統開發能力與事務處理技術，其中也包括與金融系統介面進行網上支持的SET及相關技術，目前的B2C，B2B即屬於這一類系統。 電子商務交易系統是現代企業在互聯網時代擴展新市場的重要手段，設計良好的交易系統能使企業一天24小時不停地運轉，為客戶提供優良的服務。如果能將企業核心業務系統與互聯網系統有機地集成起來，就能大大地擴展企業的運作范圍，降低經營成本和銷售成本。 3 互聯網伺服器上的應用服務
擴展互聯網伺服器的服務能力，定製滿足客戶需求的應用服務，其內容可能包含了所有電子商務系統的功能，JAVA技術與事務處理技術是這類系統的技術核心。這類系統通常指企業級的門戶網站或ASP，由於其極高的處理負載，還需要提供額外的集群技術、性能管理等復雜的技術支持。 這類系統或者是把原有的企業核心業務系統與互聯網伺服器集成起來，或者是在互聯網伺服器上開發功能完善的應用服務系統。訪問這類互聯網伺服器的客戶能得到自動更新的最新數據，獲得定製化的自助服務。訪問這類系統的客戶數極多，因此要求具有較好的可擴展能力，性能不會受客戶連接數變化的影響，一直保持良好的狀態，所以要採用連接管理技術、事務管理與資源協調等復雜的技術。 本文分三大部分，分別介紹系統需求分析與系統設計的組織方法，以及開展功能檢驗與性能測試的過程，著重介紹基本原則，並不泛及特定相關技術的細節。至於系統實施階段所採用的技術與方法，由於電子商務系統的復雜性、新技術層出不窮，實在不是用一篇文章甚至一兩本書所能涵蓋的。 系統需求分析 系統需求分析是為了系統開發人員准確地理解業務部門的目標，制定合適的實施方案，系統需求對系統實施的重要性不但應該反復強調，還應該避免收集系統需求過程中常見的幾個誤區： 1 系統需求分析不是一次性的工作，而是一個反復遞進的過程，隨著電子商務應用系統的推廣，業務部門會提出新的需求，或者改變原來的業務需求。這是允許的，而且是正常的，技術部門不能拒絕業務部門提出的新需求，而應積極配合，對原有的實施方案作相應的改變。
2 系統需求的根源是業務部門運作的需求，而不是技術部門為了實現某種先進技術而提出的需求。系統方案不能因為出現了某項新技術而作改變，畢竟，使用新技術只是手段，支持企業的商業運作才是最終目的。
3 系統需求不僅限於業務需求，還包括了客觀條件的各種限制，如項目進度的要求、與已有系統兼容的要求（如企業的所有核心數據都已經存儲在Sybase資料庫中、或者企業的舊系統留下幾千台終端必須加以利用）或其他政策法規的限制（如商業系統中使用的密碼系統必須經過政府有關部門的認證）。制定應用系統的實施方案時應把這些因素考慮在內。
收集系統需求的主要途徑是系統分析人員與最終用戶通過交談發掘搣真正攠的系統需求，獲得用戶的認同，在業務部門的幫助下准確地認識業務環境（這一點是大多數技術人員最缺乏的），收集足夠完整的信息，完成一系列文檔作為確認本階段工作的檢查標記，並作為進行下一步工作的基礎。
哪么什麼才是搣真正攠准確的系統需求，當一個客戶向系統分析人員提出要求：搣我們要建立一個網上商城，讓我們公司的客戶可以在網上直接下訂單攠，這是一個絕對真實的要求，但並不一定是一個准確的系統需求，或者說這並不一定是最適合該企業實際需求的目標。因為客戶在提出要求時，一般已經對電子商務有了一些先入為主的認識，認為電子商務就是這樣的，或者只能是這樣的，又或者同行和競爭者已經這樣做了，所以我們也要這樣做。實際上他們所真正需要的，可能比這個要求多，可能比這個要求少，甚至完全是另一個系統。這時系統分析人員就要耐心地發掘客戶的實際需求，通常是提出這樣的問題：
您希望這套電子商務應用建立起來後，能為您的企業達到以下這些目標中的哪些呢？哪些目標是您最希望達到的，您認為您的企業目前在這些方面存在什麼主要問題，您希望電子商務系統能在多大程度上解決這些問題呢？
增加客戶數量 降低企業運營成本或提高營業額
提升公司的總體形象
加快產品推向市場的速度
使企業比同行更具競爭力
縮短新產品的開發周期
改善庫存管理和采購流程管理的效率
改善企業與代理商之間的合作關系
提高客戶滿意度和客戶服務的質量
提高本企業員工的合作溝通效率
幫助企業拓展新的市場這樣的談話最好是在系統分析人員和企業的業務負責人之間進行，而不和企業的電腦部門技術負責人，只有這樣才能發掘出系統真正的需求。系統分析人員通常會從企業負責人那裡得到一些與電子商務技術完全無關的情況，例如搣客戶抱怨我們的交貨期不準時攠、搣我們的企業太大了，各部門間的合作溝通很成問題，總是左手不知道右手在做什麼攠等。這樣的交談能幫助系統分析人員准確地為電子商務系統定位，規定其功能邊界。
企業的負責人通常會更多地著眼於總體的業務規劃，負責需求分析的系統分析人員和項目經理應利用這個機會，向企業管理人員詳細地解釋幾類電子商務系統的功能和應用，啟發他們更深入地發掘企業的需求，以實踐經驗和成功案例向他們說明企業電子商務系統的預期目標，幫助他們樹立正確的期望值。多數企業都是第一次實施電子商務系統，且由於媒體的大肆宣揚等外界因素的影響,可能對系統的預期效果產生不切實際的期望，系統分析人員在需求分析階段就要准確地掌握和調整客戶的心理期望。客戶的期望值也是系統需求的一個重要因素，直接影響系統完成後的實施效果。
客戶的態度和技術水平是影響系統設計者作出方案的重要因素，也是系統需求的一部分，系統需求分析階段要和客戶一起作出充分的交流和評估。客戶的態度指企業決策者對新技術的接受程度以及願意承受風險的程度，電子商務領域的新技術層出不窮，成熟技術的功能比不上新技術，但風險卻較低，企業決策者在這方面的態度影響系統設計者設計方案時的技術選擇，如果企業決策者選擇較先進的新技術，系統分析人員有責任提醒他採用新技術可能面臨的風險：失敗的可能性較高，項目進度和開發成本可能超出預期。切勿投客戶所好，隱瞞新技術背後的不利因素。企業決策者在選擇系統集成商時也應小心，集成商的技術水平不是由掌握新技術的程度所決定，而是由他們運用技術解決實際問題的水平所反映。
中國的大多數大型企業都有專門的計算機部門，電子商務系統建成後維護管理甚至二次開發的工作都將由他們負責，方案設計時也應把客戶方技術人員的知識基礎和專業訓練程度考慮在內。系統需求分析階段最好對客戶方技術人員作一次全面的評估，考察他們對與電子商務系統相關的技術領域的掌握程度，評估的內容有：互聯網伺服器，對象技術，JAVA，應用開發工具，資料庫技術，事務處理技術，安全技術以及對工業標準的認識程度。
系統分析人員要把這些分散的需求匯總成系統的目標，製成初步系統概要需求書，准確而完整地描述企業的總體需求，再次強調系統的預期目標，並獲得企業負責人的認同，再在此基礎上作系統的初步設計。
系統需求分析的工作並未就此結束，反而才剛剛開始。項目經理應作一些准備工作，召集第一次項目會議，會議的參加者包括客戶方的業務和技術負責人，以及項目建造方的項目經理，會議的主要目的是進一步確認和細化系統概要需求書中列出的需求，確定系統建造的方向。這些會議應原則上達成下列這些目標： 1.詳細討論當前環境的情況和系統需求。2.檢討目前正在使用的應用系統，明確列出需要解決的問題。3.在適當的時候交換各自對電子商務系統所持的思路與觀點，創造較易達成共識的認知基礎。4.確定系統的主要目標，當系統需求的范圍比較廣泛，系統目標也可分為短期目標和遠期目標。5.列出為保證系統順利而要解決的主要問題，劃出最突出、最緊迫的問題，爭取客戶方的合作，在系統開始實施前即加以解決。6.向客戶解釋實施系統過程中使用的核心技術和方案的總體思路。7.基於會上達成的共識，制定各人的行動計劃表。這樣的一個會議不可能在一兩個小時內完成，可能需要幾天的時間，甚至在不同的場合下以不同的形式組織，如方案展示會、討論會、現場參觀等。在條件許可的情況下，組織項目會議成員參觀一些類似的電子商務系統，作為背景參考資料，引導項目會議成員參考成功的電子商務系統的實施經驗，對會議的成功有很大幫助。IBM在全世界各地幫助實施電子商務系統的經驗表明，這樣的項目會議對項目的成功有極其重要的意義。項目會議上技術人員與業務人員面對面地交流，節省了大量時間，技術人員能更好地理解業務人員的需求，作出切合實際的方案設計，業務人員也能更好地了解技術手段的限制，雙方的溝通還可以促進企業的業務流程向更合理、更適合計算機管理的方向改進。
實際運作中，參與項目會議的管理人員的時間相當寶貴，把所有人集中起來的機會不多，項目會議的召集人不能簡單地約定一個時間就召開會議，應該在召開會議前作認真的准備。准備工作主要有以下這些：1.確定客戶方的與會者名單，和每個與會者單獨交談，說明會議的目的，聽取他們的意見收集更細致的需求。客戶方與會者人數以四至六人為宜，太多了溝通效率就會下降。2.確定開發方的與會者名單，開發方的與會者人數以四人左右為宜，主要是項目負責人、系統設計員、開發經理和技術負責人，確定會議上討論的題目，為每個題目指定責任人向客戶說明。雙方與會總人數不宜超過十二人。3.准備需求分析文檔作為討論的基礎，這些文檔主要的內容是：
目標系統概述：目標系統的主要功能描述和運作方式。
* 系統結構：當前系統的邏輯及物理結構，正在運行的軟體及其配置圖。
* 資料庫結構：描述企業核心數據的結構，確定哪些數據將開放到互聯網伺服器上，互聯網用戶訪問數據的方式與范圍。
* 網路環境：當前系統的網路拓撲結構圖，目標系統的網路結構圖，以及網路上採用的工業標准如通訊協議、命名規則等。
* 安全性要求： 企業系統當前使用的安全管理方式，以及為適應電子商務系統的運行應作出哪些安全管理方面的改進。
* 性能要求：系統性能受很多因素的影響，性能要求分析把事務流程分解，針對每一環節討論性能要求，充分討論制約性能的不利因素，以及保證性能要求的技術手段。
系統組織結構圖：企業的人事組織結構和業務流程圖，列出為了保證電子商務系統順利運行而配置的組織結構，及每個崗位的技術素質要求。4.會議召開前公布會議的主題，以及與會者名單，附上每個人的背景材料如職位、在項目中的角色等。總之，會議前訂立明確的主題和充分的准備（包括文檔准備和會前的單獨溝通）是會議成功的基礎，作為會議召集人，要在會上以自已的技術基礎與行業知識作出方向性的指導，控制時間，及時制止會上一些不能在短期內得出結論的討論。會議的重點應放在分析系統的現狀與需求，避免過早地引入特定的技術手段，以免提前給方案的設計設下局限。系統現狀的分析除了總結與回顧在第一階段所作的系統需求的結果，還可以具體地對現有環境作技術性的分析。
系統環境的技術性分析主要有以下內容：
* 網路環境的分析：網路拓撲結構分析，當前系統的網路結構，網路上的伺服器配置等。網路流量需求分析，分析當前網路帶寬是否能滿足新系統的要求。網路系統的安全體系及安全管理策略，電子商務系統是比傳統的企業網更開放的系統，安全性要求更嚴格。
* 應用環境的分析：當前系統的軟體配置及版本，應用程序的運行模式（運行平台、是否需要實時訪問和聯機事務處理等）。資料庫結構，應用系統的核心數據模式。用戶熟悉的應用開發方式和熟練掌握的開發工具，用戶的經驗可能是寶貴的資源，能加快系統開發的進度和保證系統使用的效果，因為無需重新培訓而節省成本、降低風險；也可能是採用新技術的重大阻礙，由於習慣性心理而抗拒新的開發工具和應用運行方式，即使投入大量資源重新培訓，仍然要冒很大風險，系統維護人員可能由於不熟練而發生人為失誤，造成運行故障。這種情況在中國企業中尤其普遍，系統設計人員要以非常謹慎的態度來對待。
* 客戶運行環境的分析：電子商務系統的客戶是互聯網上使用瀏覽器或其他設備的客戶，不同於傳統的企業內部網中所有客戶運行環境都是預定定製的固定環境，系統需求列出電子商務系統支持的客戶環境要求，如瀏覽器類型，是否要支持JAVA，是否支持上網手機等。
* 其他特殊需求，如客戶的系統一定要採用Linux平台，或者有特殊的多國語言字元支持問題等。
經過詳細的分析後，項目會議最可能的結果就是聽到一大堆意見和要求。一個可控制進度與預算的項目不可能達成不受控制地產生的要求，分出輕重緩急才能簡單直接地解決問題。項目負責人先取得與會者的認同，目標太多不能在一個項目內完成，請大家先選出要在當前項目內完成的目標，然後評估這些目標的重要性。如果意見不能統一，被列為很重要的目標仍然很多，就要重新篩選這些目標。對於最後列出的目標，再次徵求大家的意見，確認這些目標已經包含了目標系統的基本功能，沒有重大的錯誤和遺漏。系統設計者對被列為很重要的目標和要求應特別重視，它們是影響系統方案的主要因素。第一次項目會議的成果是詳細而明確的系統需求，系統設計人員根據系統需求和目標進行詳細的方案設計。
9、國內有哪些做社交電商平台app的？
社交電商近兩年火得一塌糊塗，做的最大的就是拼XX了，用戶多，體量大......然後新出的有臻享家什麼的，跟其他不一樣的是它是做跨境的，都是進口商品，可以做分享返利啊什麼的。