rpc編程

❶ Restful 和 RPC 是什麼關系，有啥區別

這兩個不是互斥的，HTTP是不是RPC完全取決於client的具體形式。傳統的RPC一般是基於二進制協議的，client發個二進制包過來（然後阻塞），server處理完回復一個包，client收到後醒來。在二進制協議中一般可以在包中加個id來指明回復和請求的對應關系，這樣我們就能在一個tcp連接上同時發起多個請求和回復。HTTP這種文本協議也可以加id，但由於一些原因（Content-Length可能缺失），即使加了id也做不到一個連接上同時傳多個HTTP消息，所以HTTP協議一般會和server保持多個連接，每個連接上同時最多隻有一個HTTP消息。此種」連接池「方式即為HTTP中的」Keep-alive「。所以即使在HTTP上（或任何協議上），我們仍然可以做到高效地發送一個請求過去，阻塞，等待server處理完後，再醒來。這不就是RPC么。所以這兒的選擇更多是平衡功能和性能。一般來說，面向終端用戶的盡量用Restful HTTP。原因是認知廣，直觀，編程語言都支持HTTP（包括shell，這樣調試起來方便），性能不是那麼重要，方便用戶share鏈接。而面向內部系統的話如果機器不多也可以考慮用Restful HTTP，如果機器很多還是盡量用二進制的RPC吧，畢竟性能差距還是很大的。

❷ 誰能用通俗的語言解釋一下什麼是RPC框架

早期單機時代，一台電腦上運行多個進程，大家各干各的，老死不相往來。假如A進程需要一個畫圖的功能，B進程也需要一個畫圖的功能，程序員就必須為兩個進程都寫一個畫圖的功能。這不是整人么？於是就出現了IPC（Inter-process communication，單機中運行的進程之間的相互通信）。OK，現在A既然有了畫圖的功能，B就調用A進程上的畫圖功能好了，程序員終於可以偷下懶了。

到了網路時代，大家的電腦都連起來了。以前程序只能調用自己電腦上的進程，能不能調用其他機器上的進程呢？於是就程序員就把IPC擴展到網路上，這就是RPC（遠程過程調用）了。現在不僅單機上的進程可以相互通信，多機器中的進程也可以相互通信了。

要知道實現RPC很麻煩呀，什麼多線程、什麼Socket、什麼I/O，都是讓咱們普通程序員很頭疼的事情。於是就有牛人開發出RPC框架（比如，CORBA、RMI、Web Services、RESTful Web Services等等）。

OK，現在可以定義RPC框架的概念了。簡單點講，RPC框架就是可以讓程序員來調用遠程進程上的代碼一套工具。有了RPC框架，咱程序員就輕松很多了，終於可以逃離多線程、Socket、I/O的苦海了。

至於最近java中流行的Netty，沒玩過。但是大致了解過，Netty、Mina是游戲行業做伺服器開發的Java程序員用的比較多的PRC框架（我們學生主要是Java方向的，有不少人畢業後從事游戲開發）。據說互聯網公司用的也比較多。這兩行業都有高並發量的、長連接、分布式、非同步通訊、大數據量等特點。Netty這種RPC框架封裝和優化了Java NIO和非同步網路編程的一些繁瑣的細節，一方面可以讓開發者專注於業務邏輯的實現，一方面只需要調用Netty封裝的API就可以很快編寫出高性能的伺服器。

❸ webservice編程中的RPCServiceClient類在哪個jar包中

RPCServiceClient 需要的Jar包是axis2-adb-1.6.1.jar。
axis2 webservice client端需要的jar包有：
axis2-kernel-1.6.1.jar
axis2-adb-1.6.1.jar
axiom-api-1.2.12.jar
commons-logging-1.1.1.jar
wsdl4j-1.6.2.jar
XmlSchema-1.4.7.jar
axiom-impl-1.2.12.jar
neethi-3.0.1.jar
axis2-transport-local-1.6.1.jar
axis2-transport-http-1.6.1.jar
commons-httpclient-3.1.jar
httpcore-4.0.jar
commons-codec-1.3.jar

❹ RPC、http、tcp/ip、udp、socket以及soap協議都有什麼相同點和不同點

