一、概述

每個技術(shù)的產(chǎn)生沒有更好更壞之分，只是適用于不同的場景罷了。

二、單體架構(gòu)（單一應(yīng)用架構(gòu)）

2.1、單體架構(gòu)概念

將所有的業(yè)務(wù)場景的表示層，業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層打包放在一個工程中，最終經(jīng)過編譯打包，部署在一臺服務(wù)器上。例如：典型的J2EE工程，把jsp,業(yè)務(wù)邏輯層的service,controller和數(shù)據(jù)訪問層的dao,打包成wa包，部署在Tomcat或者Jetty或者其他容器上運(yùn)行。

問題：數(shù)據(jù)庫和應(yīng)用程序部署到不同的服務(wù)器是單體架構(gòu)嗎？

單體架構(gòu)關(guān)心的是否是整個應(yīng)用部署同一個包，如果是則為單體架構(gòu)，否則就不是。

2.2、單體架構(gòu)應(yīng)用場景及特點(diǎn)

業(yè)務(wù)場景簡單,功能不復(fù)雜，研發(fā)人員較少。

公司處于創(chuàng)業(yè)初期：為了生存，需要的是快速開發(fā)出功能，然后到市場上試錯。

性能要求及其苛刻：一些對性能要求比較高的系統(tǒng)，例如股票軟件。

需求比較穩(wěn)定的系統(tǒng)也不適合做成微服務(wù)，例如：公司內(nèi)部OA，考勤系統(tǒng)等。

比如簡單的網(wǎng)上超市，網(wǎng)站 頁面包括 用戶注冊、登錄功能、商品展示、下單。管理后臺包括用戶管理、商品管理、訂單管理。需要快速開發(fā)出功能，發(fā)布到市場上，這種就直接使用單體架構(gòu)即可。

傳統(tǒng)架構(gòu)其實就是SSH或者SSM，屬于單點(diǎn)應(yīng)用，把整個業(yè)務(wù)模塊都在一個項目進(jìn)行開發(fā)，分為MVC架構(gòu)，會拆分成controller,service,dao層。

部署的時候首先所有功能集中在一個項目中打war包部署，通過集群(session共享集群)來提高服務(wù)器的性能。war包，圖片服務(wù)器整合到war包，放到同一臺服務(wù)器。

2.3、單體架構(gòu)的優(yōu)缺點(diǎn)?

優(yōu)點(diǎn):

部署簡單 ：由于是完整的結(jié)構(gòu)體，可以直接部署在一份服務(wù)器上即可；

技術(shù)單一 ：項目不需要復(fù)雜的技術(shù)棧，往往一套熟悉的技術(shù)棧就可以完成開發(fā)，前期開發(fā)的成本低,周期短,小型企業(yè)首選；

用人成本低 ：單個程序員可以完成業(yè)務(wù)接口到數(shù)據(jù)庫的整個流程。

缺點(diǎn)：

業(yè)務(wù)越來越復(fù)雜，單體架構(gòu)擴(kuò)展性不足，業(yè)務(wù)擴(kuò)展帶來的代價越來越大；

用戶越來越多，程序承受的并發(fā)越來越高，單體應(yīng)用的并發(fā)能力有限；

單體應(yīng)用的業(yè)務(wù)都在同一個程序中，增刪改業(yè)務(wù)修改，也會影響其他代碼，給測試增加了難度。

阻礙技術(shù)創(chuàng)新

單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺或方案解決所有的問題，團(tuán)隊中的每個成 員都必須使用相同的開發(fā)語言和框架，要想引人新框架或新技術(shù)平臺會非常 困難。例如，一個使用 Struts 2構(gòu)建的、有100萬行代碼的單體應(yīng)用，如 果想要換用 Spring MVC ，毫無疑問切換的成本是非常高的。

2.4、單體架構(gòu)的后階段

分層開發(fā)

分層的開發(fā)的目的：

為了解決容錯性差，比如用戶查詢數(shù)據(jù)導(dǎo)致sql異常，會導(dǎo)致整個頁面無法訪問，從而導(dǎo)致整個服務(wù)器的宕機(jī)，此時，我們可以使用分層開發(fā)，每一個如果發(fā)生錯誤的話，在上一層可以進(jìn)行異常捕獲，這個錯誤就可以不讓用戶看到。

