分布式服務架構誕生背景：

在一個不斷發展的大型應用中，新的業務需求和功能不斷增加，技術也在不斷演進，不同團隊構建的功能子系統采用的技術架構五花八門，子系統之間的開發、部署和運維模式也存在較大差異。如果企業內部沒有統一的服務框架進行技術層面的拉通，開發和運維效率都將受到很大制約。

傳統垂直架構改造的核心就是要對應用進行服務化，服務化改造用到核心技術就是分布式服務框架。

分布式服務：

分布式服務顧名思義服務是分散部署在不同的機器上的，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是通過rpc來交互或者是webservice來交互的。邏輯架構設計完后就該做物理架構設計，系統應用部署在超過一臺服務器或虛擬機上，且各分開部署的部分彼此通過各種通訊協議交互信息，就可算作分布式部署，生產環境下的微服務肯定是分布式部署的，分布式部署的應用不一定是微服務架構的，比如集群部署，它是把相同應用復制到不同服務器上，但是邏輯功能上還是單體應用。

分布式服務架構與微服務的區別：

分布式服務架構強調的是服務化以及服務的分散化，微服務則更強調服務的專業化和精細分工；從實踐的角度來看，微服務架構通常是分布式服務架構，反之則未必成立。所以，選擇微服務通常意味著需要解決分布式架構的各種難題。

微服務相比分布式服務來說，它的粒度更小，服務之間耦合度更低，由于每個微服務都由獨立的小團隊負責，因此它敏捷性更高，分布式服務最后都會向微服務架構演化，這是一種趨勢， 不過服務微服務化后帶來的挑戰也是顯而易見的，例如服務粒度小，數量大，后期運維將會很難。

服務化架構演進圖：

MVC：當業務規模很小時，將所有都部署在同一個進程中，通過雙機或者前置負載均衡器實現負載分流；此時，用于分離前后臺邏輯的MVC架構是關鍵。

RPC：當垂直應用越來越多，應用之間交互不可避免，將核心和公共業務抽取出來，作為獨立的服務，實現前后臺邏輯分離，此時，用于提高業務復用及拆分的RPC框架是關鍵。

SOA：隨著業務發展，服務數量愈來愈多，服務生命周期管控和運行狀態的治理成為瓶頸，此時用于提升服務質量的SOA服務治理是關鍵。

微服務：隨著敏捷開發、持續交付、DevOps理論的發展和實踐，以及基于Docker等輕量級容器（LXC）部署應用和服務的成熟，微服務架構開始流行，逐漸成為應用架構的未來演進方向。通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊敏捷交付，應用的交付周期將縮短，運維成本也將大幅下降。

應用從集中式到分布式：

對于集中式的應用，當業務和功能越來越多為應付大流量、高并發的用戶訪問問題，只能通過增加硬件來滿足應用的低延時和高吞吐量。

利用硬件進行擴容只能暫時頂住沖擊，但是遇到棘手問題將無法只是擴容這么簡單：

（1）業務不斷發展
（2）代碼復用是難題
（3）敏捷持續交付面臨巨大挑戰

解決此類問題的有效方案就是進行橫向與縱向的拆分：

縱向拆分：根據業務特性將應用拆分，不同業務模塊獨立部署。

橫向拆分：將核心、公共業務拆分出來，通過分布式服務框架對業務進行服務化，消費者提供標準的契約來消費這些服務。服務提供者獨立打包、部署和演進，與消費者解耦。

服務治理：

使用RPC服務框架對業務進行拆分之后，隨著服務數增多，就需要進行服務治理，有效管控服務，提升服務運行期質量，防止業務服務代碼架構腐化。

分布式服務框架：

Dubbo、HSF、Coral Service等。

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。