當前位置:首頁 » 網頁前端 » 典型web應用分層
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

典型web應用分層

發布時間: 2023-06-17 12:19:13

Ⅰ Web應用程序為什麼分層開發

分層不是為了代碼的化簡,實際上分層之後代碼只會增加。
分層是為了整個應用的設計和維護。
如果你要開發一個簡單且永久不變的應用,當然可以將一堆代碼放在一起。但現在的技術發展和用戶需求的變化如此之快,誰能保證開發一個系統之後可以一直用下去。當你想修改程序的一些功能的時候,發現自己編寫的東西全部集中在一個文檔里,太雜了,牽一發而動全身,消耗太大了。同樣,設計的時候要考慮所有的邏輯還要考慮視圖在內,不亂才怪。
分層之後,上一層只需要調用下一層提供的介面就能使用下一層提供的服務,而下一層對上一層不具有依賴性,增加代碼的可測試性和可重用行。
web應用分層方式很多,一般分為表現層,業務邏輯層和數據訪問層,如果要改變視圖就直接在表現層操作,不用修改另外的兩個層。而且不同層可以教給不同人員去開發,再整合一下就可以了,是不是清晰很多了呢

Ⅱ web應用包括什麼

常見的計數器、留言版、聊天室和論壇BBS等,都是Web應用程序。但是,這些應用程序相對簡單,Web應用程序的真正核心主要是處理資料庫, 管理信息系統(MIS)是此體系結構的最典型應用。

Web應用程序由執行特定任務並通過Web向外界公開服務的各種Web組件組成。 在實際應用程序中,Web應用程序由多個Servlet,JSP頁面,HTML文件和圖像文件組成。 所有這些組件相互協調,以為用戶提供一套完整的服務。

(2)典型web應用分層擴展閱讀:

例如,在網上商店中,用戶反復觀察和選擇商品,購買商品,瀏覽一系列網頁,收集所需信息,支付相應費用,最後下訂單,也可以是「軟體升級向導」,指導用戶完成下載和安裝新軟體的過程,也可以是基於Intranet的報價或銷售報告生成工具。

所有這些均不同於「標准」的Web網站。 常規網站使用一系列菜單或導航欄在預定路徑中漫遊該網站。 但是,成為Web應用程序不僅僅是下級控制的導航器。 在網站上自由漫遊時,可以進行無狀態和匿名訪問,但是通常不接受Web應用程序。

Ⅲ web應用有哪些

常見的計數器、留言版、聊天室和論壇BBS等,都是Web應用程序,不過這些應用相對比較簡單,而Web應用程序的真正核心主要是對資料庫進行處理,管理信息系統(Management Information System,簡稱MIS)就是這種架構最典型的應用。

MIS可以應用於區域網,也可以應用於廣域網。基於Internet的MIS系統以其成本低廉、維護簡便、覆蓋范圍廣、功能易實現等諸多特性,得到越來越多的應用。

web開發就是我們說的做網站,它分為網頁部分,和邏輯部分也就是我們說的前台與後台,前台負責與用戶的交互,顯示數據,用到HTML顯示數據,CSS控制樣式,JS編寫復雜交互。後台編寫處理這些邏輯的程序。可以用C#,java,vb.php等語言。

(3)典型web應用分層擴展閱讀:

一、優點

1、網路應用程序不需要任何復雜的「展開」過程,你所需要的只是一個適用的瀏覽器;

2、網路應用程序通常耗費很少的用戶硬碟空間,或者一點都不耗費;

3、它們不需要更新,因為所有新的特性都在伺服器上執行,從而自動傳達到用戶端;

4、網路應用程序和伺服器端的網路產品都很容易結合,如email功能和搜索功能;

5、因為它們在網路瀏覽器窗口中運行,所以大多數情況下它們是通過跨平台使用的 (例如Windows,Mac,Linux等等)

二、應用擴展

信息化,互聯網,移動化,雲計算的不斷發展,使得公司的業務需求越來越多。

因此很多公司的頁面因為缺乏高度的可擴展性,因而流失了大量的用戶。如果你不希望重蹈這些公司的覆轍,你就急需要找到一條可以擴展自己web應用的途徑。

對Web應用來說,擴展能力很重要,隨著用戶群和工作量的增加,處理器在增加,它應該能夠進行擴展。對於Java應用來說,擴展更復雜,不只是簡單的購買和安裝20個新的處理器就可以的。

