電商項目的一般架構

 電商的一般架構

 

一、 電商簡介

「電商」一詞是業內人士對電子商務的簡稱。

廣義上講，電子商務指的是通過電子手段進行的商業活動。通過使用互聯網等電子工具，使公司內部、供應商、客戶和合作夥伴之間，利用電子業務進行信息共享，實現企業間業務流程的電子化，配合企業內部的電子化生產管理系統，提高企業整體運作的效率。

簡單的說就是企業利用電子信息在互聯網上進行的一系列商務活動，就是電子商務。

最初的電商概念是由電子商務的先驅IBM（現在的關係型數據庫DB2就是這個公司的產品）公司於1996年提出電商的概念。我國在引進這些概念的時候都翻譯成了電子商務。

 

電子商務模式，就是指在網絡環境中基於一定技術基礎的商務運作方式和盈利模式。目前主要的電子商務模式有:

傳統的電商模式

      B2B(Business to Business)企業與企業之間的電子商務

      B2B電子商務是指以企業爲主體，在企業之間進行的電子商務活動。指進行商務交易的供需雙方都是商家(或企業、公司)，她(他)們使用了Internet的技術或各種商務網絡平臺，完成商務交易的過程。其代表是馬雲的阿里巴巴電子商務模式。B2B電子商務將會爲企業帶來更低的價格、更高的生產率和更低的勞動成本以及更多的商業機會。

      CtoC(Consumer to Consumer)消費者與消費者之間的電子商務

      C2C是指消費者與消費者之間的互動交易行爲，這種交易方式是多變的。C2C商務平臺就是通過爲買賣雙方提供一個在線交易平臺，使賣方可以主動提供商品上網拍賣，而買方可以自行選擇商品進行jingjia。其代表是淘寶的電子商務模式。

      C2B(Consumer to Business)消費者與企業之間的電子商務

      C2B是商家通過網絡搜索合適的消費者羣，真正實現定製式消費。

      未來的 F2C電商模式：產家-消費者

      產家按消費者需求直接定製銷售，我認爲這應該是一種趨勢吧。

B2C(Business to Customer)企業與消費者之間的電子商務

      B2C就是企業通過互聯網爲消費者提供一個新型的購物環境—— 網上商店，消費者通過網絡在網上購物、在網上支付。比較有代表性的例如亞馬遜的電子商務模式。由於這種模式節省了客戶和企業的時間和空間，大大提高了交易效率，特別對於工作忙碌的上班族，這種模式可以爲其節省寶貴的時間。

     當然還有其他模式，我就不一一講述了，你們可以查詢Google或者baidu，我們今天講的就是B2C模式下的網上商店的系統架構。我今天所講的這個互聯網電商架構，並不是很全，更偏向於項目開發和部署這一塊。

 

二、 相關概念解釋

 

在講這個之前我先介紹一下系統前臺、系統後臺、服務器集羣、分佈式、maven、svn、失敗轉移和負載均衡的概念。

1. 系統前臺

在這裏我以我正在做的廣西移動電子商城項目爲例（進行前臺演示）

系統前臺是面向網站訪問用戶的，即給訪問網站的用戶所展示的頁面，用戶可以通過系統前臺訂購廣西移動的終端營銷案，然後通過用戶中心查看訂單狀態、修改個人相關資料等。

主要功能模塊包括商品類型、商品檢索、首頁-頻道頁-單品頁、營銷專題、訂單支付、購物流程、客戶中心、幫助中心；

2. 系統後臺

在這裏我也是以我正在做的廣西移動電子商城項目爲例

系統後臺是面向廣西移動內部人員，通過一系列功能方便其管理運營廣西移動商城。主要功能包括商品管理、類目管理、營銷案管理、訂單管理、供貨商管理、配送商管理、會員管理、倉儲管理、對賬管理、互動管理、權限管理；

3. 業務拆分

   一般的電商網站根據業務屬性可以劃分爲產品子系統，購物子系統，

支付子系統，評論子系統，客服子系統，接口子系統（如短信等外部系統）

   根據這些子系統的重要性再劃分爲核心系統和非核心繫統。

如下圖：

    

 

