高性能電子商務平台構建pdf

A. 電子商務網站一般架構有哪些

大型電子商務網站架構，摘抄 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緩存，應該效率上能接受。

B. 電子商務網站從建立到注冊到運營的全過程

你建立網站的目地是什麼，運營什麼。如果你有足夠的資金，應該首先找一些懂的人論證一下，看一下你的想法是否可行。注冊運營是一整套不是幾句話就能說清楚的，如果自己運營網站就必須要有自己的技術團隊，所以建站不是問題，關鍵是你建了網站，干什麼？把這個問題搞清楚了在找人咨詢？

一個健全的電子商務商城或運營公司
管理團隊：這兒提醒大家一下，千萬不要讓人力資源的匱乏而導致項目的擱淺，那樣會喪失掉很多機會，耽誤整體運營。

網站團隊組織如下：（參考編制）

技術：（美工、程序）

1、網站設計：

前台、架構、目錄、雜志、DM單等設計人員（1～3人）

2、產品資料設計人員，即商品的照片及文字介紹、風格等。（1～3人）

3、網站開發工程師、技術輔助人員（1～4人）

4、伺服器維護人員（1人）

5、網管（區域網維護）（1人）

推廣：（編輯、推廣）

1、市場推廣（行業廣告維護專員）（2人）

2、在線推廣、維護（社區推廣）（2人）

3、網站編輯、（內部咨詢撰寫、協助軟文推廣）（1～4人）

4、活動策劃（1～2人）

運營經理（1人）或運營助理（1～2人）

客服：（電話客服及在線客服）

1、呼叫中心人員（1～6人）

2、在線客服問題處理人員（1～4人）（網上的、電話的）

產品：（產品采購）

1、貨源采購人員（按產品品類進行劃分配備：大家電、小家電、數碼、服裝、健康、美容、日用百貨）

訂單：（錄入）

1、訂單管理人員（1～2人）

2、信息管理人員（1人）

物流：（倉儲管理及物流配送）

1、倉儲管理

2、撿貨管理

3、物流管理

4、配送、移動支付設備和信息系統等

財務：（成本管理、利潤核算）

關於以上團隊的設置，不必照搬，由於項目和公司的情況不同，因此，人員配備及部門和職位的安排都會不同，比如運營經理和助理就可靈活配置，而物流和財務有的公司是有總經辦管理，財務獨立，因此配備人員完全根據需要而定。網管呢，如果公司電腦少也可以由程序兼了，同樣的，伺服器的維護和搭建有時也是程序員的工作，靈活掌握就行。不過，基本人員要滿足，即：程序、美工、推廣、編輯、否則項目是無法運營。

現在團隊的人員建設很重要，由於人員素質參差不齊，而且，現在80～85後的「孩子」們雖談不上都是憤青兒，但普遍不太穩定，很多時候願意「玩兒性格」工作情緒上不穩定因素太多造成項目實施起來的不確定因素，遇到這種情況也是不能著急，可以曉之以理，動之以情，灌輸以公司理念及人生態度等慢慢培養。切勿急躁，否則事倍功半。

看看美工：（配色、CSS+Div是重點）

1、最好是學美術的、有過行業經驗，重點在網站配色上有自己的風格，因為現在是互聯網經濟，賺眼球兒靠什麼，靠樣子，也就是顏色和風格，美工在這一點上非常重要。面試時可以多做些題目。如：flash、廣告條等。可以命題或自由選題以便考察美工對於基本工作及臨時緊急情況下的處理。

2、關於軟體當然是會的越多越好，photoshop就不用說了，像網頁三劍客這類的都要精通，最好對於Adobe的Painter 、Reader、Idesign、Illus等熟知並精通，會為未來的視覺建設打下好基礎。

注意：最好不要找一瓶子不滿、半瓶子咣的夾生飯人才，說不會吧，又會點，但又不精通，在實際操作中，這樣的人才是無法實現項目的准確性的，談及不到任何的執行力及效率。

看看程序：（語言+經驗是重點）

1、根據網站建設的語言尋找工程師，一定要在該語言上精通並有過行業經驗，最好經歷過大項目1～3年。

理想配置：1～2名工程師+3～4名程序維護員組成一個技術團隊。