然而,Java平台能夠也確實支持應用擴展,通過外圍設備語言,例如Scala、Clojure和Groovy。利用JAVA編程語言,開發者很難使JAVA應用進行線性擴展。

另外,按需的雲計算本質使得可擴展的Web應用程序融入到了各種規模的業務中。進入到這個領域不能說沒有障礙,即使是很小的公司得到這類計算能力也很難,而且數據存儲一度曾經只適用於企業級用戶。

這使你得到想要的伺服器空間,不僅比以往更便宜,而且更容易。雲計算可以訂購更多的資源,而且就像行車路過訂購快餐一樣方便。

Ⅳ 在web應用的分層結構中,事務控制應該處於哪一層

Action層做控制器;Service層做業務邏輯處理;Dao層做資料庫處理。
Service層處理方法中用到多個Dao實例是常見的,所以當然要把事務控制擱在這一層。

前端頁面有哪三層構成,分別是什麼作用是什麼

最准確的網頁設計思路是把網頁分成三個層次,即:結構層、樣式層、行為層。

HTML:結構層

網頁的結構或內容層是該頁面的基礎HTML代碼。正如房屋的框架為房屋的其他部分構建了一個堅實

的基礎,HTML的堅實基礎創建了一個可以在其上創建網站的平台。

結構層用於存儲客戶想要閱讀或查看的所有內容。HTML結構可以包含文本和圖像,它包括訪問者用

於瀏覽網站的超鏈接。這是在符合標準的HTML5中編碼的,可以包括文本,圖像和多媒體(視頻,音頻等)。

網站內容的每個方面都應該在結構層中表示。這允許關閉JavaScript的客戶或無法查看整個網站的

CSS訪問許可權的客戶(如果不是所有功能)。

CSS:樣式層

該層指示結構化HTML文檔如何看待網站的訪問者,並由CSS(層疊樣式表)定義。這些文件包含有

關如何在Web瀏覽器中顯示文檔的樣式說明。樣式層通常包括基於屏幕大小和設備更改站點顯示的

媒體查詢。

網站的所有視覺樣式都應位於外部樣式表中。您可以使用多個樣式表,但請記住,每個CSS文件都需

要HTTP請求才能獲取它,從而影響站點性能。

JavaScript:行為層

行為層使網站具有交互性,允許頁面響應用戶操作或基於一組條件進行更改。JavaScript是行為層最

常用的語言,但CGI和PHP也經常被使用。

當開發人員引用行為層時,大多數都是指在Web瀏覽器中直接激活的層。您可以使用此圖層直接與

DOM(文檔對象模型)進行交互。在內容層中編寫有效的HTML對於行為層中的DOM交互非常重

要。在構建行為層時,應該像使用CSS一樣使用外部腳本文件來優化速度和性能。

(5)典型web應用分層擴展閱讀:

分層的一些好處是:

  • 共享資源:當您編寫外部CSS或JavaScript文件時,站點上的任何頁面都可以使用該文件。如果

您需要對該文件進行更改,也許更新網站上的某些排版樣式,則使用該樣式表的每個頁面都會得到

更改。沒有必要單獨編輯網站的每個頁面,這對於大型網站來說可能是一項艱苦的任務。

  • 下載速度更快:首次由客戶下載腳本或樣式表後,Web瀏覽器會對其進行緩存。由於這些共享

資源現在包含在瀏覽器的緩存中,因此瀏覽器中請求的其他頁面載入速度更快,從而提高了整體頁

面速度和性能。

  • 多人團隊:如果您有多個人同時在網站上工作,您可以使用允許文件簽入和簽出的系統,以確

保每個人都使用最新版本。如果樣式和行為與結構文檔交織在一起,那就更難了。

  • 搜索引擎優化:一個明確分離風格和結構的網站可能會對搜索引擎有更好的表現,因為它們可以更有效地抓取內容並理解頁面而不會陷入視覺風格和行為信息。

  • 輔助功能:外部樣式表和腳本文件更易於人們和瀏覽器訪問。屏幕閱讀器等軟體可以更輕松地

處理結構層中的內容,而無需處理無論如何都無法使用的樣式。

  • 向後兼容性:使用單獨的開發層設計的站點更可能向後兼容,因為無法使用某些CSS樣式或禁