業務拆分的作用：

第一、分爲子系統，這樣每個子系統或者服務器都可以由專門的團隊去負責，解決模塊之間的耦合以及擴展性問題，即各個子系統都是相對獨立的。

第二、拆分成子系統後，每個子系統都是單獨部署在服務器上的，如果集中部署在一個服務器上，當這臺服務器宕機了就會導致整個系統都不能使用。

4. 服務器集羣與分佈式

分佈式是指將拆分後的子系統模塊（業務）分佈在不同的服務器上，這就是通過提高單位時間內處理業務的個數來提升效率；而集羣指的是將幾臺服務器集中在一起，運行同一個子系統模塊（業務），這就是通過提高單位時間內某個業務功能模塊的執行的任務數來提升效率。分佈式中的每一個節點（拆分後的每個子系統模塊），都可以做集羣。但是集羣並不一定就是分佈式的。（圖1）

簡單說，分佈式是以縮短單個任務的執行時間來提升效率的，而集羣則是通過提高單位時間內執行的任務數來提升效率。

5.maven構建項目

Maven是一個採用純Java編寫的開源項目管理工具, Maven採用了一種被稱之爲Project Object Model (POM)概念來管理項目，那麼什麼意思呢？POM指的是工程對象模型，即把工程當做對象來進行管理，所有的項目配置信息都被定義在一個叫做POM.xml的文件中,通過該文件Maven可以管理項目的整個生命週期，包括清除、編譯，測試，報告、打包war、部署等等。

使用maven構建的項目有兩個特點：

----依賴管理

  簡單點說就是直接通過pom.xml配置文件把各個分散的項目自動的關聯起來，而不用我們程序員去手動地管理和維護這些項目（包括jar）之間依賴，這就是maven的第一個特點依賴管理。（圖2）

----項目自動構建

  項目構建是部署階段的事，主要是指把開發人員寫好的代碼進行打包（打成war，web項目只要打包成war包才能部署使用），當然這個過程不僅僅只是一個打包，其中包含了清除，編譯，測試，報告，這個過程就是項目構建過程。但是交給maven這些的動作包括package，maven都自動會幫你做好。而不用我們手動去做，這就是maven項目的第二個特點項目自動構建。 

先解決ABC三個模塊之間的依賴問題，然後使用父工程統一管理和維護這ABC三個模塊（聚合），只要在對應pom.xml文件中進行配置就行，不需要我們手動去維護這些關係。 

 

6.svn版本控制器

  簡單的說，就是管理我們寫好的代碼的，開發人員每寫完一些代碼都要把代碼往這個svn服務器中上傳，然後其他開發人員或者測試人員可以把代碼從svn服務器中拿到本地繼續開發另一個模塊或者測試。

7.失敗轉移和負載均衡

失敗轉移：簡單來說就是一個集羣中的某個服務器壞掉了，應該讓該臺服務器上的用戶轉移到其它的幾臺服務器上，這個過程對用戶來說，無需知道。

負載均衡：簡單來說就是多個用戶來併發訪問時，集羣內的服務器共同承擔用戶併發訪問的壓力，但不一定是平均分配。

上述二個概念，不光出現在WEB服務器領域，數據庫領域也是需要做失敗轉移和負載均衡的。

例如在oracle數據庫中

失敗轉移：一個羣集中的某個oracle服務器壞掉，應該讓該臺oracle服務器上的用戶轉移到其它的幾臺oracle服務器上。

負載平衡：多個用戶來併發訪問時，集羣內的oracle服務器共同承擔用戶併發訪問的壓力，但不一定是平均分配。

 

接下里進入正題：  

三、 項目開發架構

 

互聯網項目跟一般的web項目不一樣。（圖3）

我們的整個系統分爲前臺console（用戶訪問）和後臺（portal）（管理員管理），前臺是一個完整的系統（單個web項目），後臺也是一個完整的系統（單個web項目）。後臺我們叫console，前臺我們叫portal，一般項目的前後臺是放在一個web項目中的比如企業管理系統，爲什麼互聯網項目的前後臺要分開呢？這個都跟性能相關，企業管理系統的用戶很少，但是互聯網電商系統就不一樣了。

   首先互聯網中用戶分爲兩大類：一類是互聯網用戶，訪問我們的portal。還有一類是管理員，訪問我們的後臺console。管理員和互聯網用戶是不能有衝突問題的。

   前後臺分開原因：

