分布式服務(wù)架構(gòu)誕生背景：

在一個(gè)不斷發(fā)展的大型應(yīng)用中，新的業(yè)務(wù)需求和功能不斷增加，技術(shù)也在不斷演進(jìn)，不同團(tuán)隊(duì)構(gòu)建的功能子系統(tǒng)采用的技術(shù)架構(gòu)五花八門，子系統(tǒng)之間的開(kāi)發(fā)、部署和運(yùn)維模式也存在較大差異。如果企業(yè)內(nèi)部沒(méi)有統(tǒng)一的服務(wù)框架進(jìn)行技術(shù)層面的拉通，開(kāi)發(fā)和運(yùn)維效率都將受到很大制約。

傳統(tǒng)垂直架構(gòu)改造的核心就是要對(duì)應(yīng)用進(jìn)行服務(wù)化，服務(wù)化改造用到核心技術(shù)就是分布式服務(wù)框架。

分布式服務(wù)：

分布式服務(wù)顧名思義服務(wù)是分散部署在不同的機(jī)器上的，一個(gè)服務(wù)可能負(fù)責(zé)幾個(gè)功能，是一種面向SOA架構(gòu)的，服務(wù)之間也是通過(guò)rpc來(lái)交互或者是webservice來(lái)交互的。邏輯架構(gòu)設(shè)計(jì)完后就該做物理架構(gòu)設(shè)計(jì)，系統(tǒng)應(yīng)用部署在超過(guò)一臺(tái)服務(wù)器或虛擬機(jī)上，且各分開(kāi)部署的部分彼此通過(guò)各種通訊協(xié)議交互信息，就可算作分布式部署，生產(chǎn)環(huán)境下的微服務(wù)肯定是分布式部署的，分布式部署的應(yīng)用不一定是微服務(wù)架構(gòu)的，比如集群部署，它是把相同應(yīng)用復(fù)制到不同服務(wù)器上，但是邏輯功能上還是單體應(yīng)用。

分布式服務(wù)架構(gòu)與微服務(wù)的區(qū)別：

分布式服務(wù)架構(gòu)強(qiáng)調(diào)的是服務(wù)化以及服務(wù)的分散化，微服務(wù)則更強(qiáng)調(diào)服務(wù)的專業(yè)化和精細(xì)分工；從實(shí)踐的角度來(lái)看，微服務(wù)架構(gòu)通常是分布式服務(wù)架構(gòu)，反之則未必成立。所以，選擇微服務(wù)通常意味著需要解決分布式架構(gòu)的各種難題。

微服務(wù)相比分布式服務(wù)來(lái)說(shuō)，它的粒度更小，服務(wù)之間耦合度更低，由于每個(gè)微服務(wù)都由獨(dú)立的小團(tuán)隊(duì)負(fù)責(zé)，因此它敏捷性更高，分布式服務(wù)最后都會(huì)向微服務(wù)架構(gòu)演化，這是一種趨勢(shì)， 不過(guò)服務(wù)微服務(wù)化后帶來(lái)的挑戰(zhàn)也是顯而易見(jiàn)的，例如服務(wù)粒度小，數(shù)量大，后期運(yùn)維將會(huì)很難。

服務(wù)化架構(gòu)演進(jìn)圖：

MVC：當(dāng)業(yè)務(wù)規(guī)模很小時(shí)，將所有都部署在同一個(gè)進(jìn)程中，通過(guò)雙機(jī)或者前置負(fù)載均衡器實(shí)現(xiàn)負(fù)載分流；此時(shí)，用于分離前后臺(tái)邏輯的MVC架構(gòu)是關(guān)鍵。

RPC：當(dāng)垂直應(yīng)用越來(lái)越多，應(yīng)用之間交互不可避免，將核心和公共業(yè)務(wù)抽取出來(lái)，作為獨(dú)立的服務(wù)，實(shí)現(xiàn)前后臺(tái)邏輯分離，此時(shí)，用于提高業(yè)務(wù)復(fù)用及拆分的RPC框架是關(guān)鍵。

SOA：隨著業(yè)務(wù)發(fā)展，服務(wù)數(shù)量愈來(lái)愈多，服務(wù)生命周期管控和運(yùn)行狀態(tài)的治理成為瓶頸，此時(shí)用于提升服務(wù)質(zhì)量的SOA服務(wù)治理是關(guān)鍵。

微服務(wù)：隨著敏捷開(kāi)發(fā)、持續(xù)交付、DevOps理論的發(fā)展和實(shí)踐，以及基于Docker等輕量級(jí)容器（LXC）部署應(yīng)用和服務(wù)的成熟，微服務(wù)架構(gòu)開(kāi)始流行，逐漸成為應(yīng)用架構(gòu)的未來(lái)演進(jìn)方向。通過(guò)服務(wù)的原子化拆分，以及微服務(wù)的獨(dú)立打包、部署和升級(jí)，小團(tuán)隊(duì)敏捷交付，應(yīng)用的交付周期將縮短，運(yùn)維成本也將大幅下降。

應(yīng)用從集中式到分布式：

對(duì)于集中式的應(yīng)用，當(dāng)業(yè)務(wù)和功能越來(lái)越多為應(yīng)付大流量、高并發(fā)的用戶訪問(wèn)問(wèn)題，只能通過(guò)增加硬件來(lái)滿足應(yīng)用的低延時(shí)和高吞吐量。

利用硬件進(jìn)行擴(kuò)容只能暫時(shí)頂住沖擊，但是遇到棘手問(wèn)題將無(wú)法只是擴(kuò)容這么簡(jiǎn)單：

（1）業(yè)務(wù)不斷發(fā)展
（2）代碼復(fù)用是難題
（3）敏捷持續(xù)交付面臨巨大挑戰(zhàn)

解決此類問(wèn)題的有效方案就是進(jìn)行橫向與縱向的拆分：

縱向拆分：根據(jù)業(yè)務(wù)特性將應(yīng)用拆分，不同業(yè)務(wù)模塊獨(dú)立部署。

橫向拆分：將核心、公共業(yè)務(wù)拆分出來(lái)，通過(guò)分布式服務(wù)框架對(duì)業(yè)務(wù)進(jìn)行服務(wù)化，消費(fèi)者提供標(biāo)準(zhǔn)的契約來(lái)消費(fèi)這些服務(wù)。服務(wù)提供者獨(dú)立打包、部署和演進(jìn)，與消費(fèi)者解耦。

服務(wù)治理：

使用RPC服務(wù)框架對(duì)業(yè)務(wù)進(jìn)行拆分之后，隨著服務(wù)數(shù)增多，就需要進(jìn)行服務(wù)治理，有效管控服務(wù)，提升服務(wù)運(yùn)行期質(zhì)量，防止業(yè)務(wù)服務(wù)代碼架構(gòu)腐化。

分布式服務(wù)框架：

Dubbo、HSF、Coral Service等。

原文鏈接：https://blog.csdn.net/qq_41723615/article/details/90205947

總結(jié)

以上是生活随笔為你收集整理的hsf 架构_java分布服务：我打赌，没人可以这么精短的讲出分布服务架构吧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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