用了JavaScript的瀏覽器和設備仍然可以查看HTML。然後,您可以使用支持它們的瀏覽器的功能逐

步增強您的網站。

Ⅵ Web工程的分層開發中,每一層的含義和作用是什麼

通俗的講,web工程一般分為三層:視圖,控制和持久層。視圖層自然就是展示給用戶的,一般是jsp或者html頁面等。控制層是控制業務邏輯的,就是具體的實現,持久層當然就是資料庫了。

Ⅶ Web資料庫的層次體系

當前,Internet/Intranet技術發展異常迅速,越來越多的資料庫應用軟體運行在Internet/Intranet環境下。在此之前,資料庫應用系統的發展經歷了單機結構、集中式結構、客戶機/伺服器(C/S)結構之後,隨著Internet的普及,又出現了瀏覽器/伺服器(B/S)結構與多層結構。在構造一個應用系統時,首先考慮的是系統的體系結構,採用哪種結構取決於系統的網路環境、應用需求等因素。
客戶機/伺服器結構
1.二層C/S結構
二層C/S結構是當前非常流行的資料庫系統結構,在這種結構中,客戶機提出請求,伺服器對客戶機的服務請求做出回答。它把界面和數據處理操作分開在前端(客戶端)和後端(伺服器端),這個主要特點使得C/S系統的工作速度主要取決於進行大量數據操作的伺服器,而不是前端的硬體設備;同時也大大降低了對網路傳輸速度的要求,因為只須客戶端把服務請求發送給資料庫伺服器,資料庫伺服器只把服務結果傳回前端。
在設計時,對數據可能有如下不同的處理形式。
(1)在處理時,客戶機先向伺服器索取數據,然後釋放資料庫,即客戶機發出的是文件請求,在客戶機端處理數據,最後將結果送回伺服器。這種處理方式的缺點很明顯:所有的應用處理都在客戶端完成,這就要求客戶端的計算機必須有足夠的能力,以便執行需要的任何程序。更為糟糕的是,由於所有的處理均在客戶端完成,每次運行時都要將文件整體傳送到客戶端,然後才能執行。如:Student表中有30 000條記錄,客戶端發出命令:
Select * From Student Where Sno='200101'
這條命令將要求伺服器將Student表中的所有記錄傳送到客戶端,然後在客戶端執行查詢,結果只用到一條記錄;如果查詢的記錄不存在,網路傳輸的數據實際上是無 用的。如此大的數據傳輸量是不可想像的。因此,人們提出了在伺服器中能夠執行部分代碼的客戶機/伺服器結構。
(2)在處理時,客戶機接受用戶要求,並發給伺服器;在伺服器端處理用戶要求,最後將結果傳回客戶機顯示或列印。這種處理方式網路通信量較小。客戶機向伺服器發出的是處理請求,而不是文件請求,處理請求中的代碼在伺服器端執行後向客戶機傳送處理後的結果。
這樣,為了特定任務,客戶機上的程序和伺服器上的程序協同工作:客戶機端的代碼用於完成用戶的輸入輸出及數據的檢查,而伺服器端的代碼完成對資料庫的操作。
客戶機/伺服器結構的另一個主要特點在於軟體、硬體平台的無關性。資料庫伺服器上的資料庫管理系統集中負責管理數據,它向客戶端提供一個開放的使用環境,客戶端通過資料庫介面,如ODBC(開放資料庫連接)和sql語言訪問資料庫,也就是說,不管客戶端採用什麼樣的硬體和軟體,它只要能夠通過網路和資料庫介面程序連接到伺服器,就可對資料庫進行訪問。
在客戶機/伺服器結構中,常把客戶機稱為前台,而把伺服器端稱為後台。前台應用程序的功能包括用戶界面、接收用戶數據、處理應用邏輯、向後台發出請求、同時接收後台返回的結果,最後再將返回的結果按一定的格式或方式顯示給用戶。而後台伺服器則負責共享外部設備、存取共享數據、響應前台客戶端的請求並回送結果等工作。前台的應用程序和數據一般是用戶專用的,而後台的數據和代碼是所有用戶可以共享的。
由於資料庫伺服器不僅要管理共享數據,保證數據的完整性,還要執行一部分代碼,完成客戶端的一些處理請求,所以對用於伺服器的計算機提出較高的要求。最好要採用一台專用的伺服器,有較快的處理速度,有大容量的硬碟和內存,支持磁帶等大容量的存儲設備。
上面講的客戶機/伺服器結構將應用分在了客戶機、伺服器兩級,稱其為兩層客戶機/ 伺服器結構。總之,兩層C/S結構的基本工作方式是客戶程序向資料庫伺服器發送SQL請求,伺服器返回數據或結果。
這種C/S結構有兩種實現方式,一種是客戶來完成表示部分和應用邏輯部分,而伺服器完成數據訪問部分,這種情況是以客戶為中心的,適用於應用相對簡單、數據訪問量不是很大的情況。另一種是以伺服器為中心的,把一些重要的應用邏輯部分放到伺服器上,這樣可充分利用伺服器的計算能力,減少網路上需要傳送的數據。通常以存儲過程和觸發器的形式出現,但存儲過程都依賴於特定資料庫,不同資料庫之間很難移植,而三層C/S結構可以很好地解決這個問題。
注意:觸發器(trigger)是資料庫系統中,一個在插入、刪除、修改操作之後運行的記錄級事件代碼。不同的事件可以對應不同的動作。通常有3種類型的觸發器:INSERT觸發器、DELETE觸發器和UPDATE觸發器。
2.三層C/S結構
由於兩層結構的客戶機/伺服器系統本身固有的缺陷,使得它不能應用於一些大型、結構較為復雜的系統中,故出現了3層結構的客戶機/伺服器系統,將兩層結構中伺服器部分和客戶端部分的應用單獨劃分出來,即採用「客戶機—應用伺服器—資料庫伺服器」結構(如圖1-8所示)。典型的資料庫應用可分為三部分:表示部分、應用邏輯(商業邏輯)部分和數據訪問部分,三層結構便是對應於這三部分。
其中,應用伺服器和資料庫伺服器可位於同一主機,也可位於不同主機。客戶機是應用的用戶介面部分,負責用戶與應用程序的交互,運行在客戶機端的軟體也稱為表示層軟體。應用伺服器存放業務邏輯層(也稱為功能層)軟體,是應用邏輯處理的核心,實現具體業務。它能響應客戶機請求,完成業務處理或復雜計算。若有資料庫訪問任務時,應用伺服器層可根據客戶機的要求向資料庫伺服器發送SQL指令。應用邏輯變得復雜或增加新的應用時,可增加新的應用伺服器。資料庫伺服器便是用來執行功能層送來的SQL指令,完成數據的存儲、訪問和完整性約束等。操作完成後再通過應用伺服器向客戶機返回操作結果。
瀏覽器/伺服器結構
隨著Internet技術和Web技術的廣泛應用,C/S結構已無法滿足人們的需要。因為在典型C/S體系中,通常為客戶安裝前端應用程序的做法已不再現實,並且限制客戶端工作環境只能基於Windows、Macintosh或UNIX等操作系統也不切實際。於是基於瀏覽器/伺服器結構(Browser/Server)的系統應運而生。
採用B/S結構後,在客戶端只需安裝一個通用的瀏覽器即可,不再受具體操作系統和硬體的制約,實現了跨平台的應用。
基於B/S結構的典型應用通常採用三層結構:「瀏覽器—Web伺服器—資料庫伺服器」,B/S模式的工作原理是:通過瀏覽器以超文本的形式向Web伺服器提出訪問資料庫的請求,Web伺服器接受客戶請求後,激活對應的CGI程序將超文本HTML語言轉化為SQL語法,將這個請求交給資料庫,資料庫伺服器得到請求後,進行數據處理,然後將處理結果集返回給CGI程序。CGI再將結果轉化為HTML,並由Web伺服器轉發給請求方的瀏覽器,如圖1-9所示。
在B/S模式中,客戶端的標准配置是瀏覽器,如IE;業務功能處理由獨立的應用伺服器處理,Web伺服器成為應用處理的標准配置;數據處理仍然由資料庫伺服器處理。
從本質上講,B/S結構與傳統的C/S結構都是以同一種請求和應答方式來執行應用的,區別主要在於:C/S是一種兩層或三層結構模式,其客戶端集中了大量應用軟體,而B/S是一種基於超鏈接(HyperLink)、HTML、Java的三級或多級C/S結構,客戶端僅需單一的瀏覽器軟體,是一種全新的體系結構,解決了跨平台問題。到目前,這兩種結構在不同方面都有著廣泛的應用。雖然C/S結構在Internet環境下明顯不如B/S結構具有優勢,但它在區域網環境下仍具有優勢。
Internet/Intranet信息系統的多層體系結構
多層結構應用軟體與傳統的兩層結構應用軟體相比,有可伸縮性好、可管理性強、安全性高、軟體重用性好等諸多優點,如何在Internet/Intranet環境下構建應用軟體體系結構就成為一個非常重要的問題,也是現今軟體體系研究的一個新熱點。
目前各種技術層出不窮,如最初的靜態HTML頁面、簡單的CGI網關程序、Java Applet程序,現在的ASP等Web資料庫技術,還有動態的Java在線游戲及PHP技術等。
實際上,多層的概念是由Sun公司提出來的。Sun公司提出的多層應用體系包括4層:客戶層、頂端Web服務層、應用服務層和資料庫層。其中頂端Web服務層是Sun公司多層體系結構中非常重要的一層,它主要起代理和緩存的作用。頂端Web伺服器的作用是緩存本地各客戶機經常使用的Java Applet程序和靜態數據,通常被放置在客戶機所在的區域網內,起到一個Java Applet主機(向Web瀏覽器傳送Java Applet程序的計算機)和訪問其他服務的代理作用。與普通代理伺服器的作用相同。構建多層結構應用軟體時,選用Java平台是一個很好的選擇,因為它跨越各應用平台。總之,在Java平台上構建多層應用軟體體系代表著今後Internet/Intranet應用的趨勢。