2、程序開發的經驗尤其重要，主要是經歷過項目開發、改版等類似的項目，由於目前的應屆畢業生較多，大多在經驗上不足，組織技術團隊，最好採用有經驗的工程師搭配程序員的形式。即可滿足項目需要，又可以為將來做准備。

看看編輯：（文字功底+媒體是重點）

1、網路媒體和傳統媒體有區別，前者更加靈活，多變而且自由度更強，更講究信息的效率，因此，編輯要有一定的文字功底並對於圖片的處理有一定經驗。

2、最好從事過傳統媒體工作，有一定社會資源，對信息敏感，善於對文章進行總結和歸納並從中找出自己的特點。這類人才大多是學習中文或新聞專業的。

看看推廣：（思路+執行是重點）

1、推廣人員比較靈活，有時和編輯是緊密聯系的，學過市場營銷，最好有過市場經驗，重點在於活動經驗，也就是確實參與過某項目活動的推廣工作，了解流程，並且對於推廣的思路清楚。要善於想像，敢於嘗試。

2、想到就要做到，執行對於推廣是非常重要的，往往想法只是個開始，在執行中還會出現很多細枝末節的事情，要把握好。推廣人員一般在線上或在線下進行實際工作，要注意他們的性格是否有激情，是否善於溝通並可以迅速的與人打成一片並達成共識。

3、推廣即社交的一種方式。

今次聊了網站班子的搭建，希望可以給朋友們幫助，也希望共同探討，畢竟，巧媳婦難為無米之炊，僅憑一人之力再有宏韜偉略也只能是孤掌難鳴，以上說的，在實際運營中都會遇到，筆者認為，既然要做好團隊建設就一定要親歷親為，總監不是監管，也不是監督，不能從字面去賦予這個職位特性，要真正起到一個執行者和決策人的作用。從自己的團多做起，這是第一步。

C. 電子商務網站伺服器需要什麼配置

電子商務網站的伺服器需要企業級高性能的機型。商城網站因為屬於在線交易類型的性質，所以在線人數較多，安全性、穩定性、速度都有要求的。

這類網站一般圖片都比較多且大尺寸。伺服器建議用 2核4G內存了。

帶寬也用3M以上，1M帶寬這樣的訪問會打開慢的。

看需求了，要看網站的規模，網站的日均流量等等來選擇的，如果是前期的小站，或者流量不會集中很高的企業站，就不需要很高配置的伺服器了，一般1核2g 1m的就夠用

首先得弄明白自己用伺服器用來干什麼放網站、應用運行或者是用來搭建放游戲等，都有一個自己的用途，弄明白用伺服器是用來幹嘛的，就可以很明確的知道自己需要的是哪種類型的伺服器

嘗試根據下面四個問題來評估自己的需求：

1. 伺服器運行什麼應用？

2. 需要支持多少用戶訪問？

3. 需要多大空間來存儲數據？

4. 我的業務有多重要？

從你的需求來看，國內選擇那幾個比較大的商家合適，至於名字和具體配置選擇也是一門學問，老魏會幫助你提供參考意見。

D. 電子商務系統設計