TCP/IP協議是一個協議簇。裡麵包括很多協議的。UDP只是其中的一個。之所以命名為TCP/IP協議，因為TCP,IP協議是兩個很重要的協議，就用他兩命名了。
tcp和udp都是傳輸協議，主要區別是tcp協議連接需要3次握手，斷開需要四次握手，是通過流來傳輸的，就是確定連接後，一直發送信息，傳完後斷開。udp不需要進行連接，直接把信息封裝成多個報文，直接發送。所以udp的速度更快寫，但是不保證數據的完整性和數據順序，（這個是可以在實現時通過驗證手段來手動確定完整性）。
http協議是建立在TCP協議之上的一種應用，是Web聯網的基礎，最顯著的特點是客戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱為「一次連接」。
socket並不是一種協議，是在程序員層面上對TCP/IP協議的封裝和應用。其實是一個調用介面，方便程序員使用TCP/IP協議棧而已。程序員通過socket來使用tcp/ip協議。但是socket並不是一定要使用tcp/ip協議，Socket編程介面在設計的時候，就希望也能適應其他的網路協議。
rpc是一種通過網路從遠程計算機程序上請求服務，而不需要了解底層網路技術的協議。
初學情況下只要了解http協議和調用http協議，java使用httpClient，還有socket編程就好了。RPC我也了解的不多。

❺ prc和plc一樣是否有PRC這個控制器

使用 RPC 編程是在客戶機和伺服器實體之間進行可靠通信的最強大、最高效的方法之一。它為在分布式計算環境中運行的幾乎所有應用程序提供基礎。本文介紹 RPC 客戶機和伺服器之間基本的事件流，然後討論這些事件的運行時處理。
參考：http://www.ibm.com/developerworks/cn/aix/library/au-rpc_programming/

❻ 網路編程用什麼語言

目前通用的編程語言有兩種形式：匯編語言和高級語言。

匯編語言的實質和機器語言是相同的，都是直接對硬體操作，只不過指令採用了英文縮寫的標識符，更容易識別和記憶。它同樣需要編程者將每一步具體的操作用命令的形式寫出來。匯編程序通常由三部分組成：指令、偽指令和宏指令。匯編程序的每一句指令只能對應實際操作過程中的一個很細微的動作，例如移動、自增，因此匯編源程序一般比較冗長、復雜、容易出錯，而且使用匯編語言編程需要有更多的計算機專業知識，但匯編語言的優點也是顯而易見的，用匯編語言所能完成的操作不是一般高級語言所能實現的，而且源程序經匯編生成的可執行文件不僅比較小，而且執行速度很快。

高級語言是目前絕大多數編程者的選擇。和匯編語言相比，它不但將許多相關的機器指令合成為單條指令，並且去掉了與具體操作有關但與完成工作無關的細節，例如使用堆棧、寄存器等，這樣就大大簡化了程序中的指令。同時，由於省略了很多細節，編程者也就不需要有太多的專業知識。

高級語言主要是相對於匯編語言而言，它並不是特指某一種具體的語言，而是包括了很多編程語言，如目前流行的VB、VC、FoxPro、Delphi等，這些語言的語法、命令格式都各不相同。

高級語言所編制的程序不能直接被計算機識別，必須經過轉換才能被執行，按轉換方式可將它們分為兩類:

解釋類：執行方式類似於我們日常生活中的「同聲翻譯」，應用程序源代碼一邊由相應語言的解釋器「翻譯」成目標代碼(機器語言)，一邊執行，因此效率比較低，而且不能生成可獨立執行的可執行文件，應用程序不能脫離其解釋器，但這種方式比較靈活，可以動態地調整、修改應用程序。

編譯類：編譯是指在應用源程序執行之前，就將程序源代碼「翻譯」成目標代碼(機器語言)，因此其目標程序可以脫離其語言環境獨立執行，使用比較方便、效率較高。但應用程序一旦需要修改，必須先修改源代碼，再重新編譯生成新的目標文件(＊ .OBJ)才能執行，只有目標文件而沒有源代碼，修改很不方便。現在大多數的編程語言都是編譯型的，例如Visual C＋＋、Visual Foxpro、Delphi等。

❼ 如何實現一個分布式 RPC 框架

