簡而言之，微服務(wù)架構(gòu)風(fēng)格是一種將單個應(yīng)用程序開發(fā)為“一套小型服務(wù)”的方法，每個服務(wù)“運行在自己的進程中”，并通過輕量級機制(通常是HTTP資源API)進行通信。這些服務(wù)“圍繞業(yè)務(wù)功能構(gòu)建”，并通過全自動部署機制“獨立部署”?！斑@些服務(wù)只有最低限度的集中管理”，可能是用不同的編程語言編寫的，并使用不同的數(shù)據(jù)存儲技術(shù)。
微服務(wù)是一種架構(gòu)，這種架構(gòu)是將單個的整體應(yīng)用程序分割成更小的項目關(guān)聯(lián)的獨立的服務(wù)。一個服務(wù)通常實現(xiàn)一組獨立的特性或功能，包含自己的業(yè)務(wù)邏輯和適配器。各個微服務(wù)之間的關(guān)聯(lián)通過暴露api來實現(xiàn)。這些獨立的微服務(wù)不需要部署在同一個虛擬機，同一個系統(tǒng)和同一個應(yīng)用服務(wù)器中。
一個系統(tǒng)業(yè)務(wù)量很小的時候所有的代碼都放在一個項目中就好了，然后這個項目部署在一臺服務(wù)器上就好了。整個項目所有的服務(wù)都由這臺服務(wù)器提供。這就是單機結(jié)構(gòu)。
應(yīng)用隨著時間的推進，加入的功能越來越多，最終會變得巨大，一個項目中很有可能數(shù)百萬行的代碼，互相之間繁瑣的jar包。
久而久之，開發(fā)效率低，代碼維護困難。
如果想整體應(yīng)用采用新的技術(shù)，新的框架或者語言，那是不可能的。
任意模塊的漏洞或者錯誤都會影響這個應(yīng)用，降低系統(tǒng)的可靠性。
由于整個系統(tǒng)運行需要使用到Tomcat和MySQL，單臺服務(wù)器處理的能力有限,2G的內(nèi)存需要分配給Tomcat和MySQL使用，隨著業(yè)務(wù)越來越復(fù)雜，請求越來越多.。內(nèi)存越來越不夠用了，所以這時候我們就需要進行分布式的部署。
我們進行一個評論的請求，這個請求是需要依賴分布在兩臺不同的服務(wù)器的組件[Tomat和MySQL],才能完成的.。所以叫做分布式的系統(tǒng)。
在上面的圖解中其實是存在問題的，比如Tomcat存在單點故障問題，一旦Tomcat所在的服務(wù)器宕機不可用了，我們就無法提供服務(wù)了,所以針對單點故障問題，我們會使用集群來解決.那什么是集群模式呢
單機處理到達瓶頸的時候，你就把單機復(fù)制幾份，這樣就構(gòu)成了一個“集群”。集群中每臺服務(wù)器就叫做這個集群的一個“節(jié)點”，所有節(jié)點構(gòu)成了一個集群。每個節(jié)點都提供相同的服務(wù)，那么這樣系統(tǒng)的處理能力就相當(dāng)于提升了好幾倍（有幾個節(jié)點就相當(dāng)于提升了這么多倍）。
但問題是用戶的請求究竟由哪個節(jié)點來處理呢？最好能夠讓此時此刻負載較小的節(jié)點來處理，這樣使得每個節(jié)點的壓力都比較平均。要實現(xiàn)這個功能，就需要在所有節(jié)點之前增加一個“調(diào)度者”的角色，用戶的所有請求都先交給它，然后它根據(jù)當(dāng)前所有節(jié)點的負載情況，決定將這個請求交給哪個節(jié)點處理。這個“調(diào)度者”有個牛逼了名字——負載均衡服務(wù)器(Nginx)。
架構(gòu)的演變大致為：單一應(yīng)用架構(gòu) ===> 垂直應(yīng)用架構(gòu) ===> 分布式服務(wù)架構(gòu) ===> 流動計算架構(gòu)微服務(wù)架構(gòu) ===> [未知]
互聯(lián)網(wǎng)早期，一般的網(wǎng)站應(yīng)用流量較小，只需一個應(yīng)用，將所有功能代碼都部署在一起就可以，這樣可以減少開發(fā)、部署和維護的成本。
比如說一個電商系統(tǒng)，里面會包含很多用戶管理，商品管理，訂單管理，物流管理等等很多模塊，
我們會把它們做成一個web項目，然后部署到一臺tomcat服務(wù)器上。
項目架構(gòu)簡單，小型項目的話， 開發(fā)成本低。
項目部署在一個節(jié)點上，維護容易。
他的缺點也是顯而易見的：
全部功能集成在一個工程中，對于大型項目來講不易開發(fā)和維護。
項目模塊之間緊密耦合，單點容錯率低。
無法針對不同模塊進行針對性優(yōu)化和水平擴展。
隨著訪問量的逐漸增大，單一應(yīng)用只能依靠增加節(jié)點來應(yīng)對，但是這時候會發(fā)現(xiàn)并不是所有的模塊都會有比較大的訪問量.
還是以上面的電商為例子， 用戶訪問量的增加可能影響的只是用戶和訂單模塊， 但是對消息模塊的影響就比較小. 那么此時我們希望只多增加幾個訂單模塊， 而不增加消息模塊. 此時單體應(yīng)用就做不到了， 垂直應(yīng)用就應(yīng)運而生了.
所謂的垂直應(yīng)用架構(gòu)，就是將原來的一個應(yīng)用拆成互不相干的幾個應(yīng)用，以提升效率。比如我們可以將上面電商的單體應(yīng)用拆分成:
電商系統(tǒng)(用戶管理 商品管理 訂單管理)
后臺系統(tǒng)(用戶管理 訂單管理 客戶管理)
CMS系統(tǒng)(廣告管理 營銷管理)
這樣拆分完畢之后，一旦用戶訪問量變大，只需要增加電商系統(tǒng)的節(jié)點就可以了，而無需增加后臺和CMS的節(jié)點。
系統(tǒng)拆分實現(xiàn)了流量分擔(dān)，解決了并發(fā)問題，而且可以針對不同模塊進行優(yōu)化和水平擴展。
一個系統(tǒng)的問題不會影響到其他系統(tǒng)，提高容錯率。
缺點：
系統(tǒng)之間相互獨立， 無法進行相互調(diào)用。
系統(tǒng)之間相互獨立， 會有重復(fù)的開發(fā)任務(wù)
當(dāng)垂直應(yīng)用越來越多，重復(fù)的業(yè)務(wù)代碼就會越來越多。這時候，我們就思考可不可以將重復(fù)的代碼抽取出來，做成統(tǒng)一的業(yè)務(wù)層作為獨立的服務(wù)，然后由前端控制層調(diào)用不同的業(yè)務(wù)層服務(wù)呢？ 這就產(chǎn)生了新的分布式系統(tǒng)架構(gòu)。它將把工程拆分成表現(xiàn)層和服務(wù)層兩個部分，服務(wù)層中包含業(yè)務(wù)邏輯。表現(xiàn)層只需要處理和頁面的交互，業(yè)務(wù)邏輯都是調(diào)用服務(wù)層的服務(wù)來實現(xiàn)。
抽取公共的功能為服務(wù)層，提高代碼復(fù)用性。
缺點：
系統(tǒng)間耦合度變高，調(diào)用關(guān)系錯綜復(fù)雜，難以維護。
在分布式架構(gòu)下，當(dāng)服務(wù)越來越多，容量的評估，小服務(wù)資源的浪費等問題逐漸顯現(xiàn)，此時需增加一個調(diào)度中心對集群進行實時管理。此時，用于資源調(diào)度和治理中心(SOA Service Oriented Architecture，面向服務(wù)的架構(gòu))是關(guān)鍵。
使用注冊中心解決了服務(wù)間調(diào)用關(guān)系的自動調(diào)節(jié)
缺點：
服務(wù)間會有依賴關(guān)系，一旦某個環(huán)節(jié)出錯會影響較大( 服務(wù)雪崩 )。
服務(wù)關(guān)心復(fù)雜，運維、測試部署困難。
注冊中心: nacos ,zookeeper ,nacos ,eureka,consul
微服務(wù)架構(gòu)在某種程度上是面向服務(wù)的架構(gòu)，它更加強調(diào)服務(wù)的"徹底拆分"。
服務(wù)原子化拆分，獨立打包、部署和升級，保證每個微服務(wù)清晰的任務(wù)劃分，利于擴展。
微服務(wù)之間采用RESTful等輕量級Http協(xié)議相互調(diào)用。
服務(wù)各自有自己單獨的職責(zé)，服務(wù)之間松耦合，避免因一個模塊的問題導(dǎo)致服務(wù)崩潰
缺點：
分布式系統(tǒng)開發(fā)的技術(shù)成本高（容錯、分布式事務(wù)等）。
服務(wù)治理和服務(wù)監(jiān)控關(guān)鍵。
多服務(wù)運維難度，隨著服務(wù)的增加，運維的壓力也在增大
微服務(wù)架構(gòu)， 簡單的說就是將單體應(yīng)用進一步拆分，拆分成更小的服務(wù)，每個服務(wù)都是一個可以獨立運行的項目。
微服務(wù)架構(gòu)的常見問題
一旦采用微服務(wù)系統(tǒng)架構(gòu)，就勢必會遇到這樣幾個問題：
這么多小服務(wù)，如何管理他們？
這么多小服務(wù)，他們之間如何通訊？
這么多小服務(wù)，客戶端怎么訪問他們？
這么多小服務(wù)，一旦出現(xiàn)問題了，應(yīng)該如何自處理？
這么多小服務(wù)，一旦出現(xiàn)問題了，應(yīng)該如何排錯?
對于上面的問題，是任何一個微服務(wù)設(shè)計者都不能繞過去的，因此大部分的微服務(wù)產(chǎn)品都針對每一個問題提供了相應(yīng)的組件來解決它們。
服務(wù)治理就是進行服務(wù)的自動化管理，其核心是服務(wù)的注冊與發(fā)現(xiàn)。
服務(wù)注冊：服務(wù)實例將自身服務(wù)信息注冊到注冊中心。
服務(wù)發(fā)現(xiàn)：服務(wù)實例通過注冊中心，獲取到注冊到其中的服務(wù)實例的信息，通過這些信息去請求他們提供服務(wù)。
服務(wù)剔除：服務(wù)注冊中心將出問題的服務(wù)自動剔除到可用列表之外，使其不會被調(diào)用到。
在微服務(wù)架構(gòu)中，通常存在多個服務(wù)之間的遠程調(diào)用的需求，目前1主流的遠程調(diào)用的技術(shù)有基于HTTP請求的RESTFul接口及基于TCP的RPC協(xié)議。
REST(Representational State Transfer)：這是一種HTTP調(diào)用的格式，更標(biāo)準，更通用，無論哪種語言都支持http協(xié)議。
RPC（Remote Promote Call）：一種進程間通信方式。允許像調(diào)用本地服務(wù)一樣調(diào)用遠程服務(wù)。RPC框架的主要目標(biāo)就是讓遠程服務(wù)調(diào)用更簡單、透明。RPC框架負責(zé)屏蔽底層的傳輸方式、序列化方式和通信細節(jié)。開發(fā)人員在使用的時候只需要了解誰在什么位置提供了什么樣的遠程服務(wù)接口即可，并不需要關(guān)心底層通信細節(jié)和調(diào)用過程。
他們之間的區(qū)別于聯(lián)系：
| 比較項 | RESTFul | RPC |
|---|---|---|
| 通訊協(xié)議 | HTTP | 一般是TCP |
| 性能 | 略低 | 較高 |
| 靈活度 | 高 | 低 |
| 應(yīng)用 | 微服務(wù)架構(gòu) | SOA架構(gòu) |
隨著微服務(wù)的不斷增多，不同的微服務(wù)一般會有不同的網(wǎng)絡(luò)地址，而外部客戶端可能需要調(diào)用多個服務(wù)的接口才能完成一個業(yè)務(wù)需求，如果讓客戶端直接與各個微服務(wù)通信可能出現(xiàn)：
客戶端需要調(diào)用不同的url地址，增加難度。
在一定的場景下，存在跨域請求的問題。
每個微服務(wù)都需要進行單獨的身份認證。
為了解決這些問題，API網(wǎng)關(guān)順勢而生。
API網(wǎng)關(guān)直面意思是將所有API調(diào)用統(tǒng)一接入到API網(wǎng)關(guān)層，由網(wǎng)關(guān)層統(tǒng)一接入和輸出。一個網(wǎng)關(guān)的基本功能有：統(tǒng)一接入、安全防護、協(xié)議適配、流量管控、長短鏈接支持、容錯能力。有了網(wǎng)關(guān)之后，各個API服務(wù)提供團隊可以專注于自己的的業(yè)務(wù)邏輯處理，而API網(wǎng)關(guān)更專注于安全、流量、路由等問題。
在微服務(wù)當(dāng)中，一個請求經(jīng)常會涉及到調(diào)用幾個服務(wù)，如果其中某個服務(wù)不可用，沒有做服務(wù)容錯的話，極有可能會造成一連串的服務(wù)不可用，這就是雪崩效應(yīng)。
我們沒法預(yù)防雪崩效應(yīng)的發(fā)生，只能盡可能去做好容錯。服務(wù)容錯的三個核心思想是：
不被外界環(huán)境影響。
不被上游請求壓垮。
不被下游響應(yīng)拖垮。
隨著微服務(wù)架構(gòu)的流行，服務(wù)按照不同的維度進行拆分，一次請求往往需要涉及到多個服務(wù)。互聯(lián)網(wǎng)應(yīng)用構(gòu)建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發(fā)、可能使用不同的編程語言來實現(xiàn)、有可能布在了幾千臺服務(wù)器，橫跨多個不同的數(shù)據(jù)中心。因此，就需要對一次請求涉及的多個服務(wù)鏈路進行日志記錄，性能監(jiān)控即鏈路追蹤。
官網(wǎng)地址： https://servicecomb.apache.org/cn/
官網(wǎng)地址： https://www.springcloud.cc/ （中文）
官網(wǎng)地址： https://spring.io/projects/spring-cloud （英文最新）
Spring Cloud并沒有重復(fù)制造輪子，它只是將目前各家公司開發(fā)的比較成熟、經(jīng)得起實際考驗的服務(wù)框架組合起來，通過Spring Boot風(fēng)格進行再封裝屏蔽掉了復(fù)雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。
官網(wǎng)地址： ttps://spring.io/projects/spring-cloud-alibaba
Dubbo官網(wǎng)地址： https://dubbo.apache.org/zh/
Dubbo+Zookeeper
https://www.cnblogs.com/syp172654682/p/8964068.html
一、Dubbo是什么？
Dubbo是阿里巴巴開源的基于 Java 的高性能 RPC（一種遠程調(diào)用） 分布式服務(wù)框架（SOA），致力于提供高性能和透明化的RPC遠程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。
二、為什么要用Dubbo？
因為是阿里開源項目，國內(nèi)很多互聯(lián)網(wǎng)公司都在用，已經(jīng)經(jīng)過很多線上考驗。內(nèi)部使用了 Netty、Zookeeper，保證了高性能高可用性。
聯(lián)系客服