互聯網用戶數量是很大的，但是如果前後臺放在一個系統中（一個web項目）中

那麼勢必會對管理員造成很大的影響。

第一點：----用戶數量很大，導致服務器宕機或者速度變慢，那麼管理員也沒法操作了，這個耦合度太高了。

第二點：----我們前臺是要做集羣部署的，集羣部署意味着我們的這個war包（前臺子系統）是需要部署到多臺機器上的（每臺機器上都部署一個前臺子系統），互聯網用戶訪問的不一定是哪臺機器，因爲互聯網用戶過多，所以我們使用集羣以達到負載均衡（負載均衡指的是每臺機器都分擔一部分用戶訪問壓力）的目地。而我們的後臺只是針對於管理員使用，所以後臺是沒有這個需求去做集羣部署的。

第三點：----我們的前臺是需要給互聯網用戶使用的，即項目是要發佈到外網上的，而我們的後臺只供管理員使用，只要在內網中使用就行了，不需要發佈到外網。

  所以綜上所述，在互聯網項目中我們是需要把互聯網用戶訪問的前臺和管理員使用的後臺分開來的。

 

maven項目特點：（圖3）

1.依賴管理     

console創建一個web工程，portal創建一個web工程，共用同一套數據庫。console端管理員添加商品到數據庫中，portal在數據庫中取出數據來進行展示。當然console端和portal端都可能會對數據庫中的數據進行增刪改查，其中就會有許多兩方都重複的操作。比如都需要查詢商品列表。這些重複的操作（dao和service）都是需要抽取出來作爲公用模塊的（不抽取的話寫兩份沒有必要），那麼怎麼抽取呢？

那麼在這裏面，我們需要再創建一個java工程，把這些重複性的操作模塊都放在

這個java工程中，並且單獨部署在一臺服務器上（暫定爲1臺，實際上是要做集羣的）。通過這個java工程和數據庫打交道。

 那麼我們的前臺和後臺兩個web項目都必須引用這個java工程來訪問數據庫。

那麼console的web項目和java工程項目，以及portal的web項目和java工程項目到底是如何關聯的呢？

 那麼這就涉及到了我們maven裏面的重要知識點，即依賴。java工程被console工程依賴，同時也被portal工程依賴。我們的java工程是可以打包成jar，只要我們把打成的jar放到console項目和portal項目中，就解決了這個依賴問題。但是這種拷貝的方式顯然是過於笨重。我們顯然可以使用另一種方式 即maven的依賴管理，使用maven的依賴管理功能我們就不用自己把 java工程打成jar拷貝到那兩個項目中了。

 解決了公共模塊的抽取問題之後，我們接下來還要構建一個文件服務器，一般項目文件上傳都是直接上傳到console端的，如果上傳到console中，那麼我們的portal如何取出console端的圖片等資源進行展示啊。你要讓portal去訪問console嗎？這顯然不現實，不然管理員後臺又要承受龐大的訪問量，導致速度變慢甚至宕機。所以我們要再搭建一個文件服務器（創建一個file  web項目）。

那麼console只要負責傳圖片到file服務器中，portal直接到file服務器中請求圖片就行了。這樣我們目前就有四個模塊了，這四個模塊就是我們拆分成的子系統，分別部署在四種（根據模塊重要性差異分配不同性能的服務器）不同的服務器上，這就是分佈式部署。四種服務器每一種都有若干臺相同的服務器，這就是集羣部署。

但是我們目前這四個模塊是散的，所以我們還需要創建一個pom（pom指的是工程對象模型，即這個pom web工程可以把散的四個工程分別當做對象來進行管理）項目（父工程），使用父工程web項目去管理這個四個散的模塊使他們有機結合起來，能夠相互調用並且進行信息交互。這個pom父工程除了管理這四個模塊並沒有其他功能。

 

 

Maven項目的第二個特點：（圖4）

2.項目構建clean ---->compile--->test---->package

