2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

什么是微服務(wù)？

---

微服務(wù)（Microservice Architecture）是近幾年流行的一種架構(gòu)思想，關(guān)于它的概念很難一言以蔽之

究竟什么是微服務(wù)呢？我們在此引用 ThoughtWorks 公司的首席科學(xué)家 Martin Fowler 的一段話：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

看不懂？？？我有什么辦法，反正我能看得懂

我們先來看看傳統(tǒng)的項(xiàng)目模式

這是一個(gè)辦公系統(tǒng)示例，里面有好幾個(gè)模塊，那么假設(shè)有個(gè) low 逼程序員寫了個(gè)性能非常差的代碼在財(cái)務(wù)管理這個(gè)模塊里面，導(dǎo)致數(shù)據(jù)庫崩潰，那么整個(gè)項(xiàng)目都會受到影響，這是非常糟糕的情況

所以我們來總結(jié)下傳統(tǒng)模式的缺點(diǎn)：

項(xiàng)目過于臃腫當(dāng)大大小小的功能模塊都集中在同一項(xiàng)目的時(shí)候，整個(gè)項(xiàng)目必然會變得臃腫，讓開發(fā)者難以維護(hù)

資源無法隔離，整個(gè)系統(tǒng)的各個(gè)功能模塊都依賴于同樣的數(shù)據(jù)庫、內(nèi)存等資源，一旦某個(gè)功能模塊對資源使用不當(dāng)，整個(gè)系統(tǒng)都會被拖垮，耦合度太高

當(dāng)系統(tǒng)的訪問量越來越大的時(shí)候無法靈活擴(kuò)展，雖然可以進(jìn)行水平擴(kuò)展，部署在多臺機(jī)器上組成集群，但是這種擴(kuò)展并非靈活的擴(kuò)展。比如我們現(xiàn)在的性能瓶頸是支付模塊，希望只針對支付模塊做水平擴(kuò)展，這一點(diǎn)在單體系統(tǒng)是做不到的

現(xiàn)在對上面的結(jié)構(gòu)圖進(jìn)行優(yōu)化

我們將每個(gè)功能模塊提取出來單獨(dú)去開發(fā)部署，客戶端、每個(gè)模塊之間都可以互相調(diào)用實(shí)現(xiàn)解耦，當(dāng)然這只是一個(gè)簡單的示例而已

微服務(wù)的特點(diǎn)：

獨(dú)立部署，靈活擴(kuò)展傳統(tǒng)的單體架構(gòu)是以整個(gè)系統(tǒng)為單位進(jìn)行部署，而微服務(wù)則是以每一個(gè)獨(dú)立組件（例如員工管理服務(wù)，財(cái)務(wù)管理服務(wù)）為單位進(jìn)行部署 用一張經(jīng)典的圖來表現(xiàn)，就是下面這個(gè)樣子（左邊是傳統(tǒng)項(xiàng)目集群，右邊是微服務(wù)集群）：

? ? ? ? ?

資源的有效隔離微服務(wù)設(shè)計(jì)的原則之一，就是每一個(gè)微服務(wù)擁有獨(dú)立的數(shù)據(jù)源，假如微服務(wù)A想要讀寫微服務(wù)B的數(shù)據(jù)庫，只能調(diào)用微服務(wù)B對外暴露的接口來完成。這樣有效避免了服務(wù)之間爭用數(shù)據(jù)庫和緩存資源所帶來的問題

團(tuán)隊(duì)組織架構(gòu)的調(diào)整微服務(wù)設(shè)計(jì)的思想也改變了原有的企業(yè)研發(fā)團(tuán)隊(duì)組織架構(gòu)。傳統(tǒng)的研發(fā)組織架構(gòu)是水平架構(gòu)，前端有前端的團(tuán)隊(duì)，后端有后端的團(tuán)隊(duì)，DBA 有 DBA 的團(tuán)隊(duì)，測試有測試的團(tuán)隊(duì)。而微服務(wù)的設(shè)計(jì)思想對團(tuán)隊(duì)的劃分有著一定的影響，使得團(tuán)隊(duì)組織架構(gòu)的劃分更傾向于垂直架構(gòu)，比如用戶業(yè)務(wù)是一個(gè)團(tuán)隊(duì)來負(fù)責(zé)，支付業(yè)務(wù)是一個(gè)團(tuán)隊(duì)來負(fù)責(zé)（當(dāng)然，這種垂直劃分只是一個(gè)理想的架構(gòu)，實(shí)際在企業(yè)中并不會把團(tuán)隊(duì)組織架構(gòu)拆分得這么絕對）

網(wǎng)站架構(gòu)演變過程

---

單體架構(gòu)

單體架構(gòu)也稱為傳統(tǒng)架構(gòu)，說白了就是我們經(jīng)常寫的 SSM 或者 SSH 應(yīng)用，特點(diǎn)就是將整個(gè)業(yè)務(wù)都在一個(gè)項(xiàng)目中開發(fā)，整個(gè)項(xiàng)目一般都分控制層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層，這種項(xiàng)目一般只適合小項(xiàng)目開發(fā)