電子商務系統是互聯網時代計算機系統的主流應用，是集成了數據管理、事務處理、業務流程重組、系統安全管理等技術的復雜系統。很多企業管理者和信息系統技術負責人在被電子商務系統的廣闊前景所吸引的同時，亦為不知如何開展電子商務系統的建設而煩惱。系統集成商參與項目開發的困難更多：用戶需求不準確、經常變化，開發人員與業務人員溝通困難、誤差極大。最後上網工程變成了網頁設計大賽，花費了大量人力物力建造的網站並沒有為企業帶來預期中的收益，反而變成了一個擺設，甚至因為要不斷投入維護費用而成了企業的負擔。 本文著重討論電子商務系統工程中系統需求分析和系統概要設計的基本方法，向項目經理和技術負責人介紹如何組織電子商務項目的開展。事實上電子商務系統一方面是一個相當復雜的工程，需要科學的系統規劃和項目管理，另一方面電子商務系統也只不過是一種應用計算機的系統工程，雖然涉及的技術內容和業務因素較多，但只要遵循合理的系統工程實施方法進行，仍然可以順利地完成電子商務系統的建設。 電子商務技術可能目前世界上最令人眼花暸亂的技術領域，新名詞、新技術、新術語每天都在出現，如何建設電子商務系統，似乎有無數種可能，令人無所適從，不知如何作出正確的決策。技術本身並不能為企業帶來效益，只有合理應用技術建造的系統才能幫助企業解決業務運作中的問題，幫助企業發展業務，所以設計電子商務系統時必須堅持一個原則：企業的需求是目的，任何技術都只是實現需求的手段，建設電子商務系統不是為了應用某項新技術，而是為了解決企業的實際問題。只有堅持這個原則才能避免常見的失誤：採用了很多不成熟或者復雜的技術，工程費用超標，項目進度無法保證，應用效果未如理想等等。電子商務系統的目標可以用以下幾個問題來總結。 應用環境：系統將為哪些用戶服務？他們使用什麼平台，如何訪問企業的電子商務系統？ 系統功能：系統為用戶提供了什麼服務？哪些是已經有的，哪些要修改，哪些要重新開發？ 數據資源：為了實現這些服務功能，系統將使用哪些數據？數據量多大，如何存儲？ 安全管理：系統的安全性如何保證？系統管理如何實施？其中系統功能是范圍最廣泛的問題，從最早的信息發布到現在很流行的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平台，或者有特殊的多國語言字元支持問題等。
經過詳細的分析後，項目會議最可能的結果就是聽到一大堆意見和要求。一個可控制進度與預算的項目不可能達成不受控制地產生的要求，分出輕重緩急才能簡單直接地解決問題。項目負責人先取得與會者的認同，目標太多不能在一個項目內完成，請大家先選出要在當前項目內完成的目標，然後評估這些目標的重要性。如果意見不能統一，被列為很重要的目標仍然很多，就要重新篩選這些目標。對於最後列出的目標，再次徵求大家的意見，確認這些目標已經包含了目標系統的基本功能，沒有重大的錯誤和遺漏。系統設計者對被列為很重要的目標和要求應特別重視，它們是影響系統方案的主要因素。第一次項目會議的成果是詳細而明確的系統需求，系統設計人員根據系統需求和目標進行詳細的方案設計。

E. 電子商務網站系統規劃應遵循的原則有哪些

1、首先要確定一個網站的主題，接下來才是著手准備材料。收集好材料應考慮如何組織好這些材料，如何讓瀏覽者以最方便、最快捷的方式來瀏覽。

與其他媒體不同，網站設計是一種平衡的藝術。一方面，希望網站頁面漂亮，另一方面必須考慮其下載要求。所以必須綜合考慮這兩方面，強調一面，必然會削弱另一方面。
2、網站創建的基本原則（市場調查，搜索資料）
只有為公司創造效益，電子商務才有生存意義。
創建網站和我們創業一樣，關鍵是一個好的定位，要使你的網站從成千上萬的網站中脫穎而出，最主要的秘訣是獨特的視角和准確的定位。
建設一個站點，需要從一開始就明確站點的目標，規劃站點的主要構成部分及各部分的功能和風格，接下來是具體各個部分的製作，最重要的是對完成的站點進行維護和排錯以及更新，因此建設一個站點比製作一個網頁需要更加專業的知識。
建站前首先要對市場進行調研，了解市場的購買力，購買人的購買習慣，購買人的性別、年齡、文化程度、職業等；還應了解哪些商品是暢銷的，哪些商品是滯銷的，哪些商品是緊缺的。一般來講，應分析同類商品市場的規模和市場最大需求量。還需要查詢經營同類商品的電子商務網站，了解它們的長處和短處。結合自己公司的專業特長和能力，分析有無能力去搶占市場份額。做電子商務的人要把握住電子商務的本質。
電子商務的本質不是電子技術，而是商務手段。所謂商務手段就是做生意。公司在做生意的過程中，首先要處理好與供應方的關系，就是要將貨物的采購過程做好，對於進貨的品種、數量、價格要有預見性，既不要造成庫存積壓，也不要造成貨品短缺。其次要做好物流與倉儲管理工作，以最小的成本換取最大的價值。比較重要的是與客戶建立良好的關系，以客戶為中心，盡可能滿足客戶的需求。
在網站設計與管理的基本過程中，每個環節都涉及了許多內容。在實施中，可以根據具體的需求增加與調整相關的內容。
3、網站的內容策劃
建立一個電子商務網站好比寫一本書，首先應擬好提綱，確定主題，規劃好結構。一個較大型的電子商務網站內容繁多，如果網站結構不清晰，內容雜亂，瀏覽者會看得糊里糊塗，而且網站的擴充和維護也會相當困難。
網站是由一個個網頁組成的，因此網頁組織非常關鍵，網頁組織的好壞直接關繫到網站的成功與否。我們為你提供全面的網站建設服務，遵循網站建設原則，建設符合你要求的網站。