我們以後到公司上屬於開發人員，假如你是測試人員，別人已經把代碼寫好了，那麼你接下來怎麼測試啊？首先我們開發人員把代碼寫好後要提交給svn（版本控制服務器上）接下里測試人員要把代碼拿（check out）到測試主機中。在這臺測試主機，我們要安裝跟線上環境一致的軟件。例如：linux，jdk，svn（客戶端），maven，商用服務器以及hudson（項目持續構建工具，下面再解釋），CRT。代碼拿下來以後先編譯，然後打成war包。一定要我們自己拿下來，編譯和打包嗎？不是的，這時候我們就可以使用maven的項目構建直接幫我們把代碼從svn拿下來編譯打成war。命令：mvn clean package。當然中間還有compile編譯和test測試環節這些maven自動幫我們做了。所以只要寫mvn clean package就行了。從代碼到war的過程就是項目構建過程

這不是開發時候的事，而是部署的時候的事。

/*

代碼打成war的要求：

               ----項目的目錄必須符合maven項目的規範

 

 

--src   

 -----main

 ----------java       --用來存放Java文件

 ----------resources   --用來存放資源文件

 -----test

 ---------java        --用來存放測試的Java文件

 ---------resources

 --target           --項目輸出位置,編譯完畢後自動生成

 --pom.xml

         

 */

 

四、 項目部署

  

代碼寫完了，部署的時候代碼有些地方還是需要要改動的。

   ----開發完了以後提交代碼到版本控制服務器svn中。

    ----代碼提交完成之後，由測試人員從版本控制器中下到本地主機中，打包進行測試

        --我們這邊使用hudson持續構建工具，它能夠跟svn，maven，jdk做一個整合

         整合之後，我們做項目構建的話更簡單，直接package（打成）war包，而不需要測試人員去下代碼（這裏跟svn做了整合），然後自己打包（因爲跟maven做了整合）。

        --hudson有兩種版本，一種是以war包形式存在的，一種是以jnt內置服務器的形式存在的

         hudson以web瀏覽器的形式訪問的，然後在網頁上進行項目任務的構建。         

        --使用hudson構建完任務之後，把生成的可部署的war包扔到我們的商用服務器（商用服務器是項目最終的運行環境，測試必須放在實際運行環境中）中由測試人員進行測試，這裏需要注意測試的oracle數據庫和開發的oracle數據庫是不一樣的，如果都一樣的話，開發人員的數據庫數據是會變的，而測試人員需要的是不能變動的數據，所以測試人員就沒法測試了。

        

----構建項目之後進行實際部署（圖5）

       -- 後臺（console）部署的話使用單機模式就行了，即只需要一臺主機，因爲後臺本身用戶量就不會有多大，都是管理人員，既然用戶量不大的話這個併發量就更小了，充其量達到一百就不錯了。

            主要是前臺（portal），前臺的用戶訪問量是非常大的。

       -- 前臺（portal）是互聯網用戶訪問的，所以併發量會很大，所以要考慮你這個服務器對於併發量的支持問題。

           所以前臺部署到單個服務器上是不夠的，單個服務器支持的併發量是非常有限的，所以我們這邊就要求後臺做集羣部署（上面講過）。

           我們這邊舉個例子，比如三臺服務器， 分別放着前臺（portal）做集羣，那麼這三臺服務器的ip是不一樣的，分別爲192.168.1.102,192.168.1.103，192.168.1.104。這裏注意了，我們的服務器一般都使用linux或者unix系統的。以上三臺服務器的三個ip都是內網ip。那麼有些人就奇怪了，內網的東西如果被外網訪問到，這裏我們在講一下反向代理的概念。首先解釋一下什麼叫代理，代理是什麼，代理就是有人替你做些事情，比如中介，也是代理啊。

           代理分爲正向代理和反向代理。

           正向代理：我們從內網訪問外網所經過的代理服務器，我們使用ipconfig查看到的一般是內網ip，但是我們從內網訪問外網的話是需要代理服務器的。但是我們現在的情況是要讓外網的互聯網用戶訪問到我們內網的服務器，那麼外網直接訪問內網是無法訪問的。這時候就需要藉助代理服務器，得通過代理服務器爲我們做一個代理，通過代理服務器去訪問內網，這就是反向代理。即反向代理就是讓外網訪問內網的。如果現在我們的三臺服務器是外網ip的話，我們直接就可以訪問了，多方便，那爲什麼要使用內網ip呢？因爲對於我們服務器的安全性大大提高了，不會輕易被攻擊。那麼這臺代理服務器的ip肯定是外網ip。

           

           正向代理：從內網訪問外網所經過的代理服務器

           反向代理：從外網訪問內網所經過的代理服務器

           

      現在我們在市面上用的反向代理服務器有Apache的HTTP服務器

      但是現在還有一個非常火的，如日中天的一個服務器，即NGINX，這個服務器現在也在大量的使用，因爲這個服務器的性能非常高，支持的併發量也很大。現在很多互聯網項目都是用nginx，官方發佈數據是三臺nginx在一瞬間能夠支撐5萬的併發量但實際只能夠支撐2萬。

      nginx服務器有兩種能力，第一種就是反向代理，剛纔已經講過了。第二種是負載均衡的能力。第三種是靜態文件處理能力，這個我們接下來具體講解。

 

