Swoft之RPC服務介紹

娣辯孩發(fā)布于2019-07-01 10:21 / 1229人閱讀

摘要：微服務做的事情是按照項目顆粒度進行服務的拆分，把模塊多帶帶拿出來做成每一個多帶帶的小項目。給我們提供了的底層服務，我們并不需要去關心底層通訊細節(jié)和調(diào)用的過程。通過定義接口，實現(xiàn)接口，啟動提供接口服務。

RPC 服務

RPC，是一種遠程調(diào)用方式（Remote Procedure Call），通過RPC我們可以像調(diào)用本地方法一樣調(diào)用別的機器上的方法，用戶將無感服務器與服務器之間的通訊。RPC在微服務當中起到相當大的作用，當然RPC不是微服務必須的一種方式，有別的方式也可以實現(xiàn)這種遠程調(diào)用例如RESTful API就可以實現(xiàn)遠程調(diào)用。如果有用過SOAP那么你使用RPC將會覺得很類似，都是可以直接調(diào)用別的機器上的方法。

隨著業(yè)務的發(fā)展我們的項目從簡單的單體結構逐漸的演化成微服務結構，我們?yōu)槭裁匆鸱殖晌⒎漳?？那我們來說說微服務和單體架構的優(yōu)缺點。我們看一下單體架構圖。

單體架構

單體架構優(yōu)點

部署容易，如php寫的項目，只要一個文件夾復制到支持php的環(huán)境就可以了，java只需要一個jar包

測試容易，我們整體項目只要改了一個地方馬上就可以測試得出結果

負載均衡就可以解決，快速部署多個一模一樣的項目在不同的機器運行分流

單體架構的缺點

部署的問題，對于php來說這點還好，但是對于java的項目來說，我們需要重新打包整個項目耗費的時間是很長的

代碼維護，由于所有的代碼都寫在一個項目里面，要想要修改某一個功能點那么需要對項目的整體邏輯和設計有較深的理解，否則代碼耦合嚴重，導致維護難，特別對于新入職的員工來說這將是最容易出現(xiàn)問題的地方

開發(fā)效率低，隨著項目需求的不斷改變和新的功能新增，老舊的代碼又不敢隨便刪除，導致整個項目變得笨重，這將會增加你閱讀代碼的時間

擴展性，在高并發(fā)的情況下，我們往往不是整個項目的每一個功能都處于高流量高請求的情況下的，很多時候都是某一個功能模塊使用的人數(shù)比較多，在單體結構下我們沒有辦法針對單個功能實現(xiàn)分布式擴展，必須整個項目一起部署

微服務架構

在2014年被提出，現(xiàn)在國內(nèi)很多公司已經(jīng)使用，微服務是一種架構設計，并不是說什么框架或者代替什么。微服務做的事情是按照項目顆粒度進行服務的拆分，把模塊多帶帶拿出來做成每一個多帶帶的小項目。微服務的主要特點有：每一個功能模塊是一個小項目、獨立運行在不同進程或者機器上、不同功能可以又不同的人員開發(fā)獨立開發(fā)不松耦合、獨立部署不需要依賴整體項目就可以啟動單個服務、分布式管理。每一個服務只要做好自己的事情就好了。在設計微服務的時候還需要考慮到數(shù)據(jù)庫的問題，是所有微服務使用共同一個數(shù)據(jù)庫還是每一個服務單個數(shù)據(jù)庫

微服務優(yōu)點

拆分業(yè)務，把整體大項目分割成不同小項目運行在不同進程或者機器上實現(xiàn)數(shù)據(jù)隔離

技術棧，每個服務可以又不同的團隊或者開發(fā)者進行開發(fā)，外部調(diào)用人員不需要操心具體怎么實現(xiàn)的，只需要類似調(diào)用自己方法一樣或者接口一樣按照服務提供者給出來的參數(shù)傳遞即可

獨立部署，每一個服務獨立部署，部署一個服務不會影響整體項目，如果部署失敗最多是這個服務的功能缺失，并不影響其他功能的使用

按需部署，針對不同的需求可以給不同的服務自由擴展服務器，根據(jù)服務的規(guī)模部署滿足需求的實例

局部修改，當一個服務有新需求或者其他修改，不需要修改整體項目只要管好自己的服務就好了

微服務缺點

運維，微服務由于把業(yè)務拆分得細，有可能部署在不同機器上，因此對于運維人員的管理來說，這部分的成本會加大

接口調(diào)整，微服務之間通過接口進行通信。如果修改某個微服務的API，可能所有使用了該接口的微服務都需要做調(diào)整；

重復勞動，很多服務可能都會使用到相同的功能。而這個功能并沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發(fā)這一功能，導致代碼重復。

分布式，由于會把不同服務部署在不同機器上，那么對于這些服務的調(diào)用、容錯、網(wǎng)絡延遲、分布式事務等等都是一個很大的挑戰(zhàn)，當然微服務不一定全部都是部署在不同服務器上

服務調(diào)用

如上圖所示，RPC就用于調(diào)用者與服務之間的通訊，RPC協(xié)議可基于TCP、UDP或者HTTP實現(xiàn)，但是更推薦選擇TCP。