F. 搭建一個日點擊量百萬以上的 電子商務網站，它的硬體設備投資大概會是多少

百萬級訪問量網站的技術准備工作
當今從純網站技術上來說，因為開源模式的發展，現在建一個小網站已經很簡單也很便宜，所以很多人都把創業方向定位在互聯網應用。這些人里大多數不是很懂技術，或者不是那麼精通，而網站開發維護方面的知識又很分散，學習成本太高，所以這篇文章將這些知識點結合起來，系統的來說，一個從日幾千訪問的小小網站，到日訪問一兩百萬的小網站，中間可能會產生什麼問題，以及怎麼才能在一開始做足工作盡量避免這些問題。

你的網站因為努力經營，訪問量逐漸升高，在升高的過程中，問題也可能開始顯現了。因為帶寬的增加、硬體的擴展、人員的擴張所帶來的成本提高是顯而易見的，而還有相當大的一部分成本是因為代碼重構、架構重構，甚至底層開發語言更換引起的，最壞的情況就是數據丟失，所有努力付之一炬。這類成本支出大多數在一開始就可以避免，先打好基礎，往後可以省很多精力，少操很多心。

對於不同的初期投資成本，技術路線的選擇是不同的。這里假設網站剛剛只是一個構想，計劃第一年伺服器硬體帶寬投入5萬左右。對於這個資金額度，有很多種方案可選擇，例如租用虛擬主機、租用單獨伺服器，或者流行的私有雲，或者託管伺服器。前兩種選擇，網站發展到一定規模時需遷移，那時再重做規劃顯然影響更大。伺服器託管因為配置自主、能完全掌握控制權，所以有一定規模的網站基本都是這種模式。採用自己託管伺服器的網站，一開始要注意以下幾點——

一、開發語言
一般來說，技術人員（程序員）都是根據自己技術背景選擇自己最熟悉的語言，不過不可能永遠是一個人寫程序，所以在語言的選擇上還要是要費些心思。首先明確一點，無論用什麼語言，最終代碼質量是看管理，因此我們從前期開發成本分析。現在國內流行的適用於網站的語言，大概有java、php、.net、 python、ruby這五大陣營。python和ruby因為在國內流行的比較晚，現在人員還是相對難招一些。.net平台的人相對多，但是到後期需要解決性能問題時，對人員技能的要求比較高。剩餘的java、php用人可以說是最多的。java和php無法從語言層面做比較，但對於初期，應用幾乎都是靠前端支撐的網站來說，php入門簡單、編寫快速，優勢相對大一點。至於後端例如行為分析、銀行介面、非同步消息處理等，等真正需要時，就要根據不同業務需求來選擇不同語言了。

二、代碼版本管理
稍微有點規模的網站就需要使用代碼版本管理了。代碼版本管理兩點最大的好處，一是方便協同工作，二是有歷史記錄可查詢比較。代碼版本管理軟體有很多，vss/cvs/svn/hg等，目前國內都比較流行，其中svn的普及度還是很高的。

假設選了svn，那麼有幾點考慮。一是採用什麼樹結構。初期可能只有一條主幹，往後就需要建立分支，例如一條開發分支，一條上線分支，再往後，可能要每個小組一個分支。建議一開始人少時選擇兩條分支，開發和線上，每個功能本地測試無誤後提交到開發分支，最後統一測試，可以上線時合並到上線分支。如果每人都建自己的分支，合並時會浪費很大精力，對於幾乎每天都要修改幾次的WEB應用來說，所費時間太多。

