『壹』 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模式，只是每瞎鉛型個框架的使用方式不一樣而已。
『貳』 Feign實現RPC調用
Feign的中文名稱翻譯過來是偽裝
那麼Feign偽裝的是什麼呢？答案很明確，Feign偽裝的是服務提供者。
Feign可以用來做什麼？既然能偽裝，當然能提供服務提供者的功能，即RPC調用服務提供者功能。
step1
新建一個SpringBoot項目，導入web，feign，eureka client的pom依賴；這種依賴在各種IDE及SpringBoot構建網頁上都是直接輸入關鍵字按Enter就可以的
step3
配置負載均衡策略，新建一個類，配置bean Irule就可以了
step4
主類開啟Feign註解@EnableFeignClients，即允模判祥許開啟Feign
step5
關鍵步驟來了，創建一個偽服務提供者介面（不需要實現）旦搏，你偽裝誰@FeignClient的value就寫誰的名字。調用哪個介面就在RequestMapping 的value標注那個介面的url，方法名隨便起，參數沖型要給人間傳過去
step6
創建一個Controller便於前端觀察
step7
啟動eureka server，啟動三個service-hi，啟動service-feign，點擊service-feign
本篇git地址 https://github.com/KouLouYiMaSi/springcloud
『叄』 spring cloud 服務調用方式為什麼使用http restful 而不是RPC
REST是一種架構風格，其核心是面向資源，REST專門針對網路應用設計和開發方式，以降低開發的復雜性，提高系統的可伸縮性。REST提出設計概念和准則為：1.網路上的所有事物都可以被抽象為資源(resource)2.每一個資源都有唯一的資源標識(resourceidentifier)，對資源的操作不會改變這些標識3.所有的操作都是無狀態的REST簡化開發，其架構遵循CRUD原則，該原則告訴我們對於資源(包括網路資源)只需要四種行為：創建，獲取，更新和刪除就可以完成相關的操作和處理。您可以通過統一資源標識符（UniversalResourceIdentifier，URI）來識別和定位資源，並且針對這些資源而執行的操作是通過HTTP規范定義的。其核心操作只有GET,PUT,POST,DELETE。由於REST強制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分布式，集群都不需要考慮上下文和會話保持的問題。極大的提高系統的可伸縮性。對於SOAPWebservice和RestfulWebservice的選擇問題，首先需要理解就是SOAP偏向於面向活動，有嚴格的規范和標准，包括安全，事務等各個方面的內容，同時SOAP強調操作方法和操作對象的分離，有WSDL文件規范和XSD文件分別對其定義。而REST強調面向資源，只要我們要操作的對象可以抽象為資源即可以使用REST架構風格。RESTful應用問題是否使用REST就需要考慮資源本身的抽象和識別是否困難，如果本身就是簡單的類似增刪改查的業務操作，那麼抽象資源就比較容易，而對於復雜的業務活動抽象資源並不是一個簡單的事情。比如校驗用戶等級，轉賬，事務處理等，這些往往並不容易簡單的抽象為資源。其次如果有嚴格的規范和標準定義要求，而且前期規范標准需要指導多個業務系統集成和開發的時候，SOAP風格由於有清晰的規范標準定義是明顯有優勢的。我們可以在開始和實現之前就嚴格定義相關的介面方法和介面傳輸數據。簡單數據操作，無事務處理，開發和調用簡單這些是使用REST架構風格的優勢。而對於較為復雜的面向活動的服務，如果我們還是使用REST，很多時候都是仍然是傳統的面向活動的思想通過轉換工具再轉換得到REST服務，這種使用方式是沒有意義的。效率和易用性SOAP協議對於消息體和消息頭都有定義，同時消息頭的可擴展性為各種互聯網的標准提供了擴展的基礎，WS-*系列就是較為成功的規范。但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP處理方面的性能有所下降。同時在易用性方面以及學習成本上也有所增加。REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。這種高效一方面源於其面向資源介面設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是能夠很好的融合當前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml作為數據承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源信息安全性技術沒有好壞，只有是不是合適，一種好的技術和思想被誤用了，那麼就會得到反效果。REST和SOAP各自都有自己的優點，同時如果在一些場景下如果去改造REST，其實就會走向SOAP（例如安全）。REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會占據主導地位沒有什麼意義，關鍵還是看應用場景。同時很重要一點就是不要扭曲了REST現在很多網站都跟風去開發REST風格的介面，其實都是在學其形，不知其心，最後弄得不倫不類，性能上不去，安全又保證不了。成熟度SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務發布和調用，以及廠商的支持都已經達到了較為成熟的情況。不同平台，開發語言之間通過SOAP來交互的webservice都能夠較好的互通。由於沒有類似於SOAP的權威性協議作為規范，REST實現的各種協議僅僅只能算是私有協議，當然需要遵循REST的思想，但是這樣細節方面有太多沒有約束的地方。REST日後的發展所走向規范也會直接影響到這部分的設計是否能夠有很好的生命力。
『肆』 怎樣通過RPC命令實現區塊鏈的查詢
基本架構如下：
前端web基於socket.io或者REST實現，
後端加一層mongodb/mysql等資料庫來代替單含跡乎機leveldb做數據存儲
目的應該是：
1. 加速查詢
2. 做更高層的數據分析
3.做分布式資料庫
思考:
這些online的查詢固然可以方便我們的日常用， 那如何與相關應用集成呢? 我們是否可以通過簡單的rpc命令實現同等的效果?
有幾個用處：
1 . 大家都可以做自己的qukuai.com或blockchain.info的查詢：）
2. 集成RPC命令到自己的店鋪，收款後查詢用
3. 集成談悉到錢包應用
4. 其他應用場景
cmd分析：
根據高度height查block hash
./bitcoin-cli getblockhash 19999
2. 然後根據block hash查block 信息
./bitcoin-cli getblock
{
"hash" : "",
"confirmations" : 263032,
"size" : 215,
"height" : 19999,
"version" : 1,
"merkleroot" : "",
"tx" : [
""
],
"time" : 1248291140,
"nonce" : 1085206531,
"bits" : "1d00ffff",
"difficulty" : 1.00000000,
"chainwork" : "",
"previousblockhash" : "",
"nextblockhash" : ""
}
3. 根據tx查詢單筆交易的信息：
沒建index時，只能查詢自己錢包的信息，若不是錢包的交易，則返回如下：
./bitcoin-cli getrawtransaction
error: {"code":-5,"message":"Invalid or non-wallet transaction id"}
那怎麼辦州模呢? 直接分析代碼找原因：
// Return transaction in tx, and if it was found inside a block, its hash is placed in hashBlock
bool GetTransaction(const uint256 &hash, CTransaction &txOut, uint256 &hashBlock, bool fAllowSlow)
{
CBlockIndex *pindexSlow = NULL;
{
LOCK(cs_main);
{
if (mempool.lookup(hash, txOut))
{
return true;
}
}
if (fTxIndex) {
CDiskTxPos postx;
if (pblocktree->ReadTxIndex(hash, postx)) {
CAutoFile file(OpenBlockFile(postx, true), SER_DISK, CLIENT_VERSION);
CBlockHeader header;
try {
file >> header;
fseek(file, postx.nTxOffset, SEEK_CUR);
file >> txOut;
} catch (std::exception &e) {
return error("%s : Deserialize or I/O error - %s", __func__, e.what());
}
hashBlock = header.GetHash();
if (txOut.GetHash() != hash)
return error("%s : txid mismatch", __func__);
return true;
}
}
if (fAllowSlow) { // use coin database to locate block that contains transaction, and scan it
int nHeight = -1;
{
CCoinsViewCache &view = *pcoinsTip;
CCoins coins;
if (view.GetCoins(hash, coins))
nHeight = coins.nHeight;
}
if (nHeight > 0)
pindexSlow = chainActive[nHeight];
}
}
if (pindexSlow) {
CBlock block;
if (ReadBlockFromDisk(block, pindexSlow)) {
BOOST_FOREACH(const CTransaction &tx, block.vtx) {
if (tx.GetHash() == hash) {
txOut = tx;
hashBlock = pindexSlow->GetBlockHash();
return true;
}
}
}
}
return false;
}
『伍』 什麼是電腦的open system
開放系統,Windows開放式系統體系結構(WOSA) Windows Open System Architecture(WOSA)
WOSA是Microsoft在Windows環境為跨越不同平台的應用程序而開發的體系結構規劃。它制定允許信息在企業內部自由流動的標准。WOSA包括模塊化應用程序編程介面(API)，它向任何開發人員開發的應用程序提供訪問網路服務的能力。這些網路服務可以包括：電子函件、資料庫和主機連接。WOSA還提供插入任何開發人員開發的後端服務的能力。WOSA就是通常稱為的「中間件」策略，它直接在操作系統中建立，試圖刺激允許用戶在網路上進行協作的工作組應用程序的增長。Windows將對消息傳遞系統以及允許用戶快速定位網路上的其它用戶或資源的目錄服務提供了一個通用介面。WOSA還提供公用數據訪問服務和安全性增強附件。WOSA策略類似於Apple開放協作環境(AOCE)策略。
Windows for Workgroups具有它自己的內置Mail和Schelel十群件產品，它實現了WO3A體系結構部件。WOSA還被用於實現OLE(對象鏈接和嵌入)2．0和新的Cario面向對象操作系統。
WOSA為客戶應用實現了一個標准API，並為伺服器應用實現了一個服務提供商介面(SPI)，如圖W-5所示。使用SPI，資料庫廠商可以為Windows環境創造一個WOSA兼容的資料庫啟動程序。然後客戶的應用開發人員就可以創造介面，這些介面可以訪問這個資料庫啟動程序，而不需要專門為訪問這個資料庫編寫特殊代碼。
下面部件已在本書的相應標題下進行了定義，並進行了單獨討論。
消息傳遞應用程序編程介面(MAPI)，在其它應用(例如字處理器或調度程序)工作期間，提供對電子函件功能的訪問。它與廠商無關消息傳遞應用程序介面(VIM)進行競爭。VIM是由Lotus、IBM、Apple、Novell和Borland支持的。
開放式資料庫互聯性(ODBC)定義Windows操作系統部件到前端和後端(客戶機/伺服器)資料庫服務的連接。它的思想是，創立到異構網路上任何伺服器中存儲數據的訪問。資料庫廠商使用ODBC來在他們的產品中提供互操作性，於是用戶就可以使用他們希望使用的任何前端介面來訪問數據。
Windows嵌套字 API傳輸控制協議/網際網路協議(TCP/IP)，是一個用於連接不同計算機的網路通信標准。Windows嵌套字API(也稱為網路運輸協議)的設計是為了解決在Windows中存在的許多不同的TCP/IP之間的不兼容性。
遠程過程調用(RPC)WOSA實現由開放軟體基金會(OSF)的分布式計算環境(DCE)定義的RPC。RPC為將一個應用程序的處理任務分布到網路上的多個計算機提供了一條途徑。RPC開辟了一條真正的分布式處理的途徑。
系統網路體系結構(SNA)API 定義了Windows應用程序訪問IBM主機的途徑。
許可證伺服器API(LSAPI) 幫助管理人員監督和控制許可軟體的使用，並幫助公司遵守法律。
WOSA基於Microsoft的從應用程序中分離出列印機驅動程序的策略。在Windows環境，在初始化期間安裝的列印機驅動程序，可以在以後的任何時間，通過使用一個簡單的過程就被升級或修改。Windows應用程序使用安裝的不具有任何特殊配置的列印機驅動程序。它們自動介面，並利用列印機的特殊特徵和可用的字體。類似地，WOSA兼容伺服器，應用程序自動介面使得它們自己的功能對WOSA兼容的客戶應用程序也是可用的。這種研究極大地簡化了應用程序開發，以及減輕了希望集成網路上的所有不同應用程序和可用數據的網路管理人員的任務。
『陸』 什麼是遠程過程調用
遠程過程調用 Remote Procere Call
進程間通信(IPC)是在多任務操作系統或聯網的計算機之間運行的程序和進程所用的通信技術。有正老裂兩種類型的進程間通信(IPC)。
本地過程調用(LPC)LPC用在多任務操作系統中，使得同時運行的任務能互相會話。這些任務共享內存空間使任務同步和互相發送信息。
遠程過程調用(RPC)RPC類似於LPC，只是在網上工作。RPC開始是出現在Sun微系統公司和HP公司的運行UNIX操作系統的計算機中。
通過IPC和RPC，程序能利用其它程序或計算機處理的進程。客戶機/伺服器模式計算把遠程過程調用與其它技術如消息傳遞一道，作為系統間通信的一種機制。客戶機執行自己的任務，但靠伺服器提供後端文件服務。RPC為客戶機提供向後端伺服器申請服務的通信機制，如圖R-4所示。如果你把客戶機/伺服器應用程序想作是一個分離的程序，伺服器能運行數據訪問部分，因為它離數據最近，客戶機能運行數據表示和與用戶交互的前端部分。這樣，遠程過程調用可看作是把分割的程序通過網路重組的部件。LPC有時也稱耦合(Coupling)機制。
用這種方式分割程序，當用戶要訪問數據含棚時就無需每次拷貝整個資料庫或它的大部分程序到用戶系統。其實，伺服器只處理請求，甚至只執行一些數據計算，把得出的結果再發送給用戶。因為當數據存放在一個地方時，資料庫同步很容易實現，所以多個用戶可同時訪問相同的數據。
分布式計算環境是由一個通信系統——網路連接的計算機集群。很容易把這個網路看成一個計算平台，若是對等方式，其中任何一台計算機都能成為客戶機或伺服器。一些處理任務可被分成獨立運行程序在不同的網路計算機上並行處理，而獨立的程序被交給最適合這個任務的計算機處理。這種策略可利用計算機空閑資源，提高網路的效益。一個典型的企業網包括許多運行著不同操作系統的異構計算機系統。
隨著企業網的產生，開發商必須編制可在各種計算機和網路通信協議中都能運行的程序。現在人們正努力使得遠程過程調用獨立，這意味著開發商就不用考慮底層的網路和網路上數據傳輸所用的協議，下面介紹RPC在開放式軟體基金(OSF)的分布式計算環境(DCC)中實現的相關方法。RPC工作於多種分布式計算環境。
SunSoft的開放網路計算(ONC)的遠過程調用/外部數據表示(RPC/XDR)協議被廣泛採用。在三百一十萬個運行網路文件系統(NFS)的系統中，有二百八十萬個使用ONCRPC庫，並在分布式應用中作為客戶機或伺服器。ONCRPC被IBM的所有操作系統所支持(除了OS/400)。UNIX系統實驗室把RPC/XDR當作是UNIX System V Release 4的一個標准部分。Novell支持下一代ONC+傳輸自立遠程過程調用(TI-RPC)技術．TI-RPC 使用運輸層介面(TLI)實現傳輸自立。TLI提供了一種訪問面向連接或非連接傳輸服務的通用方法(這在「STERAMS環境」中有所敘述)。
Open Software Foundation(OSF)RPC 開放軟體基金會(OSF)的RPC
RPC工具提供了一種編程語言和編譯器，它們使用可看作是本地過程的可運行於客戶機和伺服器上的模塊開發分布式應用程序。運行時設施(run-timefacility)使得分布式應用程序能在多機種異構系統上運行，這樣使得底層體系結舉閉構和運輸協議對於應用程序是透明的。
程序員用介面定義語言(IDL)建立介面定義(interface definition)。IDL是程序員用來設計遠程運行的過程的工具。IDL編譯器把IDL介面定義轉換成與客戶機和伺服器相連的佔位程序(stub)。客戶機上的佔位程序可加入到伺服器的過程，而伺服器上的佔位程序也可加入到客戶機過程。位於客戶機伺服器的RPC運行時設施與佔位程序合作，來提供RPC操作。
異構環境中使用RPC的一個問題在於，不同的機器有不同的數據表示，OSFRPC通過具有調用機器的基本數據表示的特徵調用來解決這個問題。當收到調用時，若根據特徵知道兩台機器數據表示不同的話，接收器就進行數據轉換。
RPC運行時設施提供把客戶機請求傳送給伺服器和在網上發送和接收響應的功能。DCERPC運行時設施也和網路上其它DCE服務相互作用，這些DCE服務有命名、安全和定時服務。運行時設施有下列特徵：
可在多種網路上運行。開發者無需為每個網路編寫特定的應用程序。
提供客戶機或伺服器或網路上的故障恢復。它支持文件系統、資料庫和其它傳輸可變長數據的服務。
提供獨立於任何一個目錄服務的基於名字定位伺服器的方法。
提供安全工具的介面，以防RPC通信遭受破壞。安全服務保證機密信息的保密性和提供鑒別來保護通信完備性。
支持網上並發或並行處理的多線程調度，於是一個應用程序就能同時執行多個操作
提供多供應商提供的系統環境的可移植性和相互操作性。
網路解釋，准確無比
『柒』 什麼是RPC
RPC是遠程過程調用（Remote Procere Call）的縮寫形式。SAP系統RPC調用的原理其實很簡單，有一些類似於三層構架的C/S系統，第三方的客戶程序通過介面調用SAP內部的標准或自定義函數，獲得函數返回的數據進行處理後顯示或列印。
進程間通信（IPC）在多任務操作系統或聯網的計算機之間運行的程序和進程所用的通信技術。有兩種類型的進程間通信（IPC）。
本地過程調用(LPC)LPC用在多任務操作系統中，使得同時運行的任務能互相會話。這些任務共享內存空間使任務同步和互相發送信息。遠程過程調用（RPC)RPC類似於LPC，只是在網上工作。RPC開始是出現在Sun微系統公司和HP公司的運行UNⅨ操作系統的計算機中。
(7)前端rpc調用擴展閱讀
通過IPC和RPC，程序能利用其它程序或計算機處理的進程。客戶機/伺服器模式計算把遠程過程調用與其它技術（如消息傳遞）一道，作為系統間通信的一種機制。客戶機執行自己的任務，但靠伺服器提供後端文件服務。
RPC為客戶機提供向後端伺服器申請服務的通信機制，如圖R-4所示。如果你把客戶機/伺服器應用程序想作是一個分離的程序，伺服器能運行數據訪問部分，因為它離數據最近，客戶機能運行數據表示和與用戶交互的前端部分。這樣，遠程過程調用可看作是把分割的程序通過網路重孝和組的部件。LPC有時也稱耦合（Coupling）機制。
用這種方式分割程序，當用戶笑檔要訪問數據時就無需每次拷貝整個資料庫或它的大部分程序到用戶系統。其實，伺服器只處理請求，甚至只執行一些數據計算，把得出的結果再發送給用戶。因為當數據存放在一個地方時，資料庫同步很容易實現，所以多個用戶可同時訪問相同的數據。
分布式計算環境是由一個通信系統——網路連接的計算機集群。很容易把這個網路看成一個計算平台，若是對等方式，其中任何一台計算機都能成為客戶機或伺服器。
一些處理任務可被分成獨立運行程序在不同的網路計算機上並行處理，而獨立的程序被交給最適合這個任務的計算機處理。這種策略可利巧升盯用計算機空閑資源，提高網路的效益。一個典型的企業網包括許多運行著不同操作系統的異構計算機系統。