例如調(diào)用者需要調(diào)用商品的服務就可以通過RPC或者RESTful API來調(diào)用，那么RPC調(diào)用和RESTful API兩者之間的區(qū)別在哪呢？

TCP的支持保持連接，當調(diào)用服務的時候不需要每次都進行三次握手才實現(xiàn)。從性能和網(wǎng)絡消耗來說RPC都具備了很好的優(yōu)勢。

RESTful API 基于HTTP的，也就是說每次調(diào)用服務都需要進行三次握手建立起通信才可以實現(xiàn)調(diào)用，當我們的并發(fā)量高的時候這就會浪費很多帶寬資源

服務對外的話采用RESTful API會比RPC更具備優(yōu)勢，因此看自己團隊的服務是對內(nèi)還是對外

RPC調(diào)用過程

RPC最主要的作用就是用于服務調(diào)用

本文作為RPC的使用場景開山篇，對于單體架構和微服務的進行了一個描述。這個就是RPC的一個使用場景，也是最常用的一個使用場景。大家只有了解好RPC是什么使用在什么場景才能更好的去使用。

Swoft給我們提供了RPC的底層服務，我們并不需要去關心底層通訊細節(jié)和調(diào)用的過程。

Swoft通過定義接口，實現(xiàn)接口，啟動RPC Server 提供接口服務。我們只需要簡單的寫好幾個類就可以實現(xiàn)一個簡單RPC模塊。

云服務器 GPU云服務器 webrtc介紹之 swoft rpc服務 rpc服務啟動

文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/29092.html

Swoft 源碼剖析 - Swoole和Swoft的那些事 (Http/Rpc服務篇)

摘要：和服務關系最密切的進程是中的進程組，絕大部分業(yè)務處理都在該進程中進行。隨后觸發(fā)一個事件各組件通過該事件進行配置文件加載路由注冊。事件每個請求到來時僅僅會觸發(fā)事件。服務器生命周期和服務基本一致，詳情參考源碼剖析功能實現(xiàn) 作者：bromine鏈接：https://www.jianshu.com/p/4c0...來源：簡書著作權歸作者所有，本文已獲得作者授權轉(zhuǎn)載，并對原文進行了重新的排版。S...

張漢慶 2019-07-01 10:18 評論0 收藏0
Swoft 源碼剖析 - RPC 功能實現(xiàn)

摘要：值得一提的是目前的服務即服務，暫沒有其他的服務功能，所以基本上相關的配置指代的就是。會將請求傳遞給各個中間件，最終最終傳遞給處理。源碼剖析系列目錄作者：bromine鏈接：https://www.jianshu.com/p/411...來源：簡書著作權歸作者所有，本文已獲得作者授權轉(zhuǎn)載，并對原文進行了重新的排版。Swoft Github: https://github.com/swo...

marser 2019-06-28 18:49 評論0 收藏0
Swoft之服務注冊發(fā)現(xiàn)Consul服務器配置

摘要：關于推薦使用的就是，是一個使用寫的服務注冊發(fā)現(xiàn)配置管理系統(tǒng)。遠程過程調(diào)用，這是一種允許客戶端發(fā)出服務器請求的請求響應機制。 Consul服務器配置微服務帶來最大的好處就是把整個大項目分割成不同的服務，運行在不同服務器上，實現(xiàn)解耦和分布式處理。微服務雖然有很多好處，但是也會有不好的一方面。任何事物都會有兩面性，在微服務里面運維會是一個很大的難題，如果有一天我們的服務數(shù)量非常的多，然后我...

SwordFly 2019-07-01 10:22 評論0 收藏0
Swoft 框架 1.0 正式來襲，首個基于 Swoole 原生協(xié)程的 PHP 框架

摘要：歷時年多緊鑼密鼓的開發(fā)，以及愉快而忙碌的春節(jié)假期，期間數(shù)從到快破，碼云首頁推薦，作者和社區(qū)的大力支持，正式版終于要和大家見面。此次更新新增了大量特性在易用性代碼復用性能方面都有所提升?？梢杂糜跇嫿ǜ咝阅艿南到y(tǒng)中間件基礎服務等等。歷時 1 年多緊鑼密鼓的開發(fā)，以及愉快而忙碌的春節(jié)假期，期間 github star 數(shù)從 500 到快破 1k，碼云首頁推薦，Swoole作者 Rango ...

weij 2019-06-28 18:30 評論0 收藏0
Swoft| Swoft 框架組件化改造

摘要：框架組件化改造框架從單體應用到組件化改造的架構升級之路經(jīng)過一年多的開發(fā)框架功能越來越完善也越來越復雜初創(chuàng)時期的單體應用已經(jīng)無法支撐項目的快速發(fā)展于是開發(fā)組在年前為版制定了組件化改造的重構方案內(nèi)容速覽組件化原理包管理基礎知識組件化方案來 date: 2018-3-21 13:22:16title: Swoft| Swoft 框架組件化改造description: Swoft 框架從單體應...

desdik 2019-06-28 18:36 評論0 收藏0