分層的開發(fā)的好處：提高系統(tǒng)的維護(hù)性，解決容錯性問題，后面就總結(jié)出MVC設(shè)計模式(MVC架構(gòu)解決方案)。分層開發(fā)，還可以把服務(wù)器分離部署（把數(shù)據(jù)庫和應(yīng)用程序分開部署）。

特點(diǎn)和好處：

MVC分層開發(fā)能夠解決基本的容錯性問題，數(shù)據(jù)庫和項目部署分離。但是隨著互聯(lián)網(wǎng)的開發(fā)，網(wǎng)站的訪問量的持續(xù)增加，單臺的應(yīng)用服務(wù)器已經(jīng)無法滿足用戶的需求。

2.5、單體架構(gòu)提高并發(fā)訪問量

服務(wù)器集群:就是服務(wù)器集群就是指將很多服務(wù)器集中起來一起進(jìn)行同一種服務(wù)，在客戶端看來就像是只有一個服務(wù)器。集群可以利用多個計算機(jī)進(jìn)行并行計算從而獲得很高的計算速度，也可以用多個計算機(jī)做備份，從而使得任何一個機(jī)器壞了整個系統(tǒng)還是能正常運(yùn)行。

隨著業(yè)務(wù)的擴(kuò)展，大部分公司會將單體應(yīng)用進(jìn)行集群式部署，并增加負(fù)載均衡器，還需要增加集群部署的緩存服務(wù)器和文件服務(wù)器，并將數(shù)據(jù)庫讀寫分離，以應(yīng)對用戶量的增加帶來的高并發(fā)訪問量。

2.6、單體架構(gòu)使用服務(wù)器集群及存在的不足

代碼可讀性，可維護(hù)性差；

面對海量用戶，數(shù)據(jù)庫會成為瓶頸，需要使用分庫分表；

持續(xù)交付能力差，業(yè)務(wù)越復(fù)雜，代碼越多熟悉成本高。

三、垂直架構(gòu)

3.1、垂直架構(gòu)概念

訪問量逐漸增大，單體架構(gòu)單加集群節(jié)點(diǎn)帶來服務(wù)器性能越來越小。比如有的模塊是計算密集型的，它需要強(qiáng)勁的 CPU ;有的模塊則是 IO 密集型的，需要更大的內(nèi)存。由于這些模塊部署在一起，不得不在硬件 的選擇上做出妥協(xié)。因此我們通常需要將應(yīng)用拆成互不相干的幾個應(yīng)用，這就稱之為垂直架構(gòu)?。

3.2、垂直架構(gòu)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

系統(tǒng)拆分實現(xiàn)了流量分擔(dān)，解決了并發(fā)問題

可以針對不同模塊進(jìn)行優(yōu)化

方便水平擴(kuò)展，負(fù)載均衡，容錯率提高

系統(tǒng)間相互獨(dú)立

缺點(diǎn)：

服務(wù)之間相互調(diào)用，如果某個服務(wù)的端口或者ip地址發(fā)生改變，調(diào)用的系統(tǒng)得手動改變

搭建集群之后，實現(xiàn)負(fù)載均衡比較復(fù)雜

會員項目、訂單項目、支付項目、優(yōu)惠券等。項目與項目之間進(jìn)行webservice、RPC遠(yuǎn)程通信等。每個項目中都有自己獨(dú)立的數(shù)據(jù)庫（redis等），

分布式架構(gòu)拆分

會員：登錄、注冊、修改密碼。

訂單：下單，查詢訂單。

3.1、分布式架構(gòu)特點(diǎn)

以單體架構(gòu)規(guī)模的項目為單位進(jìn)行垂直劃分項目，即將一個大項目拆分成一個一個單體結(jié)構(gòu)項目。

項目與項目之間的存在數(shù)據(jù)冗余，耦合性較大，比如上圖中三個項目都存在客戶信息。

項目之間的接口多為數(shù)據(jù)同步功能，如：數(shù)據(jù)庫之間的數(shù)據(jù)庫，通過網(wǎng)絡(luò)接口進(jìn)行數(shù)據(jù)庫同步。

3.2、分布式架構(gòu)優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