我們來看一下我們的部署圖，我們圖中的nginx起到一個反向代理的作用，這是他的一個特點。那麼接下來就是nginx負載均衡的能力。

當互聯網中的請求來的時候，我們可以配置規則，即我們服務器只接收.do或者.html等以其他後綴結尾的請求。當一個.do請求過來之後，nginx給你攔截下來，攔截下來之後，他自己並不去處理這個請求，而是幫你轉發到後臺集羣的這幾臺服務器上，那麼到底轉發到哪臺呢，那麼可以在nginx上做一些配置，即做一些權重的配置。

     什麼叫權重呢？就是給我們這裏的三臺服務器分配不同的壓力

     比如，給第一臺分配30%的壓力，給第二臺分配50%的壓力，給第三臺分配20%的壓力，具體得看你這三臺服務器的配置所支持的能力，如果他們的配置都是差不多的話，你可以平均分配壓力。

     這邊nginx也很智能，他不會把所有請求都分擔在一臺機器上。如果說都分配在一臺服務器上，而另外兩臺閒置，這就是明顯的分配不均。這就是nginx支持集羣並且能夠做負載均衡的能力。我們在使用nginx做集羣和負載均衡之前使用的原始方法是DNS輪詢，DNS輪詢也能起到一個集羣作用，但是無法做到負載均衡。DNS老早之前已經被淘汰了，爲什麼呢，就是因爲因爲DNS輪詢會導致分配不均，分配不均的話就會導致一臺機器壓力很大，其他機器閒置，明顯沒有起到負載均衡的作用

     nginx主要就是在服務器集羣的基礎之上起到負載均衡的作用，讓用戶訪問夜裏平均分配到這些服務器上來，這樣的話我們後臺的處理能力明顯得就提升上來了。那麼實際上在nginx前端還有一個東西叫F5，他是一個硬件的負載均衡器，這個硬件負載均衡器能夠支持非常大的併發量，互聯網用戶只要訪問F5這一個就行了，那麼在F5上把請求往nginx上分發，但是F5價錢不菲，幾十萬到幾百萬之間。但是我們這邊不使用F5直接訪問nginx也是可以的，但是有一個問題叫三點故障問題，即如果我們部署nginx服務器的這臺機器宕機了，那麼就沒法訪問我們的後面的三臺服務器了。相當於nginx是一扇大門一樣，門關了，外面的人也就沒法進來了。我們很容想到，可以多部署幾臺nginx服務器嘛，是的，在大型的互聯網項目中，一般nginx都有兩臺，即雙機模式，但是用戶進來之後該訪問哪臺呢？這就要我們使用F5做負載均衡，去管理這兩天nginx服務器，F5的負載均衡指的是對nginx的負載均衡即給nginx分配用戶訪問壓力，這樣一來一臺nginx服務器出現故障了，F5還可以支配另一臺nginx服務器應對用戶訪問，避免我們這裏的三點故障即一臺nginx宕機了，整個項目就無法運行了。所以使用F5對nginx做負載均衡，一臺nginx服務器宕機了還有另一個臺可以使用，這對於來訪問互聯網用戶是沒有影響的，就不會出現問題。F5是硬件負載均衡器穩定性是很高的。

    那麼兩臺nginx做負載均衡，他有兩種策略。

       1.其中有一臺作爲備機，只有當另一臺運作的機器出現故障了，那麼這臺才啓用

       2.兩臺機器都啓動，做負載均衡和反向代理。

       

     我們還可以把後臺的一整個模塊拆分成幾個小模塊（war包），然後把每個小模塊分別部署到單個機器上（肯定不是單個機器上，這裏是要做集羣的），這就是分佈式部署，然後通過另一臺備用的nginx爲這幾個小模塊做負載均衡，不是備用的還是爲原來的幾個整體的模塊做負載均衡。如果在某個時間，對這幾個拆分了的特定的小模塊業務訪問量很大，就可以單獨訪問備用的nginx服務器及其後面的web服務器。這樣的話，我們整個這樣的部署，就明顯分擔了更多的壓力了。

 