向伺服器部署代碼，可以手工部署也可以自動部署。手工部署相對簡單，一般可直接在伺服器上svn update，或者找個新目錄svn checkout，再把web root給ln -s過去。應用越復雜，部署越復雜，沒有什麼統一標准，只是別再用ftp上傳那種形式，一是上傳時文件引用不一致錯誤率增加，二是很容易出現開發人員的版本跟線上版本不一致，導致本來想改個錯字結果變成回滾。如果有多台伺服器還是建議自動部署，更換代碼的機器從當前服務池中臨時撤出，更新完畢後再重新加入。

三、伺服器硬體
在各個機房裡，靠一台伺服器孤獨支撐的網站數不清，但如果資金稍微充足，建議至少三台的標准配置，分別用作web處理、資料庫、備份。web伺服器至少要8G內存，雙sata raid1，如果經濟稍微寬松，或靜態文件或圖片多，則15k sas raid10。資料庫至少16G內存，15k sas raid 10。備份伺服器最好跟資料庫伺服器同等配置。硬體可以上整套品牌，也可以兼容機，也可以半品牌半組裝，取決於經濟能力。當然，這是典型的搭配，有些類型應用的性能瓶頸首先出現在web上，那種情況就要單獨分析了。

web伺服器可以既跑程序又當內存緩存，資料庫伺服器則只跑主資料庫（假如是MySQL的話），備份伺服器所承擔就相對多一些，web配置、緩存配置、資料庫配置都要跟前兩台一致，這樣WEB和資料庫任意一台出問題，很容易就可以將備份伺服器切換過去臨時頂替，直到解決完問題。要注意，硬體是隨時可能壞掉的，特別是硬碟，所以寧可WEB伺服器跟資料庫伺服器放在一起，也一定不能省掉備份，備份一定要異機，並且有非同步，電力故障、誤操作都可能導致一台機器上的所有數據丟失。很多的開源備份方案可選擇，最簡單的就是rsync，寫crontab里，定時同步。備份和切換，建議多做測試，選最安全最適合業務的，並且盡可能異地備份。

四、機房
三種機房盡量不要選：聯通訪問特別慢的電信機房、電信訪問特別慢的聯通機房、電信聯通訪問特別慢的移動或鐵通機房。機房要盡可能多的實地參觀，多測試，找個網路質量好，管理嚴格的機房。機房可以說是非常重要，直接關繫到網站訪問速度，網站訪問速度直接關繫到用戶體驗，訪問速度很慢的網站，很難獲得用戶青睞。

五、架構
在大方向上，被熟知的架構是web負載均衡+資料庫主從+緩存+分布式存儲+隊列。在一開始，按照可擴展的原則設計和編程就可以。只是要多考慮緩存失效時的雪崩效應、主從同步的數據一致性和時間差、隊列的穩定性和失敗後的重試策略、文件存儲的效率和備份方式等等意外情況。緩存失效、資料庫復制中斷、隊列寫入錯誤、電源損壞，在實際運維中經常發生，如果不注意這些，出現問題時恢復期可能會超出預期很長時間。

六、伺服器軟體
操作系統Linux很流行。在沒有專業運維人員的情況下，應傾向於擇使用的人多、社區活躍、配置方便、升級方便的發行版，例如RH系列、 debian、ubuntu server等，硬體和操作系統要一起選擇，看是否有適合的驅動，如果確定用某種商業軟體或解決方案，也要提前知曉其對哪種操作系統支持最佳。web伺服器方面，apache、nginx、lighttpd三大系列中，apache佔有量還是最大，但是想把性能調教好還是需要很專業的，nginx和 lighttpd在不需要太多調整的情況下可以達到一個比較不錯的性能。無論選擇什麼軟體，除非改過這些軟體或你的程序真的不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BUG減少、性能增加。一個典型的php網站，基本上大多數人都沒改過任何伺服器軟體源代碼，絕大多數情況是能平穩的升級到新版本的。類似於jdk5到 jdk6，python2到python3這類變動比較大的升級還是比較少見的。看看ChangeLog，看看升級說明，結合自己情況評估測試一下，越早升級越好，升級的越晚，所花費的成本越高。對於軟體包，盡量使用發行版內置的包管理工具，沒有特殊要求時不建議自己編譯，那樣對將來運維不利。