缺點(diǎn)：耦合的太高，一旦某個(gè)模塊崩潰，可能會影響到整個(gè)項(xiàng)目的運(yùn)行

分布式架構(gòu)

分布式架構(gòu)是基于傳統(tǒng)架構(gòu)演變過來的，即將傳統(tǒng)的項(xiàng)目以模塊拆分成多個(gè)子項(xiàng)目，比如：會員項(xiàng)目、訂單項(xiàng)目、商品項(xiàng)目等。每個(gè)項(xiàng)目都有自己獨(dú)立的數(shù)據(jù)庫，注意這里是子項(xiàng)目，代表每個(gè)子項(xiàng)目都有完整的 mvc 結(jié)構(gòu)

比較：分布式架構(gòu)比傳統(tǒng)架構(gòu)粒度更細(xì)，耦合度降低，更適合團(tuán)隊(duì)開發(fā)

maven 管理的多模塊項(xiàng)目是分布式架構(gòu)嗎？？

不一定，如果你僅僅是將項(xiàng)目拆分成 entity、service、dao 幾個(gè)子工程，然后通過 maven 依賴引入，那其實(shí)最終打包后還是一個(gè) war 包啊，其實(shí)依然是一個(gè)項(xiàng)目。但是如果你打包成多個(gè)項(xiàng)目部署，互相通信，那可以稱為分布式項(xiàng)目

SOA架構(gòu)

---

SOA:（Service Oriented Architecture） 面向服務(wù)的架構(gòu)。把工程拆分成服務(wù)層、表現(xiàn)層兩個(gè)工程，服務(wù)層中包含業(yè)務(wù)邏輯，只需要對外提供服務(wù)即可。表現(xiàn)層只需處理和頁面的交互，業(yè)務(wù)邏輯都是調(diào)用服務(wù)層的服務(wù)來實(shí)現(xiàn)

SOA 是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（成為服務(wù)），通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，他應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)、和變成語言。這是的構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以從一種統(tǒng)一和通用的方式進(jìn)行交互

SOA 是把服務(wù)分成了若干，表現(xiàn)層分成了若干。表現(xiàn)層和服務(wù)層沒有耦合關(guān)系，表現(xiàn)層可以用任意一個(gè)服務(wù)層，開發(fā)的時(shí)候，僅僅是增加服務(wù)層和 web 層2個(gè)工程，并不會把服務(wù)層和 web 層當(dāng)成一個(gè)整個(gè)工程。他們是獨(dú)立的。而分布式架構(gòu)是 web 和服務(wù)層緊緊聯(lián)系到了一起，一個(gè) web 層對應(yīng)一個(gè)服務(wù)層。所以 SOA 比分布式架構(gòu)更加解耦合，擴(kuò)展也更容易

標(biāo)準(zhǔn)架構(gòu)圖：

核心組件：ESB 企業(yè)服務(wù)總線

ESB 全稱為 Enterprise Service Bus，即企業(yè)服務(wù)總線。它是傳統(tǒng)中間件技術(shù)與 XML、Web 服務(wù)等技術(shù)結(jié)合的產(chǎn)物。ESB 提供了網(wǎng)絡(luò)中最基本的連接中樞，是構(gòu)筑企業(yè)神經(jīng)系統(tǒng)的必要元素。ESB 的出現(xiàn)改變了傳統(tǒng)的軟件架構(gòu)，可以提供比傳統(tǒng)中間件產(chǎn)品更為廉價(jià)的解決方案，同時(shí)它還可以消除不同應(yīng)用之間的技術(shù)差異，讓不同的應(yīng)用服務(wù)器協(xié)調(diào)運(yùn)作，實(shí)現(xiàn)了不同服務(wù)之間的通信與整合

特點(diǎn)：

基于 SOA 的架構(gòu)思想將重復(fù)公用的功能抽取為組件，以服務(wù)的方式給各各系統(tǒng)提供服務(wù)

各各項(xiàng)目（系統(tǒng)）與服務(wù)之間采用 webservice、rpc 等方式進(jìn)行通信

ESB 企業(yè)服務(wù)總線作為項(xiàng)目與服務(wù)之間通信的橋梁

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

將重復(fù)的功能抽取為服務(wù)，提高開發(fā)效率，提高系統(tǒng)的可重用性、可維護(hù)性

可以針對不同服務(wù)的特點(diǎn)制定集群及優(yōu)化方案

采用 ESB 減少系統(tǒng)中的接口耦合

缺點(diǎn)：

系統(tǒng)與服務(wù)的界限模糊，不利于開發(fā)及維護(hù)

雖然使用了 ESB，但是服務(wù)的接口協(xié)議不固定，種類繁多，不利于系統(tǒng)維護(hù)

抽取的服務(wù)的粒度過大，系統(tǒng)與服務(wù)之間耦合性高

轉(zhuǎn)載于:https://my.oschina.net/zhoumj/blog/3044837

總結(jié)

以上是生活随笔為你收集整理的springcloud 系列教程一：微服务与网站架构演变过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。