項目架構(gòu)簡單，前期開發(fā)成本低，周期短，小型項目的首選。

通過垂直拆分，原來的單體項目不至于無限擴(kuò)大。

不同的項目可采用不同的技術(shù)。

缺點(diǎn)：

復(fù)雜應(yīng)用的開發(fā)維護(hù)成本變高，部署效率逐漸降低。因為隨著業(yè)務(wù)功能的不斷膨脹，代碼全量編譯和部署一次所需的時間非常長。

團(tuán)隊協(xié)作效率差，部分公共功能重復(fù)開發(fā)，代碼重復(fù)率居高不下。

系統(tǒng)可靠性變差。垂直架構(gòu)將所有的應(yīng)用模塊都部署到一個進(jìn)程中，如果某個應(yīng)用接口發(fā)生故障，例如內(nèi)存泄漏，會導(dǎo)致整個節(jié)點(diǎn)宕機(jī)。

四、SOA架構(gòu)(面向服務(wù)架構(gòu))

HClient:將共同的業(yè)務(wù)邏輯進(jìn)行拆分，拆分成獨(dú)立的項目進(jìn)行部署。

服務(wù)化：面向業(yè)務(wù)邏輯層開發(fā)。

項目：包含業(yè)務(wù)邏輯層和視圖層。服務(wù)：只包含業(yè)務(wù)邏輯層，沒有視圖層。

重點(diǎn)術(shù)語剖析：

負(fù)載均衡器：分發(fā)高并發(fā)的網(wǎng)絡(luò)請求，用戶的訪問被分派到不同的應(yīng)用服務(wù)器。用戶增加時，添加應(yīng)用服務(wù)器即可。

緩存服務(wù)器：緩解數(shù)據(jù)庫的數(shù)據(jù)以及數(shù)據(jù)庫讀取的壓力。

五、微服務(wù)架構(gòu)

5.1、微服務(wù)架構(gòu)概念

微服務(wù)架構(gòu)：將單體應(yīng)用拆分為多個高內(nèi)聚低耦合的小型服務(wù)，每個小服務(wù)運(yùn)行在獨(dú)立進(jìn)程，由不同的團(tuán)隊開發(fā)和維護(hù)，服務(wù)間采用輕量級通信機(jī)制，獨(dú)立自動部署，可以采用不同的語言及存儲。

單體架構(gòu)整個團(tuán)隊維護(hù)開發(fā)一個大工程及一個單庫，到了微服務(wù)架構(gòu)，用戶請求經(jīng)過API Gateway被路由到下游服務(wù)，服務(wù)之間以輕量級通信協(xié)議進(jìn)行通信，服務(wù)通過注冊中心發(fā)現(xiàn)彼此，每個服務(wù)都有專門的開發(fā)維護(hù)團(tuán)隊，每個服務(wù)對應(yīng)獨(dú)立的數(shù)據(jù)庫，服務(wù)獨(dú)立開發(fā)，獨(dú)立部署和上線。

5.2、微服務(wù)架構(gòu)的特點(diǎn)

將系統(tǒng)服務(wù)層完全獨(dú)立出來，并將服務(wù)層抽取為一個一個的微服務(wù)。

微服務(wù)遵循單一原則（一個服務(wù)做一件事）。

微服務(wù)之間采用RESTful等輕量協(xié)議傳輸。

5.3、微服務(wù)架構(gòu)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

服務(wù)拆分粒度更細(xì)，有利于資源重復(fù)利用，提高開發(fā)效率。

可以更加精準(zhǔn)的制定每個服務(wù)的優(yōu)化方案，提高系統(tǒng)可維護(hù)性。

微服務(wù)架構(gòu)采用去中心化思想，服務(wù)之間采用RESTful等輕量協(xié)議通信，相比ESB更輕量。

適用于互聯(lián)網(wǎng)時代，產(chǎn)品迭代周期更短。

單個微服務(wù)啟動較快

技術(shù)棧不受限

缺點(diǎn)：

微服務(wù)過多，服務(wù)治理成本高，不利于系統(tǒng)維護(hù)。

分布式系統(tǒng)開發(fā)的技術(shù)成本高（容錯、分布式事務(wù)等），對團(tuán)隊挑戰(zhàn)大。