七、資料庫
幾乎所有操作最後都要落到資料庫身上，它又最難擴展（存儲也挺難）。資料庫常見的擴展方法有復制、分片，設計時要考慮到每種應用的數據如何復制、分片，當然這種考慮一般會推遲到技術設計時期。在初期進行資料庫結構設計時，要根據不同的業務類型和增長量預期來考慮是否要分庫、分區，並且盡量不要使用聯合查詢、不使用自增ID以方便分片。復制延時問題、主從資料庫數據一致性問題，可以自己寫或者用已有的運維工具進行檢測。

用存儲過程是比較難擴展的，這種情形多發生於傳統C/S，特別是OA系統轉換過來的開發人員。低成本網站不是一兩台小型機跑一個資料庫處理所有業務的模式，是機海作戰。方便水平擴展比那點預分析時間和網路傳輸流量要重要的多的多。

另外，現在流行一種概念叫NoSQL，可以理解為非傳統關系型資料庫。實際應用中，網站有著越來越多的密集寫操作、上億的簡單關系數據讀取、熱備等，這都不是傳統關系資料庫所擅長的，於是就產生了很多非關系型資料庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次的寫操作，內存型的甚至5萬以上。在設計時，可根據業務特點和性能要求來選擇是否使用這類資料庫。例如 MongoDB，幾句配置就可以組建一個復制+自動分片+failover的環境，文檔化的存儲也簡化了傳統設計庫結構再開發的模式。但是當你決定採用一項技術時，一定要真正了解其優劣，例如可能你所選擇的技術並不能支持你所需要的事務和數據一致性要求。

八、文件存儲
存儲的分布幾乎跟資料庫擴展一樣困難，不過只有百萬的PV的情況下，磁碟IO方面一般不會成大問題，一兩台採用SATA做條帶RAID的機器可以應付，反而是自己做非同步備份比較復雜，因為小文件多。如果只有一台機器做存儲，可以做簡單的優化，例如放最小縮略圖的分區和放中等縮略圖的分區，根據平均大小調整一下塊大小。存儲要規劃好目錄結構，否則文件增多後維護起來復雜，也不利於擴展。同時還要考慮將來擴容，例如採用LVM，或者把文件根據不同規則散列到不同機器。磁碟IO繁重的情況下更容易出現故障，所以要做好備份，若發現有盤壞掉，要馬上行動更換，很多人的硬碟都是壞了一塊之後，接二連三的壞下去。

為了將來圖片走cdn做准備，一開始最好就將圖片的域名分開，且不用主域名。因為很多網站都將cookie設置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，並且佔多餘流量，還可能因為瀏覽器並發線程限製造成訪問緩慢。

九、程序
一定硬體條件下，應用能承載多少訪問量，很大一部分也取決於程序如何寫。程序寫的不好，可能一萬的訪問都承載不了，寫的好，可能一兩台機器就能承擔幾百萬PV。越是復雜、數據實時性要求越高的應用，優化起來越難，但對普通網站有一個統一的思路，就是盡量向前端優化、減少資料庫操作、減少磁碟IO。向前端優化指的是，在不影響功能和體驗的情況下，能在瀏覽器執行的不要在服務端執行，能在緩存伺服器上直接返回的不要到應用伺服器，程序能直接取得的結果不要到外部取得，本機內能取得的數據不要到遠程取，內存能取到的不要到磁碟取，緩存中有的不要去資料庫查詢。減少資料庫操作指減少更新次數、緩存結果減少查詢次數、將資料庫執行的操作盡可能的讓你的程序完成（例如join查詢），減少磁碟IO指盡量不使用文件系統作為緩存、減少讀寫文件次數等。程序優化永遠要優化慢的部分，換語法是無法「優化」的。

然而編程時不應該把重點放在優化上，應該關注擴展性。當今的WEB應用，需求變化非常之快，適應多種需求的架構是不存在的，我們的擴展性就要把要點放在跟底層交互的架構上，例如持久化數據的存取規則、緩存的存取規則等，還有一些共用服務，例如用戶信息等。先把不變的部分做完善，剩下的部分就很容易將精力放在業務邏輯上面了。

