1.1 blog:
2 核心業務功能模組
2.1 提醒
2.1.1 郵件
2.1.2 簡訊
2.1.3 站內訊息
2.1.4 im？
2.2 濾詞系統
2.3 前台
2.3.1 訂單
2.3.2 賣家
2.3.3 搜尋
2.3.4 商品
2.3.5 提現、對賬
2.3.6 **
2.3.7 投訴仲裁
2.4 後台
2.4.1 買家
2.4.2 賣家
2.4.3 合同
2.4.4 其他支援業務系統
3 大資料量
3.1 買家數
3.1.1 買家數量是乙個累積增長的過程
3.2 賣家數
3.2.1 中國號稱有4000
萬的中小企業
3.3 訂單數
3.3.1 乙個買家可以形成多個訂單
3.5 產品數量
3.5.1 每個賣家會發布多個產品
3.6 郵件數量
3.6.1 每個訂單從生成開始整個流程會觸發多個通知操作
3.7 站內訊息數量
3.7.1 買家和賣家的互動大部分是通過站內訊息的方式
3.7.2 買家和賣家的訊息也可以以im
形式儲存
3.7.3 買家和賣家的訊息是整個平台做仲裁的重要依據
3.8 賬務資訊數
3.8.1 與訂單息息相關
3.9 使用者行為儲存
4 大併發量
4.1 產品終極頁
4.1.1 **的70%
的訂單發起位址是產品終極頁
4.1.2 所有活動都會導向這個頁面
4.2 垂直搜尋
4.2.1 大部分的產品查詢都會通過這個引擎
4.2.2 很多公司的b2c
和b2b2c
同時推進，這個搜尋需要整合兩部分資料
4.3 訂單數
4.3.1 **以及常規的營銷活動會帶來比較大的併發量
4.3.2 **活動產生的壓力
4.4 站內訊息數
4.4.1 對於一些b2b2c
型別的電商，站內訊息是買家和賣家唯一溝通渠道
4.4.2 屬於產生訂單的觸發型操作
4.4.3 平均乙個訂單會產生4
個以上的站內訊息
4.5 郵件資訊數
4.5.1 乙個訂單平均會觸發4
個以上的郵件操作
4.5.2 郵件的傳送要求準實時
4.5.3 屬於訂單產生的觸發型操作
4.6 產品
4.6.1 每個產品對應多個
4.6.2 的展示一般通過cdn
進行加速
4.6.3 屬於訪問量帶來的不可避免的訪問壓力
4.7 使用者行為記錄
4.7.1 使用者觸發型的動作
5 理解的幾個架構核心演算法
5.1 一致性hash演算法
5.2 分布式演算法paxos演算法
5.3 lru演算法
6 核心目標
6.1 乾掉小型機
6.2 乾掉oracle
，都用免費的
mysql
6.3 支援大資料量
6.4 支援高併發
6.5 支援線性拓展
6.6 保證ha
7 分布式不可避免的損失
7.1 資料統計只能單獨處理
7.2 為了ha
我們必須付出成倍的機器
7.3 為了加速我們需要更大的頻寬
7.4 為了效能我們將冗餘較多字段
7.5 系統膨脹到一定程度，我們的必須soa
8 常規技術
8.1 系統垂直拆分
8.1.1 賣家系統
8.1.2 買家系統
8.1.3 商品系統
8.1.4 郵件系統edm
8.1.6 財務系統
8.1.7 日誌審計系統
8.1.8 訊息系統
8.1.9 資訊系統
8.1.10 其他業務系統
8.1.11 支付系統
8.1.12 對賬系統
8.2 分布式資料庫
8.2.1 訂單需要用分布式的方式儲存
8.2.2 買家需要使用分布式方式儲存
8.2.3 賣家需要進行分布式儲存
8.2.4 訊息需要採用分布式儲存
8.2.5 商品需要用分布式方式儲存
8.2.6 策略推薦
客戶端方式可以用阿里的cobar
有侷限性是只能在spring+myabatis
下使用
如果有機器可以用阿里的cobar-server
粗糙一點的用變形蟲amode
華麗一點的可以考慮用**的tddl
8.3 非同步的訊息伺服器
8.3.1 核心就是訂單產生的時候通知買家和賣家
8.3.2 郵件提醒需要訊息伺服器做緩衝
8.3.3 站內訊息建議也通過訊息伺服器做緩衝
8.3.4 策略推薦
一般基本的推薦activemq
做集群和
failover機制
較大資料量推薦**的開源訊息伺服器metaq
8.4 加速
8.4.1 全國cdn加速
8.4.2 的分布式儲存策略
8.4.3 的加工提速
8.4.4 策略推薦
**的tair
檔案系統
8.5 海量資料計算
8.5.1 統計使用者行為類的
8.5.2 商業bi類的
8.5.3 策略推薦
較大資料量建議使用hadoop
4t以下資料量使用
mongodb
8.6 終極頁靜態化
8.6.1 建議全部靜態化
8.6.2 memache去支援靜態頁上的動態資料的動態建立
8.6.3 策略推薦
freemark做可靜態化資源的靜態化
velocity做可靜態化資源的靜態化
8.7 機房異構
8.7.1 一般**的資料量可能需要這樣的操作，常規電商不建議
8.7.2 一般通過資料庫層次的同步
8.7.3 通過訊息伺服器進行部分資訊的傳遞
8.8 垂直搜尋
8.8.1 就是通過mapreduce
這類搜尋直接放到檔案系統上進行
8.8.2 將搜尋結果cache
到memcache
這類集群或者
mongodb上
8.8.3 策略推薦
solr+luence
8.9 服務治理
8.9.1 上邊列出的系統只是業務系統的一部分，多個系統的介面需要統一管理
8.9.2 服務治理最好簡化為一種語言，方便通訊
8.9.3 策略推薦
阿里的dubbo
**曾經開源的hsf
8.10 單點sso
8.10.1 將系統進行拆分後，sso
是乙個核心引擎在不同系統間切換
8.10.2 針對支付類的操作，建議做二次密碼驗證
8.10.3 策略推薦
cas有時間還是自己寫吧
8.11 esb
8.11.1 核心工作就是服務編排，以及資料流轉編排
8.11.2 併發量有限，一般放到後端進行比較合適
8.11.3 策略推薦
mule
camel
8.12 工作流引擎
8.12.1 主要是平台商角度需要進行訂單流轉以及業務的變更需要
8.12.2 暫時這類系統除非自己構建，無法支援較大資料量以及併發量
8.12.3 策略推薦
activiti（
jbpm4.4
的公升級版）
關注規則引擎的可以用jbpm5
8.13 審計日誌收集
8.13.1 較大資料量增加網絡卡，寫本地磁碟延遲傳送
8.13.2 策略推薦
，經過證明可以每天進行
4t的資料量傳送
中小資料量就activemq即可
8.14 定時任務排程
8.14.1 用來執行一些定時任務
8.14.2 策略推薦
利用quartz
本身的集群特性
利用**的定時任務專案taobaoschedule
btw:附上mindjet圖
未來跨境電商將由B2C轉向B2B
為更好地促進校企人才交流，加大商務人才培養力度，提高企業的商務競爭力，商務部外貿發展事務局於4月23日在北京舉行 12335企校對接活動暨企校交流會 對外經貿大學教授王健在會上表示，未來跨境電子商務將由b2c轉向b2b，整個制度體系和物流體系可能都要隨之發生變化，政策導向應該從所謂零售或者是b2c更...
B2C電商設計
set names utf8mb4 set foreign key checks 0 create table category id int 11 not null primary key auto increment,name varchar 255 not null default comme...
FEC開發的B2B2B電商系統包含哪些功能模組？
今天，電子商務不算是乙個新興行業了，但是許多企業和商家仍對電商系統一知半解。電子商務包含哪些模式？核心是什麼？電商系統包含哪些功能模組？為什麼有些電商平台風生水起，而有些電商平台卻虧損不斷？那麼，本文就和筷雲資訊一起來了解其中奧秘吧！其實，電子商務的三要素就是人 貨 場，無論是b2b b2c還是社群...