Ⅷ 為什麼JavaWeb項目要分層

首先讓我們坐著時光機回到n年前的web開發。
那個時候最早都是靜態的html頁面,後來有了資料庫,有了所謂的動態頁面,
然後程序猿在編碼的時候,會把所有的代碼都寫在頁面上,包括資料庫連接,包括事務控制,接收參數,各種校驗,各種邏輯,各種html/js/css代碼等等
怎麼樣?夠亂吧?像一坨那什麼一樣,這個頁面可能有成千上萬行?

那麼好,問題來了,回頭需要修改的時候,你怎麼辦?
你找個東西找半天,好不容易找到了,還不敢改,怕被其他地方用了,改出連帶問題。
頁面一出錯,定位不準到底是哪裡的問題,從頭到尾的挨個排查。
等等等等。

這就是大家常說的什麼叫可維護性,這也是為什麼越來越多的公司的規范要求不能寫復雜sql。

還記得之前在東軟的時候,一哥們寫了一個80多行的大sql來完成一個核心的查詢。
試問這個大sql天天在資料庫里run,還有性能可言?
再試問誰敢改?
後來項目要改需求還是出現bug了,那個sql要改動,寫sql的哥們改了好久才改好,因為時間長他也忘了,
再後來他離職了。。。

有人問,那簡單sql實現不了我的功能呀,怎麼辦?
從資料庫設計層面開始下手,要允許適當的冗餘,把表弄好,就迎刃而解了,這也是資料庫層面的一種解耦吧。

