【正文】 ? 進(jìn)行代碼級(jí)安全檢驗(yàn)，防止 SQL 注入問題。 ? 用戶密碼保護(hù)，我們將保持 sha 256 位的 hash 密碼，而不是原始密碼 42 ? 開啟 128 位 SSL 的 訪問，使得 關(guān)鍵 數(shù)據(jù)加密傳輸 ? 在服務(wù)器端審核所有用戶操作，以防止非法用戶操作 ? 采用用戶密碼強(qiáng)度驗(yàn)證，禁止使用簡(jiǎn)單的不安全的密碼 ? 用戶密鑰一旦丟失將立即作廢，防止帳號(hào)盜用 ? 每天對(duì)數(shù)據(jù)庫進(jìn)行熱備份，以防止數(shù)據(jù)庫崩潰或者非法篡改。 41 圖 47. WEB 服務(wù)器架構(gòu)圖 其他安全機(jī)制 ? 安全 登錄 控制 ? 禁 用 root 帳號(hào) ? 使用 SSH 密鑰登錄方式登錄，密鑰采用 2048 位的 DSA 密碼。 weblb weblb2 均為 web 服務(wù)器的負(fù)載均衡節(jié)點(diǎn)，用于調(diào)用 web web2 網(wǎng)站服務(wù)器，其中 weblb1 服務(wù)器處于工作狀態(tài)，當(dāng) weblb1 出現(xiàn)故障或死機(jī)時(shí)將由 weblb2 服務(wù)器接管所有的 weblb1 的所有工作直到 weblb1 服務(wù)器恢復(fù)正常，保證用戶的正常訪問； web web2 均為網(wǎng)站 web 服務(wù)器，其中負(fù)載量較小的將被 weblb1（或 weblb2）首先調(diào)用以達(dá)到 web1 與 web2 的負(fù)載均衡，當(dāng) web1 或 web2 出現(xiàn)故障或死機(jī)時(shí)將由相應(yīng)的另一方接管所有工作，保證 用戶的正常訪問 當(dāng)在線用戶增加導(dǎo)致項(xiàng)目訪問緩慢的情況時(shí)候，可以增加負(fù)載均衡節(jié)點(diǎn)，來實(shí)現(xiàn)分流，解決訪問緩慢的問題。 在 WEB 服務(wù)器主要采用 LVS 作為負(fù)載均衡中間件， 4 臺(tái)服務(wù)器（ web web weblbweblb2）用于實(shí)現(xiàn) web 服務(wù)器的負(fù)載均衡（需 5 個(gè) IP）。 服務(wù)器架構(gòu) 綜合考慮成本和效率服務(wù) 器在系統(tǒng)中主要分為 3 大塊包括： WEB 服務(wù)器、數(shù)據(jù)庫服務(wù)器、文件服務(wù)器（在必要的時(shí)候包括：應(yīng)用服務(wù)器和資源服務(wù)器）。 b）靜態(tài)資源備份：每次在部署新版本時(shí)，運(yùn)行部署腳本將最新的靜態(tài)資源拷貝到在線 Web 服務(wù)器（ Web1, Web2）、備份 Web 服務(wù)器（ Backup Web），從而進(jìn)行備份。這兩臺(tái)服務(wù)器每日定時(shí) 運(yùn)行腳本將最新的數(shù)據(jù)庫備份文件導(dǎo)入到自身的數(shù)據(jù)庫。 ? 第一階段，可采用定時(shí)異地容災(zāi)機(jī)制 項(xiàng)目初期， 為了防止數(shù)據(jù)丟失， 可以通過 定期對(duì)數(shù)據(jù)進(jìn)行備份 包括：結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù) 。 39 圖 46. 圖分布式文件存儲(chǔ) （ 當(dāng) 系統(tǒng)磁盤 出現(xiàn)瓶頸的時(shí)候，可以采用 NAS 附件存儲(chǔ) 技術(shù)如 ：磁盤陣列形式 ；或者采用 SAN 網(wǎng)絡(luò)存儲(chǔ) 技術(shù) ，來解決） 容災(zāi)設(shè)計(jì) 所謂容災(zāi) 即，當(dāng)發(fā)生災(zāi)難的時(shí)候如：地震、海嘯等，淹沒了主機(jī)房的時(shí)候，項(xiàng)目還能正常運(yùn)行，或者受影響不大。只要增加一個(gè)或者多個(gè) Datanode 節(jié)點(diǎn)，就可以解決這個(gè)問題，而且那個(gè)節(jié)點(diǎn)出問題，都不會(huì)影響到項(xiàng)目正常運(yùn)作。從而解決，文件備份和容量無限擴(kuò)容的問題。 MYSQL SERVER 可以無限拓展，每個(gè) mysql server 都可以是如圖（ 圖 44）所示的主從庫。我們采用 amoeba 作為 MYSQL 分布式數(shù)據(jù)庫的中間件。 對(duì)于結(jié)構(gòu)化數(shù)據(jù)，在項(xiàng)目第二階段還是采用 MYSQL 數(shù)據(jù)庫的分布式集群方式來存儲(chǔ)。從中大家可以看出分布式和集群的關(guān)系，分布式是集群的擴(kuò)展。 集群大家可以理解為，一組服務(wù)器集中在一起實(shí)現(xiàn)一個(gè)業(yè)務(wù)。如圖（ 圖43）所示 圖 43. NGINX 負(fù)載均衡示意 ? 第二階段 分布式集群 當(dāng)項(xiàng)目運(yùn)營(yíng)發(fā)展到一定階段，用戶并發(fā)數(shù)和數(shù)據(jù)量暴增到已經(jīng)達(dá)到第一階段架構(gòu)瓶頸。在項(xiàng)目運(yùn)作初期，特別是 B2C 項(xiàng)目，如果沒有太多 SNS 交互功能，那一般非結(jié)構(gòu)化資源不會(huì)過多。在這里有一種簡(jiǎn)易的方法 采用 RAID 做多硬盤數(shù)據(jù)同步。 結(jié)構(gòu)化數(shù)據(jù)以 MYSQL 為例常用的集群技術(shù)，目前最常用的方式就是設(shè)置主 從（ masterslave）庫 ,并實(shí)現(xiàn)讀寫分離，保障數(shù)據(jù)安全的同時(shí)，提高了數(shù)據(jù)操縱的效率。這種方式，在項(xiàng)目初期，沒有大并發(fā)大量和大數(shù)據(jù)量的前期下。 項(xiàng)目數(shù)據(jù)安全設(shè)計(jì)可以分為兩個(gè)階段，根據(jù)項(xiàng)目運(yùn)營(yíng)的需求進(jìn)行調(diào)整。 從圖（ 8） 我們可以看到數(shù)據(jù)庫和文件系統(tǒng)的安全級(jí)別是最高的。 ? 只向 Web 服務(wù)器集群打開相應(yīng)的服務(wù)端口（由具體應(yīng)用決定且可配） ? （ 分布式 ） 數(shù)據(jù)庫集群和 (分布式 )文件系統(tǒng)集群 36 ? 安全級(jí)別最高，不可直接由外部登錄 ? 只向應(yīng)用服務(wù)器及資源服務(wù)器集群打開絕對(duì)必要的服務(wù)端口 數(shù)據(jù)安全設(shè)計(jì) 數(shù)據(jù)在 項(xiàng)目 中 處于核心地位，數(shù)據(jù) 分為 兩大類即：結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。 34 第四章 運(yùn)行環(huán)境 服務(wù)器 軟硬 環(huán)境 需求名稱 環(huán)境要求 硬件最低配置 CPU： 四核 （以上） 內(nèi)存：（ 4G 以上）、網(wǎng)卡：千兆 操作系統(tǒng) Ubuntu Server 應(yīng)用服務(wù)器 、 、 負(fù)載均衡 LVS(Linux Virtual Server) 數(shù)據(jù)庫 、 Oracle11g 分布式 文件服務(wù)器 分布式數(shù)據(jù)庫 ameoba 客戶端軟 硬 環(huán)境 需求名稱 環(huán)境要求 硬件最低配置 CPU： (以上 ) 內(nèi)存： 512MB（以上） 操作系統(tǒng) 適合 Windows 系列 、 Linux 系列 、 Mac OS 瀏覽器 適合 以上 ， 以上 ， 遨游 以上 ， 以上 版本 最小 屏幕區(qū)域 1024*768 35 第五章安全保障建設(shè) 服務(wù)分層隔離設(shè)計(jì) W e b服 務(wù) 器 集 群應(yīng) 用服 務(wù) 器 集 群資 源服 務(wù) 器 集 群分 布 式數(shù) 據(jù) 庫 集 群分 布 式文 件 系 統(tǒng) 集 群高 低（安全級(jí)別） 圖 41. 服務(wù)器分離設(shè)計(jì) 使用 linux 系統(tǒng)的 iptables 內(nèi)核級(jí)防火墻，可以根據(jù)需要禁止某些或開發(fā)某些端口的訪問。 檢貨任務(wù)的執(zhí)行： 檢貨任務(wù)的執(zhí)行，即在貨位上檢下產(chǎn)品的過程，需要注意兩點(diǎn)：所檢產(chǎn)品的正確，產(chǎn)品數(shù)量的正確。 檢貨路徑規(guī)劃： 檢貨路徑的 規(guī)劃，實(shí)際上就是地理信息學(xué)中的路徑規(guī)劃問題。播種法的最33 大優(yōu)勢(shì)在于， 多個(gè)訂單集中處理后，理論上需要檢的產(chǎn)品會(huì)均勻分布在整個(gè)庫房中，檢貨時(shí)只需要在庫房中遍歷一次，即可完成整個(gè)檢貨的過程。例如，一本書的上、下冊(cè)需要捆綁在一起，以共同銷售；有些商品（例如硬盤）需要重要裝箱，以用于零售；而手機(jī)等產(chǎn)品需要在?？ㄉ霞由w銷售商的印章，這一操作也有時(shí)候是放在收貨部分完成；更常見的，則是在商品上添加標(biāo)簽，以利于庫房?jī)?nèi)商品的管理和追蹤。若需要記錄商品序列號(hào)，則還需要逐個(gè)記錄。 收貨處理： 收貨處理主要分別兩塊：系統(tǒng)信息錄入和實(shí)物處理。對(duì)于不符合銷售標(biāo)簽的產(chǎn)品，要當(dāng)場(chǎng)拒收。 另外，在收貨時(shí)除了需要清點(diǎn)商品 外，還尤其需要注意商品是否符合銷售標(biāo)準(zhǔn)。點(diǎn)大包收貨的優(yōu)點(diǎn)除了交接效率高外，優(yōu)點(diǎn)還在于不需要送貨長(zhǎng)時(shí)間在場(chǎng)。逐個(gè)清點(diǎn)是最為常用的方式，優(yōu)點(diǎn)是清點(diǎn)準(zhǔn)確，可以當(dāng)面發(fā)現(xiàn)差異，當(dāng)面解決，但逐個(gè)清點(diǎn)的收貨效率低，收貨時(shí)間長(zhǎng)，且供應(yīng)商必須在場(chǎng)。 實(shí)物庫存數(shù)量 : 32 在實(shí)際收貨過程中，不可能做到完全按預(yù)約進(jìn)行，有些商品的銷售數(shù)量突然加大，可能需要緊急收貨；有的訂單雖然當(dāng)前銷售不多，剩余天數(shù)較多，但有可能是下一波促銷商品，很快就會(huì)產(chǎn)生銷售高峰；有的時(shí)候會(huì)出現(xiàn)影響收貨效率的意外情況，因此，在管理送貨預(yù)約時(shí)，不要一次性 將所有收貨能力全部安排掉，而要保留部分機(jī)動(dòng)力量，用于靈活安排。 供應(yīng)商送貨數(shù)量和品類： 收貨速度也受到供應(yīng)商所送商品的影響。會(huì)影響收貨能力的設(shè)備主要包括：收貨停車場(chǎng)大小、卸貨平臺(tái)數(shù)量、單據(jù)打印機(jī)數(shù)量、標(biāo)簽打印機(jī)數(shù)量等；而人力這一影響主要是所安排收貨人員的數(shù)量。若產(chǎn)品到了銷售淡期，每日銷售量減小，則會(huì)導(dǎo)致平均庫齡增大，產(chǎn)品滯銷。考慮單個(gè) Unit 的庫齡并沒有什么意思，但是某一個(gè) Item，某一個(gè) Category 的平均庫齡，卻真實(shí)地反應(yīng)了公司的庫存狀況。如何確定哪家優(yōu)先，哪家落后，即如何管理送貨預(yù)約系統(tǒng)，是一個(gè)很專門的話題，這個(gè)專題完了以后，再專門寫篇文章討論。 有效的預(yù)約管理方式： 庫房的接待能力是有限的，而且在短時(shí)間內(nèi)無法改變。 有效的采購信息溝通方式： 31 在做采購單時(shí)，采購在發(fā)送完采購郵件后，最好電話通知供應(yīng)商一下，提醒對(duì)方查看。 供應(yīng)管理 零售企業(yè)的庫存，都來自于供應(yīng)商。這對(duì)于 B2C 企業(yè)是極為必要的，國(guó)內(nèi)排名前 10 的幾家公 司，其管理的 SKU 數(shù)量一般都會(huì)超過 10 萬種，這樣大的數(shù)量，只能依靠電腦系統(tǒng)管理。 貨位管理 貨位系統(tǒng)是 WMS 中最為基礎(chǔ)的部分，貨位系統(tǒng)的設(shè)計(jì)，在很大程度上決定了 WMS 系統(tǒng)的表現(xiàn)，尤其是與庫存轉(zhuǎn)移相關(guān)的操作（包括上架、檢貨、理貨、盤點(diǎn)等，這實(shí)際上包括了庫房中的大部分操作）的效率和準(zhǔn)確性。 調(diào)撥中庫存： 庫存的調(diào)撥，必然會(huì)存在一段時(shí)間，庫存既不存在于調(diào)撥出庫房，也不存在于調(diào)撥入庫房。 30 調(diào)撥占用庫存： 電子商務(wù)系統(tǒng)需要設(shè)立一個(gè)以上的庫房。另外一些產(chǎn)品，銷售量少，庫存的管理難度大，只有當(dāng)產(chǎn)生訂單 后，才向供應(yīng)商采購。庫存被鎖定后，無法直接銷售，必須在解除鎖定后才能轉(zhuǎn)化為可銷售庫存。有的時(shí)候是因?yàn)樗袔齑嫒孔鹘祪r(jià)促銷的成本很高，有的時(shí)候是防止競(jìng)爭(zhēng)對(duì)手的惡意采購。 鎖定庫存： 在銷售中，經(jīng)常會(huì)使用的一種方式是降價(jià)，這一方式的效果會(huì) 非常好，成功的降價(jià)促銷可以在很短時(shí)間內(nèi)將商品一售而空，可銷售庫存直接轉(zhuǎn)化為訂單占用庫存。 不可銷售庫存： 在庫存管理中經(jīng)常會(huì)發(fā)現(xiàn)這樣的事情，產(chǎn)品由于某種原因，無法作正常銷售（例如包裝破損、性能故障、型號(hào)標(biāo)錯(cuò)等等）。 設(shè)立訂單占用庫存的原因在于：訂單的生成和庫房的發(fā)貨在時(shí)間上是異步的。若可銷售庫存數(shù)量 訂單產(chǎn)品數(shù)量，則通知前臺(tái)網(wǎng)站成功，否則會(huì)通知前臺(tái)庫存不足，提醒客戶。當(dāng)可銷售庫存 0，前臺(tái)網(wǎng)站會(huì)顯示商品可供購買，而一旦可銷售庫29 存 0 時(shí)，前臺(tái)網(wǎng)站則會(huì)顯示商品不可直接購買 。而對(duì)于零售型企業(yè)來講，沒有生產(chǎn)的過程，所有的貨品都是從上游采購后，存放在庫房，再給銷售給下游。充分了解庫存狀態(tài) ,確定適當(dāng)?shù)姆?wù)水平其集中表現(xiàn)在信息、供應(yīng)鏈運(yùn)作、供應(yīng)鏈的戰(zhàn)略與規(guī)劃三個(gè)方面。主要包括 :采用商業(yè)建模技術(shù)對(duì)企業(yè)的庫存策略、提前期和運(yùn)輸變化的準(zhǔn)確度進(jìn)行評(píng)價(jià) 。主要內(nèi)容如圖（ 圖 313）通過字面可以很好地理解這里就不詳細(xì)闡述。為決策支持提供有利的技術(shù)基礎(chǔ)。 27 圖 312. 訂單管理采集流程 決策支持 為決策提供有效數(shù)據(jù)支持，是 ECRM 的最主要作用和最終目標(biāo)，前面 3 個(gè)模塊主要是對(duì)數(shù)據(jù)的采集、挖掘和分析，通過數(shù)據(jù)采集引擎、數(shù)據(jù)挖掘引擎、數(shù)據(jù)分析技術(shù)、工作流引擎等基礎(chǔ)模塊 對(duì)數(shù)據(jù)進(jìn)行采集、加工最終得到的數(shù)據(jù)。通過數(shù)據(jù)分析技術(shù)分析用戶下單、退單行為。 訂單管理主要包含： B2C 平臺(tái)訂單管理、淘寶商城訂單管理、網(wǎng)絡(luò)分銷商訂單管理、物流跟蹤、信用控制 5 個(gè)功能模塊。 通過數(shù)據(jù)分析技術(shù)，對(duì)客戶的下單行為進(jìn)行分析，形成客戶信用控制體系。這也是當(dāng)前電子商務(wù)最為主要的訂單來源。這個(gè)有利于銷售人員（客服人員）與客戶建立長(zhǎng)效友好的關(guān)系，利于新產(chǎn)品的銷售。特別是新品上市，如何定位商品目標(biāo)群體，那么客戶漏斗可以為您解決這個(gè)問題如圖（ 圖311）。而客戶漏斗則在針對(duì)個(gè)性化商品去甄別客戶的過程中起到關(guān)鍵性作用的環(huán)節(jié) 系統(tǒng)通過客戶漏斗分析客戶行為集市、電子商務(wù)業(yè)務(wù)數(shù)據(jù)庫、訂單數(shù)據(jù)庫對(duì)用戶潛在需求進(jìn)行智能化分析，對(duì)客戶漏斗進(jìn)行初始化等級(jí)劃分。 25 圖