單體架構(gòu)
什么是單體架構(gòu)
一個(gè)歸檔包（例如war格式或者Jar格式）包含了應(yīng)用所有功能的應(yīng)用程序，我們通常稱之為單體應(yīng)用。架構(gòu)單體應(yīng)用的方法論，我們稱之為單體應(yīng)用架構(gòu)，這是一種比較傳統(tǒng)的架構(gòu)風(fēng)格。。
單體架構(gòu)示例圖
單體架構(gòu)的缺陷
1.復(fù)雜性高
整個(gè)項(xiàng)目包含的模塊非常多，模塊的邊界模糊，依賴關(guān)系不清晰，代碼質(zhì)量參差不齊,整個(gè)項(xiàng)目非常復(fù)雜。每次修改代碼都心驚膽戰(zhàn)，甚至添加一個(gè)簡(jiǎn)單的功能，或者修改一個(gè)BUG都會(huì)造成隱含的缺陷。
2.技術(shù)債務(wù)逐漸上升
隨著時(shí)間推移、需求變更和人員更迭，會(huì)逐漸形成應(yīng)用程序的技術(shù)債務(wù)，并且越積越多。已使用的系統(tǒng)設(shè)計(jì)或代碼難以修改，因?yàn)閼?yīng)用程序的其他模塊可能會(huì)以意料之外的方式使用它。
3.部署速度逐漸變慢
隨著代碼的增加，構(gòu)建和部署的時(shí)間也會(huì)增加。而在單體應(yīng)用中，每次功能的變更或缺陷的修復(fù)都會(huì)導(dǎo)致我們需要重新部署整個(gè)應(yīng)用。全量部署的方式耗時(shí)長(zhǎng)、影響范圍大、風(fēng)險(xiǎn)高，這使得單體應(yīng)用項(xiàng)目上線部署的頻率較低，從而又導(dǎo)致兩次發(fā)布之間會(huì)有大量功能變更和缺陷修復(fù)，出錯(cuò)概率較高。
4.擴(kuò)展能力受限，無(wú)法按需伸縮
單體應(yīng)用只能作為一個(gè)整體進(jìn)行擴(kuò)展，無(wú)法結(jié)合業(yè)務(wù)模塊的特點(diǎn)進(jìn)行伸縮。
5.阻礙技術(shù)創(chuàng)新
單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺(tái)或方案解決所有問題，團(tuán)隊(duì)的每個(gè)成員都必須使用相同的開發(fā)語(yǔ)言和架構(gòu)，想要引入新的框架或技術(shù)平臺(tái)非常困難。
由于單體架構(gòu)的缺陷日益明顯，所以越來(lái)越多的公司采用微服務(wù)架構(gòu)范式解決上面提到的單體架構(gòu)中的問題。
不同于構(gòu)建單一、龐大的應(yīng)用，微服務(wù)架構(gòu)將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)。
SOA架構(gòu)
SOA是Service-Oriented Architecture的英文縮寫，就是面向服務(wù)的架構(gòu)。這里的服務(wù)可以理解為service層業(yè)務(wù)服務(wù)。
單一應(yīng)用架構(gòu)
當(dāng)網(wǎng)站流量很小時(shí)，只需一個(gè)應(yīng)用，將所有功能都部署在一起，以減少部署節(jié)點(diǎn)和成本。
垂直應(yīng)用架構(gòu)
當(dāng)訪問量逐漸增大，單一應(yīng)用增加機(jī)器帶來(lái)的加速度越來(lái)越小，將應(yīng)用拆成互不相干的幾個(gè)應(yīng)用，以提升效率。
分布式服務(wù)架構(gòu)
當(dāng)垂直應(yīng)用越來(lái)越多，應(yīng)用之間交互不可避免，將核心業(yè)務(wù)抽取出來(lái)，作為獨(dú)立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場(chǎng)需求。
流動(dòng)計(jì)算架構(gòu)
當(dāng)服務(wù)越來(lái)越多，容量的評(píng)估，小服務(wù)資源的浪費(fèi)等問題逐漸顯現(xiàn)，此時(shí)需增加一個(gè)調(diào)度中心基于訪問壓力實(shí)時(shí)管理集群容量，提高集群利用率。
此時(shí)，用于提高機(jī)器利用率的SOA服務(wù)治理方案是關(guān)鍵。
Dubbo就是SOA服務(wù)治理方案的核心框架。
總結(jié)：dubbo不僅可以對(duì)服務(wù)進(jìn)行治理，而且還可以對(duì)服務(wù)進(jìn)行調(diào)用。
微服務(wù)架構(gòu)
什么是微服務(wù)架構(gòu)
簡(jiǎn)而言之，微服務(wù)架構(gòu)風(fēng)格的開發(fā)方法，是以開發(fā)一組小型服務(wù)的方式來(lái)開發(fā)一個(gè)獨(dú)立的應(yīng)用系統(tǒng)的。其中每個(gè)小型服務(wù)都運(yùn)行在自己的進(jìn)程中，并經(jīng)常采用HTTP資源API輕量的機(jī)制來(lái)相互通信。
這些服務(wù)圍繞業(yè)務(wù)功能進(jìn)行構(gòu)建，并能通過全自動(dòng)的部署機(jī)制來(lái)進(jìn)行獨(dú)立部署。這些微服務(wù)可以使用不同的語(yǔ)言來(lái)編寫，并且可以使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。對(duì)這些微服務(wù)我們僅做最低限度的集中管理。
微服務(wù)架構(gòu)示例圖
微服務(wù)架構(gòu)的特性
每個(gè)微服務(wù)可獨(dú)立運(yùn)行在自己的進(jìn)程里
一系列獨(dú)立運(yùn)行的微服務(wù)共同構(gòu)建起整個(gè)系統(tǒng)
每個(gè)服務(wù)為獨(dú)立的業(yè)務(wù)開發(fā)，一個(gè)微服務(wù)只關(guān)注某個(gè)特定的功能，如訂單管理、用戶管理等
微服務(wù)之間通過一些輕量的通信機(jī)制進(jìn)行通信，如REST API接口進(jìn)行調(diào)用
可以使用不同的語(yǔ)言與存儲(chǔ)技術(shù)
全自動(dòng)的部署機(jī)制
微服務(wù)架構(gòu)的優(yōu)勢(shì)
1.易于開發(fā)和維護(hù)
一個(gè)微服務(wù)只關(guān)注一個(gè)特定的業(yè)務(wù)功能，所以它的業(yè)務(wù)清晰、代碼量較少。開發(fā)和維護(hù)單個(gè)微服務(wù)相對(duì)比較簡(jiǎn)單，整個(gè)應(yīng)用是由若干個(gè)微服務(wù)構(gòu)建而成，所以整個(gè)應(yīng)用也會(huì)維持在可控狀態(tài)；
2.單個(gè)微服務(wù)啟動(dòng)較快
單個(gè)微服務(wù)代碼量較少，所以啟動(dòng)會(huì)比較快；
3.局部修改容易部署
單體應(yīng)用只要有修改，就要重新部署整個(gè)應(yīng)用，微服務(wù)解決了這樣的問題。一般來(lái)說，對(duì)某個(gè)微服務(wù)進(jìn)行修改，只需要重新部署這個(gè)服務(wù)即可；
4.技術(shù)棧不受限
在微服務(wù)中，我們可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)，合理地選擇技術(shù)棧
5.按需伸縮
微服務(wù)架構(gòu)的挑戰(zhàn)
1.運(yùn)維要求較高
更多的服務(wù)意味著更多的運(yùn)維投入。在單體架構(gòu)中只需要保證一個(gè)應(yīng)用的正常運(yùn)行；而在微服務(wù)中，需要保證幾十甚至幾百個(gè)服務(wù)的正常運(yùn)行與協(xié)作，帶來(lái)了巨大的挑戰(zhàn)；
2.分布式固有的復(fù)雜性
使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對(duì)于一個(gè)分布式系統(tǒng)，系統(tǒng)容錯(cuò)、網(wǎng)絡(luò)延遲、分布式事務(wù)等都帶來(lái)了巨大的挑戰(zhàn)；
3.接口調(diào)整成本高
微服務(wù)之間通過接口進(jìn)行通信。如果修改某個(gè)微服務(wù)的API，可能所有使用了該接口的微服務(wù)都需要做調(diào)整；
4.重復(fù)勞動(dòng)
很多服務(wù)可能都會(huì)使用到相同的功能。而這個(gè)功能并沒有達(dá)到分解為一個(gè)微服務(wù)的程度，這個(gè)時(shí)候，可能各個(gè)服務(wù)都會(huì)開發(fā)這一功能，導(dǎo)致代碼重復(fù)。
微服務(wù)設(shè)計(jì)原則
單一職責(zé)原則
服務(wù)自治原則
輕量級(jí)通信原則
接口明確原則
微服務(wù)和SOA的區(qū)別
微服務(wù)架構(gòu)強(qiáng)調(diào)的第一個(gè)重點(diǎn)就是業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化
微服務(wù)不再?gòu)?qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時(shí)SOA的思想進(jìn)入到單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部實(shí)現(xiàn)真正的組件化。
分布式-微服務(wù)-集群的區(qū)別
分布式
service A、B、C、D 分別是業(yè)務(wù)組件，通過API Geteway進(jìn)行業(yè)務(wù)訪問。
將一個(gè)大的系統(tǒng)劃分為多個(gè)業(yè)務(wù)模塊，業(yè)務(wù)模塊分別部署到不同的機(jī)器上，各個(gè)業(yè)務(wù)模塊之間通過接口進(jìn)行數(shù)據(jù)交互。
區(qū)別分布式的方式是根據(jù)不同機(jī)器不同業(yè)務(wù)。
注：分布式需要做好事務(wù)管理。
集群模式
集群模式是不同服務(wù)器部署同一套服務(wù)對(duì)外訪問，實(shí)現(xiàn)服務(wù)的負(fù)載均衡。
區(qū)別集群的方式是根據(jù)部署多臺(tái)服務(wù)器業(yè)務(wù)是否相同。
注：集群模式需要做好session共享，確保在不同服務(wù)器切換的過程中不會(huì)因?yàn)闆]有獲取到session而中止退出服務(wù)。
一般配置Nginx*的負(fù)載容器實(shí)現(xiàn)：靜態(tài)資源緩存、Session共享可以附帶實(shí)現(xiàn)，Nginx支持5000個(gè)并發(fā)量。
分布式是否屬于微服務(wù)?
答案是肯定的。微服務(wù)的意思也就是將模塊拆分成一個(gè)獨(dú)立的服務(wù)單元通過接口來(lái)實(shí)現(xiàn)數(shù)據(jù)的交互。
微服務(wù)架構(gòu)
微服務(wù)的設(shè)計(jì)是為了不因?yàn)槟硞€(gè)模塊的升級(jí)和BUG影響現(xiàn)有的系統(tǒng)業(yè)務(wù)。
微服務(wù)與分布式的細(xì)微差別是，微服務(wù)的應(yīng)用不一定是分散在多個(gè)服務(wù)器上，他也可以是同一個(gè)服務(wù)器。
分布式和微服的架構(gòu)很相似，只是部署的方式不一樣而已。
