① 會員用戶數量在2000萬，這樣的電子商務系統需求，需要一個怎樣的集群伺服器架構，使用LAMP架構。
2000W已經算是大型網站抄了，不論襲數據量還有訪問量都是非常大的，像這種情況下可以有兩種配置方案，第一就是用很多台伺服器通過集群來滿足咱們的需要 第二就是配置高端的伺服器來滿足需求比如IBM的刀片伺服器或者小型機，總體沒個一二百W下不來
我們是IBM伺服器的代理商 主做機房建設 系統集成 有需要了可以聯系我 資料有我的聯系方式
② 簡述電子商務服務體系架構
電子商務是以信息網路技術為手段，以商品交換為中心的商務活動；也可理解為在互聯網、企業內部網和增值網上以電子交易方式進行交易活動和相關服務的活動，是傳統商業活動各環節的電子化、網路化、信息化。
電子商務通常是指在全球各地廣泛的商業貿易活動中，在網際網路開放的網路環境下，基於瀏覽器/伺服器應用方式，買賣雙方不謀面地進行各種商貿活動，實現消費者的網上購物、商戶之間的網上交易和在線電子支付以及各種商務活動、交易活動、金融活動和相關的綜合服務活動的一種新型的商業運營模式。各國政府、學者、企業界人士根據自己所處的地位和對電子商務參與的角度和程度的不同，給出了許多不同的定義。電子商務分為：ABC、B2B、B2C、C2C、B2M、M2C、B2A（即B2G）、C2A（即C2G）、O2O 等。
③ 電子商務的基礎框架結構是怎樣的
從技術角度看，電子商務的基礎框架結構由以下三部分組成：
(一)企業內部網
企業內部網由Web伺服器、電子郵件伺服器、資料庫伺服器以及客戶端的PC機組成。所有這些伺服器和PC機都通過先進的網路設備集線器HUB或交換器SWITCH連接在一起。
WEB伺服器可以向企業內部提供一個內部WWW站點，藉此提供企業內部日常的信息訪問；郵件伺服器為企業內部提供電子郵件的發送和接收；資料庫伺服器通過WEB伺服器和由自己對企業內部和外部提供電子商務處理服務；客戶端PC機則用來為企業內部員工提供訪問工具，員工可以通過InternetExplorer等瀏覽器在許可權允許的前提下方便快捷地訪問各種伺服器。
(二)企業外聯網
企業外聯網是架構在企業內聯網和供應商、合作夥伴、經銷商等其他企業內聯網之間的通信網路。也可以說，企業外聯網是由兩個或兩個以上的企業內聯網連接而成的。這樣組織之間就可以訪問彼此的重要信息，如定購信息、交貨信息等。當然，組織間通過外聯網各自的需要共享一部分而不是全部的信息。
(三)Internet
Internet是電子商務最廣泛的層次。任何組織都可以通過Internet向世界上所有的人發布和傳遞信息，而任何入都可以訪問Internet獲得相關信息和服務。當企業需要和其他所有的公司和廣大消費者進行交流的時候。它們就必須充分利用互聯網。互聯網是目前世界上最大的計算機通信網路，它將世界各地的計算機網鉻聯結在一起。企業開展全面的電子商務必須藉助互聯網。
只有在企業內聯網、外聯網以及藉助互聯網的前提下，企業才可能實現真正意義上的完全的電子商務。
④ 能不能詳細說一下一家做電商平台的linux伺服器架構是什麼
看你做電子商務那塊的工作了 如果是伺服器的運營維護，肯定是需要精通Linux 如果是做商務、客服等，不需要你會Linux
⑤ 電子商務網站一般架構有哪些
1．電子商務的基本概念電子商務是利用計算機及互聯網開展的各種商務活動。其中電子是手段，商務是目的。是通過網站的商務運作和會員制收費，達到盈利的目的。電子商務包括以下三部分內容：
電子：指信息基礎設施及相關應用系統，其中信息基礎設施包括internet 網路基礎和信息技術，應用系統應包括支持電子商務活動的網站。
商務：指業務內容、流程及規則，這是電子商務網站系統設計的基礎和依據。
信息：指業務活動中的數據，應完整、全面、實時、動態。業務活動所使用的數據也是網站系統資料庫設計的依據。Internet技術、信息技術系統和商務過程的有機集成形成了一個新的商務模型，即電子商務模型。2．電子商務網站的基本架構設計電子商務網站是以商務活動為中心進行的，而網站的盈利一般通過網站的會員制收費進行，網站的盈利點是網站根據網站的商務活動內容確定的，所以網站的基本架構設計既要以商務活動的業務內容、流程、相關規則為基礎，又要兼顧電子商務網站的收費體系。網站基本架構的設計主要根據以下步驟進行：2.1 確定電子商務網站功能定位 確定網站所涉及的商務活動的內容、商務活動的流程。比如我們在進行房產信息網的設計中，首先考慮確定網站發布房產信息的種類，確定了房源信息包括中介所的房源信息和個人的出售、出租信息，網站負責信息的發布和信息的管理。同時在確定了信息發布種類後，確定了信息處理的流程為房源信息輸入、會員資格審核、信息審核，信息發布。2.2 確定網站的收費對象和收費規則在網站所涉及的商務內容確定了的情況下，確定收費的對象和如何進行收費，以此為依據確定網站的欄目。網站欄目的劃分實際上就是系統的功能模塊劃分。在房產網站的系統設計中，確定了網站只對房產中介所進行收費，個人用戶免費，所以網站的主要欄目分為個人專區和中介所專區兩個主要欄目，同時根據功能的逐步擴大，這樣也就基本確定了網站的信息服務內容和方式。2.3 確定網站的欄目的功能在確定了網站的收費項目後，要確定網站的主要欄目和功能，包括網站的管理功能模塊、網站的信息發布方式、網站商務活動的發布以及網站導航欄等。網站的功能欄目的設置和系統的主要功能模塊的劃分是相一致的。網站業務介紹性欄目，應包括內容應包括會員申請流程，收費標准，網站運行規程等，使用戶對網站的服務有一個明確的了解，是擴大網站的會員用戶數量和提高網站的使用率都是必不可少的欄目。網站的導航欄是網站的整體功能的全面介紹，使用戶對網站的功能有一個清晰的了解，也是網站不可缺少的欄目。同時也應有網站運行的相關提示信息，比如在房產網站的設計中，我們在確定了收費對象和主要功能後，確定了網站首頁的主要欄目為中介所專區、個人專區、寫字間專區、新房樓市等欄目，同時加入了上網導航欄目對網站的主要功能進行介紹。 2.4 確定網站的信息流和控制流 在確定了網站的主要功能和商務活動的主要規則後，應該確定網站的信息流圖和控制流圖，作為資料庫設計的基礎。在房產網的設計中，我們根據房產信息發布的功能和所確定的信息審核和控制流程，確定房產網的基本數據流圖為： 實例：一個網站的數據流圖在確定了一個網站的數據流圖和控制流後 ，系統的運行控制流程也就確定下來了。3．網站的後台管理在網站的基本功能和數據流確定後，為了保證網站信息的准確性和有效性，應有完善的後台管理和維護系統，進行相關數據的審核，定期進行資料庫的維護和備份，進行繳費會員資格的管理，有效的保證網站的商務運作。我們在房產信息發布網站的後台管理系統的系統設計中，設計了一套完整的網站後台管理系統，主要功能包括房源信息管理如：房產信息審核、房產信息刪除、房產信息刪除確認；網站運行提示信息的管理，主要是對網站與商務運營有關的信息進行管理，使網站的用戶對網站的運行情況進行管理；網站會員資格的審核，對逾期未繳費的用戶取消會員資格；網站系統管理員許可權管理，對不同的網站系統管理人員進行授權使用不同的後台維護功能。4．網站的資料庫設計在確定了網站的主要商務的業務對象和業務流程後，可以確定了網站的數據流，也就可以進行資料庫設計。 在進行資料庫設計時，同樣和一般的應用系統開發一樣，應該注意信息的完整性和數據的獨立性。我們在房產網站的開發過程中，在資料庫的設計階段，對系統的資料庫按房源的基本信息、中介所信息、個人信息分別進行庫表的設計，同時對系統的維護信息、許可權管理等控制信息設計獨立的庫表，主要的資料庫表為房源信息表、中介所信息表、會員信息表等，這樣可以方便網站的信息輸入、資料庫查詢同時也方便網站後台的資料庫管理和資料庫維護。資料庫表數據的獨立性和數據冗餘直接影響數據的存取效率，影響網站的運行速度，所以在資料庫設計時一定要避免數據的冗餘性，同時要避免長資料庫表的設計。總結：在電子商務網站開發過程中，網站的商業運作模式決定了網站系統設計，一個功能清晰的網站的設計，一定要從網站的系統設計入手。
⑥ 電子商務網站一般架構有哪些
大型電子商務網站架構，摘抄 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緩存，應該效率上能接受。
⑦ 電子商務的三層結構模型是什麼
1、電子商務的三層結構模型，是指在客戶端與資料庫之間加入了一個「中間層」，也叫組件層。並不是指物理上的三層，不是簡單地放置三台機器就是三層體系結構，也不僅僅有B/S應用才是三層體系結構。三層是指邏輯上的三層，即使這三個層放置到一台機器上。三層體系的應用程序將業務規則、數據訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與資料庫進行交互，而是通過COM/DCOM通訊與中間層建立連接，再經由中間層與資料庫進行交互。
2、1998年，SUN公司將電子商務體系結構被分解成表達層、應用（邏輯）層和數據層。
（1）表達層。表達層以Web伺服器為基礎，負責信息的發布，用於顯示數據和接收用戶輸入的數據，為用戶提供一種互動式操作的界面。
（2）應用層。應用層是系統架構中最體現核心架構的部分，處於數據層與表示層之間，起到了數據交換中承上啟下的作用。根據分層的思想，對於數據層而言，應用層是調用者，對於表達層而言，應用層是被調用者，應用層負責體系架構中所有核心業務邏輯的處理。
（3）數據層。數據層的基礎是DBMS，負責資料庫的訪問，可以訪問資料庫系統、二進制文件、文本文檔或是XML文檔。
⑧ 求電商公司的架構圖，伺服器擺放，所用技術等等
電商公司，網路架構要保證的就是兩點：1 速度 2 不間斷
所以，外局，最起碼要求兩條INET線路（最好是兩條光纖，理想狀態是兩條當地最快供應商的光纖，比如說電信，一條備用光纖比如說聯通）
因為有兩條或以上的INET，所以路由器也必須是支持多WAN的，建議並發處理萬級以上的，不然CPU會吃不消。
路由器也要備多一個，備用的可以1千元以下的足夠了。
負載均衡，用海蜘蛛、wayos，ros等設置就可以了，所以路由器本身就要選折這種系統的，還要限制流媒體和BT等吃流量厲害的軟體。
主千兆交換機背板起碼要80G以上的了。
下層的交換機，最好能是分組分部門，控制在每組16-24口之內。
注意預留備用交換機。
主流量伺服器設置穩定後，建議還是擺放到專業機房去，畢竟那裡的帶寬是足夠的，環境也舒適。
公司內如果光纖有固定ip，總下行可保證在200M，總上行可保證在50M，可在公司內做一個鏡像伺服器，由外部主伺服器推送過來（下行），當然，最好有獨立的鏡像用光纖。
主從伺服器的硬體反而要求不太高，現在幾萬的機子，硬體已經好得很了，不過一定要raid 5以上。
資料庫，最起碼是sql，然後就oracle，要看口袋裡的銀子。
最後，就是ups，智能管理的也是必須的，5kva以上吧，不然整個機房就沒必要搞了。
噢，對了，空調和空凈機也不能少，沒空調你敢搞電商伺服器？
⑨ 電子商務ERP軟體C/S架構和B/S架構的區別
C/S 架構
C/S 架構是一種典型的兩層架構，其全程是Client/Server，即客戶端伺服器端架構，其客戶端包含一個或多個在用戶的電腦上運行的程序，而伺服器端有兩種，一種是資料庫伺服器端，客戶端通過資料庫連接訪問伺服器端的數據；另一種是Socket伺服器端，伺服器端的程序通過Socket與客戶端的程序通信。
B/S架構
B/S 架構的全稱為Browser/Server，即瀏覽器/伺服器結構。Browser指的是Web瀏覽器，極少數事務邏輯在前端實現，但主要事務邏輯在伺服器端實現，Browser客戶端，WebApp伺服器端和DB端構成所謂的三層架構。
B/S架構的系統無須特別安裝，只有Web瀏覽器即可。
B/S架構中，顯示邏輯交給了Web瀏覽器，事務處理邏輯在放在了WebApp上，這樣就避免了龐大的胖客戶端，減少了客戶端的壓力。因為客戶端包含的邏輯很少，因此也被成為瘦客戶端。
C/S和B/S都可以進行同樣的業務處理，但是B/S隨著Internet技術的興起，是對C/S結構的一種改進或者擴展的結構。相對於C/S，B/S具有如下優勢：
1、分布性：可以隨時進行查詢、瀏覽等業務
2、業務擴展方便：增加網頁即可增加伺服器功能
3、維護簡單方便：改變網頁，即可實現所有用戶同步更新
4、開發簡單，共享性強，成本低，數據可以持久存儲在雲端而不必擔心數據的丟失。
⑩ 電商系統 分布式架構 web伺服器端做些什麼功能
不是web服務嗎？