[[339110]]

學(xué)習(xí)內(nèi)容安排如下：

• 系統(tǒng)架構(gòu)的演化：集中式架構(gòu)、分布式架構(gòu)。
• 服務(wù)之間的調(diào)用方式：HTTP和RPC。
• Spring提供的RestTmeplate模板的使用。

當(dāng)然系統(tǒng)架構(gòu)肯定不是說我一篇文章就能學(xué)好的，只能說我作為一名初學(xué)者，是如何去理解這些概念的。

至于想要真正地去弄懂這些，需要自己長(zhǎng)期性地不斷學(xué)習(xí)，非一朝一夕就能學(xué)完的。

一、系統(tǒng)架構(gòu)概述

技術(shù)更新是非?？斓?，從單一應(yīng)用到垂直細(xì)分，到分布式，到SOA，以及微服務(wù)架構(gòu)。

還有在Google帶領(lǐng)下的Service Mesh，只有不斷地學(xué)習(xí)才能在IT行業(yè)前行下去。

1集中式架構(gòu)

當(dāng)網(wǎng)站流量很小時(shí)，只需一個(gè)應(yīng)用，將所有功能都部署在一起，以減少部署節(jié)點(diǎn)和成本。

 

 

但是流量一旦增加就會(huì)出現(xiàn)各種的問題：

• 代碼耦合，開發(fā)維護(hù)困難。
• 無法針對(duì)不同模塊進(jìn)行針對(duì)性優(yōu)化以及擴(kuò)展。
• 單點(diǎn)容錯(cuò)率低，并發(fā)能力差。

當(dāng)然為了解決這些問題，后續(xù)也做了優(yōu)化，根據(jù)業(yè)務(wù)功能對(duì)系統(tǒng)進(jìn)行拆分。

雖然解決了代碼耦合問題，但是系統(tǒng)間相互獨(dú)立，會(huì)有很多重復(fù)開發(fā)工作，影響開發(fā)效率。

舉一個(gè)例子來理解，比如說一個(gè)電商項(xiàng)目，根據(jù)業(yè)務(wù)功能拆分成兩套系統(tǒng)：

• 前端門戶系統(tǒng)：就是用戶看到的界面。
• 后臺(tái)管理系統(tǒng)：內(nèi)部人員的管理界面。

那么現(xiàn)在問題來了：

根據(jù)id去數(shù)據(jù)庫(kù)查詢商品，Service層和Dao層的代碼要寫兩遍，造成了代碼的極度冗余。

2分布式服務(wù)

為了解決代碼冗余問題，可以將核心業(yè)務(wù)作為獨(dú)立的服務(wù)抽取出來，形成服務(wù)中心。

多個(gè)子系統(tǒng)只需要訪問服務(wù)中心就好了。

 

 

優(yōu)點(diǎn)：將基礎(chǔ)服務(wù)進(jìn)行了抽取，系統(tǒng)間相互調(diào)用，提高了代碼復(fù)用和開發(fā)效率。

缺點(diǎn)：一旦服務(wù)變多，調(diào)用關(guān)系錯(cuò)綜復(fù)雜，開發(fā)者自己都搞不清楚誰調(diào)用誰，難以維護(hù)。

3流動(dòng)計(jì)算架構(gòu)SOA

它將普通的分布式系統(tǒng)集中管理起來了，更便于維護(hù)，同時(shí)也提高資源利用率。

其典型的架構(gòu)就是阿里巴巴的Dubbo，這個(gè)架構(gòu)圖就比較復(fù)雜了，我就不自己畫了。

 

 

不要看好像挺復(fù)雜的，本質(zhì)上都是為了管理服務(wù)，我以打車的例子大致說明下：

• 在以前，我們?nèi)羰且塑嚕枰フ臆?，而?duì)于車主來說也需要找乘客。
• 而現(xiàn)在，有打車服務(wù)了，我們?nèi)羰且塑囍苯咏械蔚尉秃昧耍緳C(jī)也方便找乘客。

對(duì)于服務(wù)也是一樣的，以前有什么問題?

• 服務(wù)越來越多，要管理每個(gè)服務(wù)的地址。
• 服務(wù)之間調(diào)用關(guān)系錯(cuò)綜復(fù)雜，難以理清。
• 服務(wù)過多，服務(wù)狀態(tài)難以管理。

為了解決上述問題，服務(wù)治理做了哪些?

• 服務(wù)注冊(cè)中心，實(shí)現(xiàn)服務(wù)自動(dòng)注冊(cè)，無需人為記錄服務(wù)地址。
• 服務(wù)自動(dòng)訂閱，服務(wù)列表自動(dòng)推送，服務(wù)調(diào)用透明化，無需關(guān)心依賴關(guān)系。
• 動(dòng)態(tài)監(jiān)控服務(wù)狀態(tài)，人為控制服務(wù)狀態(tài)即可。

