【正文】 在?？ㄉ霞由w銷售商的印章，這一操作也有時候是放在收貨部分完成；更常見的，則是在商品上添加標簽，以利于庫房內(nèi)商品的管理和追蹤。 檢貨及發(fā)貨 播種法是將多個訂單集中到一起后，批量檢貨，然后再分檢成單獨的訂單。播種法的最33 大優(yōu)勢在于， 多個訂單集中處理后，理論上需要檢的產(chǎn)品會均勻分布在整個庫房中，檢貨時只需要在庫房中遍歷一次，即可完成整個檢貨的過程。 單件產(chǎn)品訂單單獨處理： 單件產(chǎn)品的訂單在掃描出庫時可以采取與普通訂單不同的方式（具體做法在掃描出庫時描述），可以顯著提高掃描出庫速度，需要單獨處理； 訂單的大分區(qū)，小聚合： 播種法的優(yōu)勢在于聚合，將多個訂單集中在一起處理，檢貨人員只需要遍歷一次檢貨路徑，即可完成所有訂單的檢貨，但是如果這些訂單中的所有產(chǎn)品分布于庫房的各個地點，則檢貨路徑會明顯很長，效率也不會很高。 檢貨路徑規(guī)劃： 檢貨路徑的 規(guī)劃，實際上就是地理信息學中的路徑規(guī)劃問題。而物流庫房中的路徑規(guī)劃，實際依賴的是貨位，只要確認貨位后，即可依據(jù)貨位號的大小關系，制定路徑規(guī)劃規(guī)則，從而得到檢貨路徑。 檢貨任務的執(zhí)行： 檢貨任務的執(zhí)行，即在貨位上檢下產(chǎn)品的過程，需要注意兩點：所檢產(chǎn)品的正確，產(chǎn)品數(shù)量的正確。除了檢貨人員自己的細致檢查外，最理想的方式是使用 RF 設備，掃描條碼，確認產(chǎn)品類型。 34 第四章 運行環(huán)境 服務器 軟硬 環(huán)境 需求名稱 環(huán)境要求 硬件最低配置 CPU： 四核 （以上） 內(nèi)存：（ 4G 以上）、網(wǎng)卡：千兆 操作系統(tǒng) Ubuntu Server 應用服務器 、 、 負載均衡 LVS(Linux Virtual Server) 數(shù)據(jù)庫 、 Oracle11g 分布式 文件服務器 分布式數(shù)據(jù)庫 ameoba 客戶端軟 硬 環(huán)境 需求名稱 環(huán)境要求 硬件最低配置 CPU： (以上 ) 內(nèi)存： 512MB（以上） 操作系統(tǒng) 適合 Windows 系列 、 Linux 系列 、 Mac OS 瀏覽器 適合 以上 ， 以上 ， 遨游 以上 ， 以上 版本 最小 屏幕區(qū)域 1024*768 35 第五章安全保障建設 服務分層隔離設計 W e b服 務 器 集 群應 用服 務 器 集 群資 源服 務 器 集 群分 布 式數(shù) 據(jù) 庫 集 群分 布 式文 件 系 統(tǒng) 集 群高 低（安全級別） 圖 41. 服務器分離設計 使用 linux 系統(tǒng)的 iptables 內(nèi)核級防火墻，可以根據(jù)需要禁止某些或開發(fā)某些端口的訪問。在架構中，將各種服務器按照安全級別的從高到低分為如圖（ 圖 51）： ? Web 服務器集群 ? 安全級別最低，可由外部直接通過 SSH(Secure Shell)協(xié)議登錄 ? 向所有 IP 打開 HTTP, HTTPS, SSH, FTP 等端口 ? 應用服 務器及資源服務器集群 ? 安全級別中等，不可直接由外部登錄。 ? 只向 Web 服務器集群打開相應的服務端口（由具體應用決定且可配） ? （ 分布式 ） 數(shù)據(jù)庫集群和 (分布式 )文件系統(tǒng)集群 36 ? 安全級別最高，不可直接由外部登錄 ? 只向應用服務器及資源服務器集群打開絕對必要的服務端口 數(shù)據(jù)安全設計 數(shù)據(jù)在 項目 中 處于核心地位，數(shù)據(jù) 分為 兩大類即：結構化數(shù)據(jù)和非結構化數(shù)據(jù)。結構化數(shù)據(jù)一般指的是存儲在數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)這里可以是 (oracle 或者 mysql 等關系型數(shù)據(jù)庫 ), 非結構化數(shù)據(jù)指的是如圖片、視頻、文件等非結構化資源。 從圖（ 8） 我們可以看到數(shù)據(jù)庫和文件系統(tǒng)的安全級別是最高的。這里涉及到兩個概念 集群和分布式。 項目數(shù)據(jù)安全設計可以分為兩個階段，根據(jù)項目運營的需求進行調(diào)整。 ? 第一階段 集群 集群，是項目初期和中期采用的數(shù)據(jù)安全設計。這種方式，在項目初期，沒有大并發(fā)大量和大數(shù)據(jù)量的前期下?？梢员ＷC數(shù)據(jù)的安全和完整性。 結構化數(shù)據(jù)以 MYSQL 為例常用的集群技術，目前最常用的方式就是設置主 從（ masterslave）庫 ,并實現(xiàn)讀寫分離，保障數(shù)據(jù)安全的同時，提高了數(shù)據(jù)操縱的效率。如圖（ 9），在這里我們可以保證，當一臺數(shù)據(jù)庫服 務器當機的時候，那項目還能正常運作，而不會有絲毫影響 圖 42. 結構化數(shù)據(jù)集群 非結構化數(shù)據(jù)，對于電子商務項目來說視頻資源是相對較少的，如有也只是產(chǎn)品介紹 flash或者短片，主要是圖片類資源， flash 等。在這里有一種簡易的方法 采用 RAID 做多硬盤數(shù)據(jù)同步。 但是這種方法，只能在硬盤損壞的情況下保證項目正常運作，如果服務器其他部件損壞則無法正常運作。在項目運作初期，特別是 B2C 項目，如果沒有太多 SNS 交互功能，那一般非結構化資源不會過多。所以在項目初期可以采用以 nginx 或者 ligd 為應用服務 器，（兩37 者在靜態(tài)資源的處理上要優(yōu)于 apache 或 IIS），下面以 nginx 為例（ nginx 更穩(wěn)定）。如圖（ 圖43）所示 圖 43. NGINX 負載均衡示意 ? 第二階段 分布式集群 當項目運營發(fā)展到一定階段，用戶并發(fā)數(shù)和數(shù)據(jù)量暴增到已經(jīng)達到第一階段架構瓶頸。我們應該采用分布式集群對架構進行拓展，以保障系統(tǒng)的性能以及項目的正常運作，當然這還包括 web 前端的安全性和性能問題，這個在服務器架構上會詳細描述。 集群大家可以理解為，一組服務器集中在一起實現(xiàn)一個業(yè)務。而分布式，的每個節(jié)點都處理不同的業(yè)務，每次分布式的節(jié)都 可以是一個集群。從中大家可以看出分布式和集群的關系，分布式是集群的擴展。采用分布式可以解決集群的性能瓶頸問題，資源瓶頸問題，因為它是可以無限拓展的。 對于結構化數(shù)據(jù)，在項目第二階段還是采用 MYSQL 數(shù)據(jù)庫的分布式集群方式來存儲。因為首先 MYSQL 是免費開源的，大大降低項目運營的成本；其次 MYSQL 是跨平臺的，與 MS SQL 相比大大提高了拓展性；再次 MYSQL 輕便耗資源少，這個是 ORACLE 無法比擬的。我們采用 amoeba 作為 MYSQL 分布式數(shù)據(jù)庫的中間件。如圖（ 11）所示，解決數(shù)據(jù)量大的情況下，數(shù)據(jù)查詢效 率的問題，以及服務器資源不足的問題。 MYSQL SERVER 可以無限拓展，每個 mysql server 都可以是如圖（ 圖 44）所示的主從庫。 38 圖 44. MYSQL 數(shù)據(jù)庫分布式存儲 同時 amoeba 也支持讀寫分離，這大大提高了 mysql 的讀寫效率，可以充分利用 mysql的不同存儲引擎的不同機制來讓數(shù)據(jù)庫性能達到最優(yōu)狀態(tài)如圖（ 圖 45）所示 圖 45. Amoeba 讀寫分離架構 對于非結構化數(shù)據(jù)存儲，我們采用 hadoop 構建分布式文件服務器。從而解決，文件備份和容量無限擴容的問題。在 hadoop 下，當你服務器資源不足 包括：硬盤、 CPU、內(nèi)存。只要增加一個或者多個 Datanode 節(jié)點，就可以解決這個問題，而且那個節(jié)點出問題，都不會影響到項目正常運作。如圖（ 圖 46）所示。 39 圖 46. 圖分布式文件存儲 （ 當 系統(tǒng)磁盤 出現(xiàn)瓶頸的時候，可以采用 NAS 附件存儲 技術如 ：磁盤陣列形式 ；或者采用 SAN 網(wǎng)絡存儲 技術 ，來解決） 容災設計 所謂容災 即，當發(fā)生災難的時候如：地震、海嘯等，淹沒了主機房的時候，項目還能正常運行，或者受影響不大。在這里一樣根據(jù)項目運營的不同階段做兩個階段的容災方案。 ? 第一階段，可采用定時異地容災機制 項目初期， 為了防止數(shù)據(jù)丟失， 可以通過 定期對數(shù)據(jù)進行備份 包括：結構化數(shù)據(jù)、非結構化數(shù)據(jù) 。 結構化數(shù)據(jù) ：在線數(shù)據(jù)庫服務器（ DB）每日定時 運行腳本做整庫自備份，生成數(shù)據(jù)庫備份文件，并將備份文件上傳到備份數(shù)據(jù)庫（ Backup DB）。這兩臺服務器每日定時 運行腳本將最新的數(shù)據(jù)庫備份文件導入到自身的數(shù)據(jù)庫。 根據(jù)上傳資源的用戶角色不同， 非結構化數(shù)據(jù) 又分為： a）用戶上傳 數(shù)據(jù)資源 備份：定期（如 30 分鐘）從 DB 服務器的 media meta 信息表中獲取最新上傳 數(shù)據(jù)資源 的列表，將此列表中的每個 數(shù)據(jù)資源 從 Media 服務器拷 貝到在線 Web 服務器（ Web1, Web2）、備份 Web服務器（ Backup Web），以此達到備份效果。 b）靜態(tài)資源備份：每次在部署新版本時，運行部署腳本將最新的靜態(tài)資源拷貝到在線 Web 服務器（ Web1, Web2）、備份 Web 服務器（ Backup Web），從而進行備份。 40 ? 第二階段，可采用第三方異地容災機制 第二階段，由于項目運營已經(jīng)進入常態(tài)化，用戶量和用戶數(shù)據(jù)日趨重要，每時每刻都可能有用戶進行交易，定時沒分已經(jīng)無法滿足需求，這個時候實時異地備份成為必然趨勢 。 服務器架構 綜合考慮成本和效率服務 器在系統(tǒng)中主要分為 3 大塊包括： WEB 服務器、數(shù)據(jù)庫服務器、文件服務器（在必要的時候包括：應用服務器和資源服務器）。 WEB 服務器，主要存放項目的程序代碼； 數(shù)據(jù)庫服務器，主要存放數(shù)據(jù)庫和數(shù)據(jù)倉庫等結構化數(shù)據(jù)； 文件服務器，主要存放的是圖片、文件、視頻等非結構化數(shù)據(jù)。 在 WEB 服務器主要采用 LVS 作為負載均衡中間件， 4 臺服務器（ web web weblbweblb2）用于實現(xiàn) web 服務器的負載均衡（需 5 個 IP）。 web web2 均為系統(tǒng)的 web 服務器， weblb weblb2 均為 web 服務 器的負載均衡節(jié)點 。 weblb weblb2 均為 web 服務器的負載均衡節(jié)點，用于調(diào)用 web web2 網(wǎng)站服務器，其中 weblb1 服務器處于工作狀態(tài)，當 weblb1 出現(xiàn)故障或死機時將由 weblb2 服務器接管所有的 weblb1 的所有工作直到 weblb1 服務器恢復正常，保證用戶的正常訪問； web web2 均為網(wǎng)站 web 服務器，其中負載量較小的將被 weblb1（或 weblb2）首先調(diào)用以達到 web1 與 web2 的負載均衡，當 web1 或 web2 出現(xiàn)故障或死機時將由相應的另一方接管所有工作，保證 用戶的正常訪問 當在線用戶增加導致項目訪問緩慢的情況時候，可以增加負載均衡節(jié)點，來實現(xiàn)分流，解決訪問緩慢的問題?？梢赃M行無限擴容。 41 圖 47. WEB 服務器架構圖 其他安全機制 ? 安全 登錄 控制 ? 禁 用 root 帳號 ? 使用 SSH 密鑰登錄方式登錄，密鑰采用 2048 位的 DSA 密碼。該方法被業(yè)界證明為最安全的登錄方式（ 該 加密算法 被 美國國防部 等高保密機構 使用） ? 用戶訪問權限控制 ? 將隨時更新系統(tǒng)補丁，以避免系統(tǒng)漏洞 ? 服務器 將盡量少開服務，只服務于 必要 項目，這樣降低由其他服務帶來的安全隱患。 ? 用戶密碼保護，我們將保持 sha 256 位的 hash 密碼，而不是原始密碼 42 ? 開啟 128 位 SSL 的 訪問，使得 關鍵 數(shù)據(jù)加密傳輸 ? 在服務器端審核所有用戶操作，以防止非法用戶操作 ? 采用用戶密碼強度驗證，禁止使用簡單的不安全的密碼 ? 用戶密鑰一旦丟失將立即作廢，防止帳號盜用 ? 每天對數(shù)據(jù)庫進行熱備份，以防止數(shù)據(jù)庫崩潰或者非法篡改。備份過程通過 SSH 安全隧道進行。 ? 進行代碼級安全檢驗，防止 SQL 注入問題。