後來。。。
進入第二階段,大家痛定思痛,決定要把頁面和邏輯拆開,頁面只是負責顯示,邏輯都在後台。
這就出現了短暫的,在jsp里使用標簽調用bean的用法。bean里耦合了除了頁面之外的所有東西。

再後來。。。
進入了第三階段,大家又痛定思痛,決定要拆成三部分,就是大名鼎鼎的MVC。

再再後來。。。
衍生出來了類似於struts/springmvc等等的mvc框架
---------------
JavaWeb項目的層有2個維度。

第一個維度是MVC的三層:
M:model,模型層,包括了你的業務邏輯和資料庫操作,封裝好給視圖層使用的。
V:view,視圖層,僅僅做的是展示數據,不包含業務邏輯,主要是jsp/html等等
C:controller,控制層,負責接收請求,調用模型層處理業務邏輯並返回給視圖層。

第二個維度是java代碼里的三層:
controller:控制層,負責接收參數/解析參數/封裝參數,調用serivce,將service方法的返回值進行封裝(如果需要),返回數據/返回頁面,路由。
service:負責業務邏輯,事務控制在這層里做,被controller調用,以及調用。
:持久層,負責資料庫交互,被service調用。

這2個維度別弄混了喲。我今天主要說的是第二個維度的層喲。
我認為,第二個維度是第一個維度的延伸,其實第二個維度再加上一個表現層就完美了,這就為什麼有人說是4層架構。
---------------
前戲結束,步入正題:

有些學生朋友可能會問為什麼要分層呢?我本來可以在一個地方寫完的東西,非要散落在各個層中,都在一起不是挺好的嗎?
開發效率高呀~
跳來跳去的我腦子都暈啦。。。

這就是為什麼有人會把所有的東西都扔在一個層里,比如controller層。。。

其實我們可以在jsp上把所有的邏輯以及資料庫操作,數據展示全部寫在一起,耦合在一起,這樣開發起來貌似更快,
但是維護性非常差,有朝一日想改一個小地方,牽一發而動全一身,隱患很高,無法快速定位問題。
因此我們需要分層。
分層了之後,你理論上改了持久層的東西,邏輯層是不用變動的。

每個Dao類是跟每個表走,Dao的每個方法里就一個個的簡單sql,不包含任何業務邏輯,可以被不同的service復用和調用。

經過抽象後基本上都是通用的,因而我們在定義DAO層的時候可以將相關的方法定義完畢,
這樣的好處是在對Service進行擴展的時候不需要再對DAO層進行修改,提高了程序的可擴展性。

提高了程序的可擴展性。具體什麼時候做這些操作,怎麼做這些操作都由Service來處理。
(就像郭德綱的相聲里的一句話:「行了,你甭管了」)

而Service則不是,一個Service里可以會調用多個不同的,完成特定的業務邏輯,事務控制,
封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重復利用性

同時,一個Service的方法也有可能被多個Controller的方法來調用。

邏輯出問題就在Service找問題,資料庫,sql有問題就在Dao層找問題,
參數解析錯誤,跳轉錯誤,就在Controller上找問題。
這樣快速定位問題,互不幹擾。

---------------
分層架構(這里會延伸到更廣闊的架構):

回頭項目玩大了,怎麼辦?拆!!!

具體可以搜一下:maven分模塊開發,怎麼玩代碼依賴,怎麼玩微服務,怎麼玩SOA,怎麼玩RPC,怎麼玩bbo。

web項目發展有幾個階段啊

第一個階段(單一應用架構):
所有代碼都耦合在一個項目里,放在一台伺服器上,這種all in one的方式是有好處的。
創業初期,不用什麼架構,走敏捷開發,最快速的實現需求才是王道。
你甭管我有多爛,我至少能跑起來,我至少能在外網上讓你訪問,讓你使用。
當然了,初期的訪問量很少,節省部署和運維成本才是王道呀。
聽阿里的講座,說淘寶的前期的版本用的就是一台PC機作為伺服器,所有的功能耦合在一個項目里,
每次往生產環境上發版本,要上傳一個600mb的包,呵呵。

第二個階段(垂直應用架構):
哎喲,不錯哦。自己的兒子被越來越多的人訪問,訪問量激增,一台伺服器扛不住了,
沒事,我們可以玩負載均衡,玩集群。
但是!這種性能加速度其實會變得越來越小,因為你的項目是耦合在一起的。
這時,我們需要拆分項目,這里又有2個維度,按層拆,按模塊拆。
將拆好的不同項目分別部署在不同的伺服器上,並且再分不同的小集群。

第三個階段(分布式服務架構):
唉呀媽呀,訪問量陡增,到這步你創業應該算成功了,開始燒投資人的錢了吧。
經過上面拆成了越來越多的模塊,模塊與模塊交互越來越多,怎麼辦?
這個時候我們需要把核心的業務抽出來,作為獨立的服務,慢慢發展成穩定的服務中心,
用來提升業務復用和整合。
就像阿里的大牛說過,沒有淘寶的積累,天貓能那麼快的出來嗎?
這個時候,你的緩存,資料庫,消息隊列等服務都應該是分布式的。

第四個階段(流動計算架構)
哎呀媽呀,訪問量又上了一個台階,翻了好幾百倍吖,腫么辦?
這個時候服務越來越多,一些容量和資源的浪費問題凸顯出來,
這時我們需要一個調度中心來基於訪問壓力動態的管理集群容量,
提高利用率。

第五個階段(雲計算架構)
抱歉,作者正在學習中,未完待續。