對(duì)于我個(gè)人來說，我就會(huì)用滴滴和司機(jī)之間的關(guān)系作為對(duì)比，來理解服務(wù)管理和服務(wù)之間的關(guān)系，不然專業(yè)術(shù)語太多了，也很難理解。

4微服務(wù)

微服務(wù)和SOA比較像，但也有一些差別。

 

 

①微：微服務(wù)的核心

也就是小的意思，服務(wù)拆分粒度很小。例如一個(gè)用戶管理就可以作為一個(gè)服務(wù)。

②面向服務(wù)

每個(gè)服務(wù)都要對(duì)外暴露Rest風(fēng)格服務(wù)接口API，并不關(guān)心服務(wù)的技術(shù)實(shí)現(xiàn)。

你是用Java實(shí)現(xiàn)的也好，還是用Python實(shí)現(xiàn)的也罷，都可以，只要提供Rest的接口即可。

③單一職責(zé)

微服務(wù)中每一個(gè)服務(wù)都對(duì)應(yīng)唯一的業(yè)務(wù)能力，做到單一職責(zé)。

④獨(dú)立

• 團(tuán)隊(duì)獨(dú)立：每個(gè)服務(wù)對(duì)應(yīng)獨(dú)立的開發(fā)團(tuán)隊(duì)。
• 技術(shù)獨(dú)立：因?yàn)槭敲嫦蚍?wù)，提供Rest接口，使用什么技術(shù)沒有別人干涉。
• 自治：自治是說服務(wù)間互相獨(dú)立，互不干擾。
• 前后端獨(dú)立：以前后端要為電腦端、手機(jī)端提供不同接口，現(xiàn)在只需要提供Rest接口。
• 數(shù)據(jù)庫(kù)分離：每個(gè)服務(wù)都使用自己的數(shù)據(jù)源。
• 服務(wù)獨(dú)立：服務(wù)間雖然有調(diào)用，但要做到服務(wù)重啟不影響其它服務(wù)。

二、服務(wù)調(diào)用方式

我們以前寫的代碼本質(zhì)上都是在一個(gè)服務(wù)中，屬于服務(wù)內(nèi)部：類與類之間的調(diào)用。

那如何實(shí)現(xiàn)服務(wù)之間的調(diào)用呢?有兩種方式：RPC調(diào)用和Http調(diào)用。

1RPC調(diào)用

基于原生TCP通信，速度快，效率高，現(xiàn)在熱門的dubbo，都是RPC的典型代表。

2Http調(diào)用

這個(gè)就太常見了，我們以前一直在用的Ajax請(qǐng)求，就屬于http調(diào)用。

它的特點(diǎn)在于靈活，實(shí)現(xiàn)了不同編程語言之間的調(diào)用，Ajax就是在使用js調(diào)用Java。

現(xiàn)在使用Java代碼調(diào)用Java，做個(gè)演示：

 

 

我在電腦上創(chuàng)建了兩個(gè)不同的工程，工程①也就是我們這幾天用SpringBoot搭建的項(xiàng)目。

在工程①中實(shí)現(xiàn)了通過id去數(shù)據(jù)庫(kù)查詢用戶數(shù)據(jù)的功能，也可以通過瀏覽器訪問。

那在工程②中調(diào)用工程①中的業(yè)務(wù)，也就是服務(wù)之間的調(diào)用。

注意：這和以前已經(jīng)有本質(zhì)上的區(qū)別了，以前都是內(nèi)部的調(diào)用，現(xiàn)在不一樣了。

當(dāng)然因?yàn)槲疫@邊只有一臺(tái)電腦，所以我不太確定能否實(shí)現(xiàn)跨電腦的調(diào)用。

那它具體是如何實(shí)現(xiàn)的呢?

3RestTemplate

它是Spring提供的一個(gè)模板工具類，也是上述我使用到的工具：

 

 

①SpringBoot測(cè)試

在SpringBoot中測(cè)試和在Spring中測(cè)試有些許不同之處需要注意。

是使用注解@SpringBootTest說明，參數(shù)為啟動(dòng)類的字節(jié)碼。

②restTemplate

這也就是spring提供的模板工具類，使用spring注入后，即可以直接使用

③getForObject()

這是發(fā)送一次get請(qǐng)求，postForObject對(duì)應(yīng)著post請(qǐng)求，發(fā)送到哪兒呢?

• 參數(shù)一：指定訪問電腦的IP地址。
• 參數(shù)二：返回?cái)?shù)據(jù)的Class對(duì)象。

最后

學(xué)習(xí)完了Http客戶端工具，就可以正式學(xué)習(xí)微服務(wù)了，明天開始學(xué)SpringCloud。

謝謝你的觀看。