今天，我們一起來實現一個輕量級的RPC框架。
RPC，即 Remote Procere Call（遠程過程調用），說得通俗一點就是：調用遠程計算機上的服務，就像調用本地服務一樣。
RPC 可基於 HTTP 或 TCP 協議，Web Service 就是基於 HTTP 協議的 RPC，它具有良好的跨平台性，但其性能卻不如基於 TCP 協議的 RPC。會兩方面會直接影響 RPC 的性能，一是傳輸方式，二是序列化。
眾所周知，TCP 是傳輸層協議，HTTP 是應用層協議，而傳輸層較應用層更加底層，在數據傳輸方面，越底層越快，因此，在一般情況下，TCP 一定比 HTTP 快。就序列化而言，Java 提供了默認的序列化方式，但在高並發的情況下，這種方式將會帶來一些性能上的瓶頸，於是市面上出現了一系列優秀的序列化框架，比如：Protobuf、Kryo、Hessian、Jackson 等，它們可以取代 Java 默認的序列化，從而提供更高效的性能。
為了支持高並發，傳統的阻塞式 IO 顯然不太合適，因此我們需要非同步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優秀的 NIO.2 支持，用 Java 實現 NIO 並不是遙不可及的事情，只是需要我們熟悉 NIO 的技術細節。
我們需要將服務部署在分布式環境下的不同節點上，通過服務注冊的方式，讓客戶端來自動發現當前可用的服務，並調用這些服務。這需要一種服務注冊表（Service Registry）的組件，讓它來注冊分布式環境下所有的服務地址（包括：主機名與埠號）。
每台 Server 上可發布多個 Service，這些 Service 共用一個 host 與 port，在分布式環境下會提供 Server 共同對外提供 Service。此外，為防止 Service Registry 出現單點故障，因此需要將其搭建為集群環境。
本文將為您揭曉開發輕量級分布式 RPC 框架的具體過程，該框架基於 TCP 協議，提供了 NIO 特性，提供高效的序列化方式，同時也具備服務注冊與發現的能力。根據以上技術需求，我們可使用如下技術選型：
Spring：它是最強大的依賴注入框架，也是業界的權威標准。
Netty：它使 NIO 編程更加容易，屏蔽了 Java 底層的 NIO 細節。
Protostuff：它基於 Protobuf 序列化框架，面向 POJO，無需編寫 .proto 文件。
ZooKeeper：提供服務注冊與發現功能，開發分布式系統的必備選擇，同時它也具備天生的集群能力。
http://blog.csdn.net/l1028386804/article/details/62284352

❽ php rpc好用嗎,有什麼優缺點php rpc框架哪個好

什麼是RPC框架？ 如果用一句話概括RPC就是：遠程調用框架（Remote Procere Call）那什麼是遠程調用？通常我們調用一個php中的方法，比如這樣一個函數方法: localAdd(10, 20)，localAdd方法的具體實現要麼是用戶自己定義的，要麼是php庫函數中自帶的，也就說在localAdd方法的代碼實現在本地，它是一個本地調用！遠程調用意思就是：被調用方法的具體實現不在程序運行本地，而是在別的某個遠程地方。

遠程調用原理

比如 A (client) 調用 B (server) 提供的remoteAdd方法：

• 首先A與B之間建立一個TCP連接；

• 然後A把需要調用的方法名（這里是remoteAdd）以及方法參數（10， 20）序列化成位元組流發送出去；

• B接受A發送過來的位元組流，然後反序列化得到目標方法名，方法參數，接著執行相應的方法調用（可能是localAdd）並把結果30返回；

• A接受遠程調用結果,輸出30。

RPC框架就是把我剛才說的這幾點些細節給封裝起來，給用戶暴露簡單友好的API使用。

遠程調用的好處

解耦：當server需要對方法內實現修改時，client完全感知不到，不用做任何變更；這種方式在跨部門，跨公司合作的時候經常用到，並且方法的提供者我們通常稱為：服務的暴露。

RPC與Socket有什麼區別？

通過上面的簡單闡述，好像RPC與Socket 好像啊。都是調用遠程的方法，都是client/server模式，我之前也寫了一篇文章: 細說socket 那他們有啥區別呢?

RPC（遠程過程調用）採用客戶機/伺服器模式實現兩個進程之間相互通信。socket是RPC經常採用的通信手段之一，RPC是在Socket的基礎上實現的，它比socket需要更多的網路和系統資源。除了Socket，RPC還有其他的通信方法，比如：http、操作系統自帶的管道等技術來實現對於遠程程序的調用。微軟的Windows系統中，RPC就是採用命名管道進行通信。

RPC與REST有什麼區別？

通過了解RPC後，我們知道是RPC是client/server模式的，調用遠程的方法，REST也是我們熟悉的一套API調用協議方法，它也是基於client/server模式的，調用遠程的方法的，那他倆又有啥區別呢？

REST API 和 RPC 都是在 Server端 把一個個函數封裝成介面暴露出去，以供 Client端 調用，不過 REST API 是基於HTTP協議的，REST致力於通過http協議中的POST/GET/PUT/DELETE等方法和一個可讀性強的URL來提供一個http請求。而 RPC 則可以不基於 HTTP協議
因此，如果是後端兩種語言互相調用，用 RPC 可以獲得更好的性能（省去了 HTTP 報頭等一系列東西），應該也更容易配置。如果是前端通過 AJAX 調用後端，那麼用 REST API 的形式比較好（因為無論如何也避不開 HTTP 這道坎）。

php中流行的rpc框架有哪些

既然php是世界上最好的語言，那php中流行的RPC框架有哪些呢？

先列舉下： phprpc，yar, thrift, gRPC, swoole, hprose

因為時間和精力有限，不可能一個一個的去學習和使用，我選幾個世面上用的最多的幾個用下吧。因為RPC原理是一樣的，都是Client/Server模式，只是每個框架的使用方式不一樣而已。