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

我們擁有十余年網(wǎng)頁設(shè)計和網(wǎng)站建設(shè)經(jīng)驗，從網(wǎng)站策劃到網(wǎng)站制作，我們的網(wǎng)頁設(shè)計師為您提供的解決方案。為企業(yè)提供網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、微信開發(fā)、小程序設(shè)計、手機(jī)網(wǎng)站制作設(shè)計、成都h5網(wǎng)站建設(shè)、等業(yè)務(wù)。無論您有什么樣的網(wǎng)站設(shè)計或者設(shè)計方案要求，我們都將富于創(chuàng)造性的提供專業(yè)設(shè)計服務(wù)并滿足您的需求。

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

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

至于想要真正地去弄懂這些，需要自己長期性地不斷學(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)站流量很小時，只需一個應(yīng)用，將所有功能都部署在一起，以減少部署節(jié)點和成本。

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

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

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

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

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

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

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

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

2分布式服務(wù)

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

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

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

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

3流動計算架構(gòu)SOA

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

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

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

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

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

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

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

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

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

4微服務(wù)

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

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

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

②面向服務(wù)

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

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

③單一職責(zé)

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

④獨立

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

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

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

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

1RPC調(diào)用

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

2Http調(diào)用

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

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

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

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

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

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

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

當(dāng)然因為我這邊只有一臺電腦，所以我不太確定能否實現(xiàn)跨電腦的調(diào)用。

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

3RestTemplate

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

①SpringBoot測試

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

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

②restTemplate

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

③getForObject()

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

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

最后

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

謝謝你的觀看。

文章標(biāo)題：微服務(wù)，Java目前很火熱的系統(tǒng)架構(gòu)
網(wǎng)頁鏈接：http://uogjgqi.cn/article/cdhhpgp.html