G. 電子商務平台建設的作品目錄

第1章電子商務基礎
1.1基礎知識
1.2基本組成
1.2.1電子商務框架
1.2.2電子商務分類
1.3電子數據交換
第2章電子商務網路平台的規劃與建設
2.1網路規劃
2.1.1需求分析
2.1.2通信量分析
2.1.3邏輯網路設計
2.2網路管理
2.3網站定位
2.3.1網站分類
2.3.2網站規模與定位
2.4電子商務系統與Internet的連接
2.4.1選擇ISP服務商
2.4.2選擇接入方式
2.4.2.1虛擬主機
2.4.2.2伺服器託管方式
2.4.2.3專線方式接入
2.4.2.4數據中心
2.4.2.5自營主機
2.4.2.6ISDN方式接入
2.4.2.7ADSL方式接入
2.4.2.8CableModem方式接入
2.4.2.9T1和T3連接
2.4.3各種接入方式比較
2.5域名
2.5.1概述
2.5.2域名命名規則
2.5.3注冊域名
2.5.4域名的商業價值
第3章電子商務硬體平台的規劃與建設
3.1電子商務系統體系結構
3.1.1傳統C/S系統的二層體系結構
3.1.2B/S系統的三層體系結構
3.1.3兩種體系結構的對比
3.2電子商務系統硬體環境配置
3.3伺服器設備
3.3.1伺服器的選擇和測試
3.3.2PC伺服器
3.3.3UNIX伺服器
3.3.4DNS伺服器
3.3.5通信伺服器
3.3.6代理伺服器
3.3.7伺服器群集
3.4客戶端
3.5中繼器
3.6集線器
3.6.1集線器
3.6.2交換式集線器
3.6.3集線器與交換式集線器的比較
3.6.4各種集線器的選購
3.7路由器
3.7.1概述
3.7.2選擇路由器
3.8交換機
3.9路由和交換方案比較
3.10電子商務系統硬體平台投資和運營成本
第4章電子商務軟體平台的規劃與建設
4.1電子商務系統的軟體平台配置
4.2電子商務系統軟體
4.2.1網路操作系統
4.2.2Web伺服器軟體
4.2.3Web伺服器軟體功能
4.2.4Web伺服器工具
4.2.5中間件
4.2.6資料庫
4.2.7WAP簡介
4.3電子商務軟體平台費用預算
第5章Web頁面開發語言及相關技術
5.1頁面標注語言
5.1.1頁面標注語言概述
5.1.2HTML
5.1.3XML
5.1.4XHTML和VRML
5.1.5SSI
5.1.6DHTML
5.2動態網頁技術
5.2.1CGI技術
5.2.2ASP技術
5.2.3PHP技術
5.2.4JSP技術
5.2.5Servlet
5.2.6ISAPI和NSAPI技術
5.2.7CORBA技術
5.2.8Java技術
5.2.9各種動態網頁技術性能比較
5.2.10集成工具
第6章電子商務應用系統分析與設計
6.1應用系統分析與設計方法
6.1.1結構化系統開發方法
6.1.1.1系統調查
6.1.1.2系統分析
6.1.1.3系統設計
6.1.1.4程序設計
6.1.1.5系統測試
6.1.1.6運行維護
6.1.1.7結構化系統開發方法存在的問題
6.1.2快速原型法
6.1.3面向對象法
6.1.3.1基本原理
6.1.3.2相關概念
6.1.3.3開發過程
6.1.3.4面向對象開發方法的優點和不足
6.2開發目標和管理
6.2.1確定電子商務的效益目標和成本目標
6.2.2實施的管理
6.3網站的戰略管理
6.3.1職能戰略管理
6.3.2網站競爭戰略管理
6.3.3網站發展戰略管理
6.4外包與開發
6.5外購商品化軟體
6.6電子商務系統集成
6.6.1企業後端信息系統集成
6.6.2電子商務系統集成
6.7電子商務系統評價指標
第7章電子商務網站規劃與建設
7.1腳本
7.2網頁概述
7.2.1主頁
7.2.2不同網頁構建策略
7.3網站規劃
7.3.1網站內容結構
7.3.2網站頁面流程
7.3.3網站主題風格
7.3.4網站標准色彩
7.3.5網站標准字體
7.4網頁設計和製作
7.4.1網頁開發工具
7.4.2網頁設計方法
7.4.3網頁設計指導原則
7.4.4層疊樣式表
7.4.5網頁上的圖標
7.4.6網頁上的圖形
7.4.7網頁上的圖像
7.4.8網頁上的動畫
7.4.9網頁布局
7.4.10網頁高級技術
7.4.11網頁製作注意事項
7.5網站發布
7.6網站推廣
7.6.1注冊到搜索引擎
7.6.2郵件列表
7.7網站維護
7.8人員結構和職能
7.9網站運營注意事項
第8章網站前後台軟體開發
8.1前台軟體開發
8.1.1商品分類目錄管理
8.1.1.1概述
8.1.1.2商品分類目錄設計
8.1.1.3商品分類結構管理
8.1.2電子商品貨架設計
8.1.3商品信息管理
8.1.4會員服務
8.2後台軟體開發
8.2.1資料庫設計
8.2.2購物車設計
8.2.3交易處理
8.2.4訂單管理
8.2.5統計報表
8.2.6折扣管理
第9章網路和信息安全技術
9.1電子商務安全概述
9.1.1系統安全需求分析
9.1.2網路環境的安全需求
9.1.3交易安全需求分析
9.1.4基本安全技術
9.2密碼技術
9.2.1密碼技術概述
9.2.2數據加密方法
9.2.3對稱密碼體制
9.2.4公開密鑰密碼體制
9.2.5密鑰的保密與管理
9.2.6數字水印
9.3網路安全手段與相關技術
9.3.1防火牆技術
9.3.2計算機病毒防治技術
9.3.3數據的備份措施
9.4安全套接層協議SSL
9.4.1安全交易標准
9.4.2SSL概述
9.5安全電子交易協議SET
9.5.1概述
9.5.2SET體系
9.5.3SET認證體系
9.5.4SSL與SET協議的比較
9.5.5安全電子交易模式
第10章電子商務安全體系與CA認證
10.1信息認證技術
10.1.1信息認證技術概述
10.1.2數字簽名技術
10.1.3數字簽名與身份認證的方式
10.1.4數字證書
10.1.5認證中心
10.1.6申請和更新證書
10.1.7遠程發放證書
10.1.8撤銷證書
10.2電子商務安全認證體系
10.2.1PKI安全體系概述
10.2.2PKI的組成
10.2.3PKI的功能
10.2.4PKI數字證書
10.2.5認證機構關系結構
10.2.6認證操作安全的防範
10.3網上支付安全策略
10.3.1網路銀行安全概述
10.3.2網路銀行安全服務
10.3.3網路銀行安全機制
10.3.4網路銀行安全技術管理
第11章電子商務法律制度
11.1電子商務法的立法原則
11.2電子商務中的合同法應用
11.2.1電子商務合同的概念及特徵
11.2.2電子簽名與認證中的法律問題
11.2.3電子商務合同的訂立
11.2.4電子商務合同的履行及違約救濟
11.2.5電子支付與安全協議中的法律問題
11.2.6電子合同中當事人的權利義務
11.3電子商務中的無形財產權利
11.3.1知識產權
11.3.2著作權與鄰接權
11.3.3專利權
11.3.4域名的商標權保護
11.4電子商務中的消費者權益保護
11.4.1電子商務中消費者隱私權的保護
11.4.2電子商務中消費者知情權的實現
11.4.3電子商務中的特許經營權
11.5電子商務中的稅收征管法律制度
11.5.1電子商務稅收引發的新問題
11.5.2我國電子商務稅收的法律對策
11.6電子商務中的刑事犯罪
11.6.1電子商務犯罪的定義及構成要件
11.6.2電子商務犯罪的特徵
11.6.3電子商務犯罪的種類
11.6.4電子商務犯罪的刑法適用
11.7電子商務中的程序法應用
11.7.1電子商務糾紛的司法管轄權
11.7.2電子商務糾紛的法律適用
11.7.3電子商務中的非訴訟爭端解決機制
11.7.4電子證據的法律解決效力