那麼以上結構有一個問題：

      模擬情景：某個用戶想要從我們這個網站下載資源，但是他必須先登錄。

     所以用戶輸入信息點擊登錄之後，登錄請求就會通過F5硬件負載均衡器過來的，F5把請求交給其中一臺nginx，然後nginx再把請求發給我們的前臺服務器1。假設用戶通過校驗，那麼這臺1服務器會產生一個session存儲該用戶的登錄信息，接下來該用戶就可以下載資源了，當點擊下載的時候下載資源請求再次通過F5硬件負載均衡器過來，F5把請求再分發給其中一臺nginx，但是1服務器已經很忙了，所以這臺nginx把我們的下載請求交給了前臺服務器2處理，但是我們的前臺服務器2他並沒有存儲了該用戶信息的session，

當服務器2收到這個下載請求時首先會判斷你有沒有登錄（找存儲了用戶信息的session），很明顯你是無法從服務器2中順利地下載資源的。那該怎麼辦呢？

       解決方法

      1.最原始的解決方法是session的共享或者叫session的複製，那麼什麼叫session共享呢？就是當一臺服務器中有session了，那麼同時也會給其餘的服務器複製相同的一份session，讓這些服務器有同樣的session。但是這種方法有一個問題，在session複製的時候就會產生一個性能的問題，如果用戶數量越多session就是複製得越頻發，還有就是你服務器集羣的數量越多session複製得也越多。本質上就是你的使用量越多，session的複製也就迅速增長，我們把這個叫做session複製風暴，他會對我們的服務器性能產生很大的影響，所以這種策略我們是不採用的

 

     2.第二種方法是最合適的，但是我們還需要一臺服務器， 這臺服務器我們需要部署非關係型數據庫redis， redis是一個用c語言編寫開源的key-value存儲系統（nosql），學過java的應該都知道java集合這章中的map吧，map也是key-value（鍵值對）的形式存儲數據的吧，redis和這個是類似的。屬於非關係型數據庫。現在redis是一個比較火的技術，在redis中他可以把session做一個接管，也就是redis可以和我們的前臺這些服務器做一個整合，那麼如何整合呢？回到我們上面假設的原始情景中，當互聯網用戶輸入信息點擊登錄後，我們的請求經過F5和nginx來到前臺服務器1，此時服務器1中當前用戶session不是服務器1自己創建和管理的而是交給redis服務器來創建和管理。當用戶再次點擊下載鏈接時，請求通過F5和nginx被傳到了服務器2上，然後服務器2從redis服務器中獲取對應的session，判斷當前發送請求的用戶是否已經登錄，這樣的話這個問題就很好的解決了。也不會出現session複製風暴的問題。Session服務器也是可以做集羣和分佈式部署的（包括redis數據庫分頁，讀寫分離，主從複製。主負責寫，從負責讀）。

 

接下來講的是nginx的靜態文件處理能力：靜態文件處理,如果我們的靜態頁面即給訪問者瀏覽的頁面放在前臺服務器上，那麼前臺服務器處理靜態頁面的能力是不夠的

所以我們不能把靜態頁面發佈到前臺服務器（portal）中，我們得發佈到nginx服務器上。那麼發佈到nginx的時候我們是從管理員後臺（console）服務器進行發佈的，那麼我們如何在從管理員後臺（console）服務器把靜態頁面和圖片發佈到nginx服務器上呢？我們之前做發佈的時候是使用webservice來做的，那之前webservice是部署在portal裏的，現在如果要把靜態頁面和圖片發佈到nginx上，就需要在nginx部署webservice，但是nginx是無法部署webservice的。我們要在console管理員後臺和nginx之間做一個靜態化發佈

 第一種方案：使用共享服務器rsingle，console和nginx兩臺機器上，都有 一個文件夾相互做同步，只要console把靜態文件放到自己機器的此文件夾中同時也會同步到對應的nginx機器的文件夾上。

第二種方案：在nginx安裝一個tomcat服務，部署webservice服務war包，這個war的功能是專門用來接收靜態文件的，部署之後就讓這個tomcat來接收靜態文件和圖片。這個tomcat中得部署我們的webservice服務war包那麼webservice服務我們發佈了之後console就會調用這裏面的服務從而把console中靜態文件發送到nginx當中，專門放在一個存儲靜態文件的文件夾中，這樣的話當互聯網用戶來訪問的時候，當請求來到nginx的時候，nginx就會判斷，當前請求是.html或者.jpg或者.css結尾的，即請求靜態資源的，就不會再把該請求發送給前臺服務器中去處理而是直接在自己nginx服務器上處理。

   

  總結： 項目中nginx服務器的作用

1.反向代理：從外網訪問內網所經過的代理服務器，攔截.do或者其他結尾的請求，做集羣（目的：負載均衡），轉發給前臺服務器。

2.負載均衡

3.  靜態文件處理能力。

五.數據庫集羣和分佈式

下面的簡單講解一下：

我這裏還沒有講數據庫的集羣和分佈式包括主從複製、讀寫分離

大型網站需要存儲海量的數據，爲達到海量數據存儲，高可用

，高性能一般採用冗餘的方式進行系統設計，本質上其實就是通過空間換時間，比如原來一臺數據庫服務器既負責讀也負責寫，現在讀單獨放在一臺服務器上，寫也單獨放在一臺服務器上，提高了讀寫效率。

一般有兩種冗餘的系統設計方式：讀寫分離和分庫分表

讀寫分離：一般解決讀比例遠大於寫比例的場景，可採用一主一備，一主多備或多主多備方式。

 讀寫分離：

   讀寫分離簡單的說是把對數據庫讀和寫的操作分開對應不同的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕io壓力。主數據庫提供寫操作，從數據庫提供讀操作，其實在很多系統中，主要是讀的操作，例如你瀏覽淘寶一般是看得多，寫得少吧。當主數據庫進行寫操作時，數據要同步到從的數據庫，這樣纔能有效保證每個數據庫的完整性。

  主備：

這一般是數據庫的安全策略，對於一些安全性要求比較高的系統，數據庫通常是由主服務器和備份服務器組成，主備同時運行，主服務器有數據改動後，立刻會同步到備份服務器。所以在日常運維工作中，爲了防患於未然，經常會進行主備切換，就是把生產對接的服務器從主數據庫切換到備份庫上，使用備份庫運行一段時間，看看備份庫運行是否正常，數據是否正確等。
切換的操作只需將連接池中，數據庫服務器的ip換成備份庫ip就可以了。

 

數據庫分庫和表拆分（分庫分表）：

1. 業務拆分後：每個子系統需要單獨的庫

2. 如果單獨的庫太大，可以根據業務特性，進行再次數據庫拆分，跟我們上面講的拆分是類似的，比如我們可以把數據庫分爲商品分類庫，產品庫；

3. 分庫後，如果表中有數據量很大的，則進行表拆分，一般可以按照id，時間等進行表拆分

4. 在分庫，分表的基礎上，進行讀寫分離

 

底層拆分的數據庫進行分佈式部署和集羣部署。

 

圖示：以產品子系統爲例