以太坊rpc源碼

❶ 求一個用C++編寫的RPC方法的例子

去這個專欄看下，我記得當初就是在這學的，最後還有源代碼下載，講得很詳細，祝你學習進步
http://www.cppblog.com/jb8164/archive/2009/10/14/48368.html

第1步：編寫 IDL（Interface Description Language，介面描述語言）文件
-------------------------------------------------------------------------
IDL 是一個通用的工業標准語言，大家應該不陌生，因為 COM 裡面也是用它來描述介面的。
Hello.idl:

[
uuid("4556509F-618A-46CF-AB3D-ED736ED66477"), // 唯一的UUID，用 GUIDGen 生成
version(1.0)
]

interface HelloWorld
{
// 我們定義的方法
void Hello([in,string]const char * psz);
void Shutdown(void);
}

一個可選的文件是應用程序配置文件（.acf），它的作用是對 RPC 介面進行配置，例如下面的 Hello.acf 文件：
Hello.acf:

[
implicit_handle(handle_t HelloWorld_Binding)
]

interface HelloWorld
{

}

上面定義了 implicit_handle，這樣客戶端將綁定句柄 HelloWorld_Binding 了，後面的客戶端代碼中我們會看到。

編譯 IDL 文件：
>midl Hello.idl
Microsoft (R) 32b/64b MIDL Compiler Version 6.00.0366
Copyright (c) Microsoft Corporation 1991-2002. All rights reserved.
Processing .\Hello.idl
Hello.idl
Processing .\Hello.acf
Hello.acf

我們可以看到自動生成了 Hello.h, Hello_s.c, Hello_c.c 文件，這些叫做 rpc stub 程序，不過我們可以不管這個概念，
我們只需要知道 Hello.h 裡面定義了一個

extern RPC_IF_HANDLE HelloWorld_v1_0_s_ifspec;

這個 RPC_IF_HANDLE 將在後面用到。

第2步：編寫服務端程序
-------------------------------------------------------------------------
第1步中我們已經約定了調用的介面，那麼現在我們開始實現其服務端。代碼如下：
server.c

#include <stdlib.h>
#include <stdio.h>
#include "Hello.h" // 引用MIDL 生成的頭文件

/**
* 這是我們在IDL 中定義的介面方法
* 需要注意一點，IDL 裡面的聲明是：void Hello([in,string]const char * psz);
* 但是這里變成了const unsigned char *，為什麼呢？
* 參見MSDN 中的MIDL Command-Line Reference -> /char Switch
* 默認的編譯選項，對 IDL 中的char 按照unsigned char 處理
*/

void Hello(const unsigned char * psz)
{
printf("%s\n", psz);
}

/** 這也是我們在IDL 中定義的介面方法，提供關閉server 的機制*/
void Shutdown(void)
{
// 下面的操作將導致 RpcServerListen() 退出
RpcMgmtStopServerListening(NULL);
RpcServerUnregisterIf(NULL, NULL, FALSE);
}

int main(int argc,char * argv[])
{
// 用Named Pipe 作為RPC 的通道，這樣EndPoint 參數就是Named Pipe 的名字
// 按照Named Pipe 的命名規范，\pipe\pipename，其中pipename 可以是除了\
// 之外的任意字元，那麼這里用一個GUID 串來命名，可以保證不會重復
RpcServerUseProtseqEp((unsigned char *)"ncacn_np", 20, (unsigned char *)"\\pipe\\{8dd50205-3108-498f-96e8-dbc4ec074cf9}", NULL);

// 注冊介面，HelloWorld_v1_0_s_ifspec 是在MIDL 生成的Hello.h 中定義的
RpcServerRegisterIf(HelloWorld_v1_0_s_ifspec, NULL, NULL);

// 開始監聽，本函數將一直阻塞
RpcServerListen(1,20,FALSE);
return 0;
}

// 下面的函數是為了滿足鏈接需要而寫的，沒有的話會出現鏈接錯誤
void __RPC_FAR* __RPC_USER midl_user_allocate(size_t len)
{
return(malloc(len));
}

void __RPC_USER midl_user_free(void __RPC_FAR *ptr)
{
free(ptr);
}

編譯：
>cl /D_WIN32_WINNT=0x500 server.c Hello_s.c rpcrt4.lib
用於 80x86 的 Microsoft (R) 32 位 C/C++ 優化編譯器 14.00.50727.42 版
版權所有(C) Microsoft Corporation。保留所有權利。

server.c
Hello_s.c
正在生成代碼...
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.

/out:server.exe
server.obj
Hello_s.obj
rpcrt4.lib

編譯時為什麼要指定 _WIN32_WINNT=0x500 呢？因為如果沒有的話會報告下面的錯誤：
Hello_s.c(88) : fatal error C1189: #error : You need a Windows 2000 or later to
run this stub because it uses these features:

第3步：編寫客戶端程序
-------------------------------------------------------------------------
客戶端的代碼：
client.c

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include "Hello.h" // 引用MIDL 生成的頭文件

int main(int argc, char * argv[])
{
unsigned char * pszStringBinding = NULL;
if ( argc != 2 )
{
printf("Usage:%s <Hello Text>\n", argv[0]);
return 1;
}

// 用Named Pipe 作為RPC 的通道。參見server.c 中的RpcServerUseProtseqEp() 部分
// 第3 個參數NetworkAddr 如果取NULL，那麼就是連接本機服務
// 否則要取\\\\servername 這樣的格式，例如你的計算機名為jack，那麼就是\\jack
RpcStringBindingCompose( NULL, (unsigned char*)"ncacn_np", /*(unsigned char*)"\\\\servername"*/ NULL, (unsigned char*)"\\pipe\\{8dd50205-3108-498f-96e8-dbc4ec074cf9}", NULL, &pszStringBinding );

// 綁定介面，這里要和 Hello.acf 的配置一致，那麼就是HelloWorld_Binding
RpcBindingFromStringBinding(pszStringBinding, & HelloWorld_Binding );

// 下面是調用服務端的函數了
RpcTryExcept
{
if ( _stricmp(argv[1], "SHUTDOWN") == 0 )
{
Shutdown();
}
else
{
Hello((unsigned char*)argv[1]);
}
}
RpcExcept(1)
{
printf( "RPC Exception %d\n", RpcExceptionCode() );
}
RpcEndExcept

// 釋放資源
RpcStringFree(&pszStringBinding);
RpcBindingFree(&HelloWorld_Binding);
return 0;
}

// 下面的函數是為了滿足鏈接需要而寫的，沒有的話會出現鏈接錯誤
void __RPC_FAR* __RPC_USER midl_user_allocate(size_t len)
{
return(malloc(len));
}

void __RPC_USER midl_user_free(void __RPC_FAR *ptr)
{
free(ptr);
}

編譯：
>cl /D_WIN32_WINNT=0x500 client.c Hello_c.c rpcrt4.lib
用於 80x86 的 Microsoft (R) 32 位 C/C++ 優化編譯器 14.00.50727.42 版
版權所有(C) Microsoft Corporation。保留所有權利。

client.c
Hello_c.c
正在生成代碼...
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.

/out:client.exe
client.obj
Hello_c.obj
rpcrt4.lib

第4步：測試：
-------------------------------------------------------------------------
運行 server.exe，將彈出一個 console 窗口，等待客戶端調用。
運行客戶端 client.exe：

>client hello
可以看到 server.exe 的 console 窗口出現 hello 的字元串。

>client shutdown
server.exe 退出。

❷ 以太坊如何使用web3.js或者rpc介面獲取交易數據交易時間與確認數

如果要查詢主網上的交易記錄，可以使用etherscan。但是，如果是你自己搭建的私鏈，應該如何查詢交易記錄呢？

答案是你需要自己監聽鏈上的日誌，存到資料庫里，然後在這個資料庫中查詢。例如：

varaddr=""
varfilter=web3.eth.filter({fromBlock:0,toBlock:'latest',address:addr});
filter.get(function(err,transactions){
transactions.forEach(function(tx){
vartxInfo=web3.eth.getTransaction(tx.transactionHash);
//這時可以將交易信息txInfo存入資料庫
});
});

web3.eth.filter()用來監聽鏈上的日誌，web3.eth.getTransaction()用來提取指定交易的信息，一旦獲得交易信息，就可以存入資料庫供查詢用了。

推薦一個實戰入門，你可以看看：以太坊教程

❸ 以太坊是什麼丨以太坊開發入門指南

以太坊是什麼丨以太坊開發入門指南
很多同學已經躍躍欲試投入到區塊鏈開發隊伍當中來，可是又感覺無從下手，本文將基於以太坊平台，以通俗的方式介紹以太坊開發中涉及的各晦澀的概念，輕松帶大家入門。
以太坊是什麼
以太坊（Ethereum）是一個建立在區塊鏈技術之上， 去中心化應用平台。它允許任何人在平台中建立和使用通過區塊鏈技術運行的去中心化應用。
對這句話不理解的同學，姑且可以理解為以太坊是區塊鏈里的Android，它是一個開發平台，讓我們就可以像基於Android Framework一樣基於區塊鏈技術寫應用。
在沒有以太坊之前，寫區塊鏈應用是這樣的：拷貝一份比特幣代碼，然後去改底層代碼如加密演算法，共識機制，網路協議等等（很多山寨幣就是這樣，改改就出來一個新幣）。
以太坊平台對底層區塊鏈技術進行了封裝，讓區塊鏈應用開發者可以直接基於以太坊平台進行開發，開發者只要專注於應用本身的開發，從而大大降低了難度。
目前圍繞以太坊已經形成了一個較為完善的開發生態圈：有社區的支持，有很多開發框架、工具可以選擇。
智能合約
什麼是智能合約
以太坊上的程序稱之為智能合約， 它是代碼和數據(狀態)的集合。
智能合約可以理解為在區塊鏈上可以自動執行的（由事件驅動的）、以代碼形式編寫的合同（特殊的交易）。
在比特幣腳本中，我們講到過比特幣的交易是可以編程的，但是比特幣腳本有很多的限制，能夠編寫的程序也有限，而以太坊則更加完備（在計算機科學術語中，稱它為是「圖靈完備的」），讓我們就像使用任何高級語言一樣來編寫幾乎可以做任何事情的程序（智能合約）。
智能合約非常適合對信任、安全和持久性要求較高的應用場景，比如：數字貨幣、數字資產、投票、保險、金融應用、預測市場、產權所有權管理、物聯網、點對點交易等等。
目前除數字貨幣之外，真正落地的應用還不多（就像移動平台剛開始出來一樣），相信1到3年內，各種殺手級會慢慢出現。
編程語言：Solidity
智能合約的默認的編程語言是Solidity，文件擴展名以.sol結尾。
Solidity是和JavaScript相似的語言，用它來開發合約並編譯成以太坊虛擬機位元組代碼。
還有長像Python的智能合約開發語言：Serpent，不過建議大家還是使用Solidity。
Browser-Solidity是一個瀏覽器的Solidity IDE, 大家可以點進去看看，以後我們更多文章介紹Solidity這個語言。
運行環境：EVM
EVM（Ethereum Virtual Machine）以太坊虛擬機是以太坊中智能合約的運行環境。
Solidity之於EVM，就像之於跟JVM的關系一樣，這樣大家就容易理解了。
以太坊虛擬機是一個隔離的環境，在EVM內部運行的代碼不能跟外部有聯系。
而EVM運行在以太坊節點上，當我們把合約部署到以太坊網路上之後，合約就可以在以太坊網路中運行了。
合約的編譯
以太坊虛擬機上運行的是合約的位元組碼形式，需要我們在部署之前先對合約進行編譯，可以選擇Browser-Solidity Web IDE或solc編譯器。
合約的部署
在以太坊上開發應用時，常常要使用到以太坊客戶端（錢包）。平時我們在開發中，一般不接觸到客戶端或錢包的概念，它是什麼呢？
以太坊客戶端（錢包）
以太坊客戶端，其實我們可以把它理解為一個開發者工具，它提供賬戶管理、挖礦、轉賬、智能合約的部署和執行等等功能。
EVM是由以太坊客戶端提供的。
Geth是典型的開發以太坊時使用的客戶端，基於Go語言開發。 Geth提供了一個互動式命令控制台，通過命令控制台中包含了以太坊的各種功能（API）。Geth的使用我們之後會有文章介紹，這里大家先有個概念。
Geth控制台和Chrome瀏覽器開發者工具里的面的控制台是類似，不過是跑在終端里。
相對於Geth，Mist則是圖形化操作界面的以太坊客戶端。
如何部署
智能合約的部署是指把合約位元組碼發布到區塊鏈上，並使用一個特定的地址來標示這個合約，這個地址稱為合約賬戶。
以太坊中有兩類賬戶：
· 外部賬戶
該類賬戶被私鑰控制（由人控制），沒有關聯任何代碼。
· 合約賬戶
該類賬戶被它們的合約代碼控制且有代碼與之關聯。
和比特幣使用UTXO的設計不一樣，以太坊使用更為簡單的賬戶概念。
兩類賬戶對於EVM來說是一樣的。
外部賬戶與合約賬戶的區別和關系是這樣的：一個外部賬戶可以通過創建和用自己的私鑰來對交易進行簽名，來發送消息給另一個外部賬戶或合約賬戶。
在兩個外部賬戶之間傳送消息是價值轉移的過程。但從外部賬戶到合約賬戶的消息會激活合約賬戶的代碼，允許它執行各種動作（比如轉移代幣，寫入內部存儲，挖出一個新代幣，執行一些運算，創建一個新的合約等等）。
只有當外部賬戶發出指令時，合同賬戶才會執行相應的操作。
合約部署就是將編譯好的合約位元組碼通過外部賬號發送交易的形式部署到以太坊區塊鏈上（由實際礦工出塊之後，才真正部署成功）。
運行
合約部署之後，當需要調用這個智能合約的方法時只需要向這個合約賬戶發送消息（交易）即可，通過消息觸發後智能合約的代碼就會在EVM中執行了。
Gas
和雲計算相似，佔用區塊鏈的資源（不管是簡單的轉賬交易，還是合約的部署和執行）同樣需要付出相應的費用（天下沒有免費的午餐對不對!）。
以太坊上用Gas機制來計費，Gas也可以認為是一個工作量單位，智能合約越復雜（計算步驟的數量和類型，佔用的內存等），用來完成運行就需要越多Gas。
任何特定的合約所需的運行合約的Gas數量是固定的，由合約的復雜度決定。
而Gas價格由運行合約的人在提交運行合約請求的時候規定，以確定他願意為這次交易願意付出的費用：Gas價格（用以太幣計價） * Gas數量。
Gas的目的是限制執行交易所需的工作量，同時為執行支付費用。當EVM執行交易時，Gas將按照特定規則被逐漸消耗，無論執行到什麼位置，一旦Gas被耗盡，將會觸發異常。當前調用幀所做的所有狀態修改都將被回滾， 如果執行結束還有Gas剩餘，這些Gas將被返還給發送賬戶。
如果沒有這個限制，就會有人寫出無法停止（如：死循環）的合約來阻塞網路。
因此實際上（把前面的內容串起來），我們需要一個有以太幣余額的外部賬戶，來發起一個交易（普通交易或部署、運行一個合約），運行時，礦工收取相應的工作量費用。
以太坊網路
有些著急的同學要問了，沒有以太幣，要怎麼進行智能合約的開發？可以選擇以下方式：
選擇以太坊官網測試網路Testnet
測試網路中，我們可以很容易獲得免費的以太幣，缺點是需要發很長時間初始化節點。
使用私有鏈
創建自己的以太幣私有測試網路，通常也稱為私有鏈，我們可以用它來作為一個測試環境來開發、調試和測試智能合約。
通過上面提到的Geth很容易就可以創建一個屬於自己的測試網路，以太幣想挖多少挖多少，也免去了同步正式網路的整個區塊鏈數據。
使用開發者網路(模式)
相比私有鏈，開發者網路(模式)下，會自動分配一個有大量余額的開發者賬戶給我們使用。
使用模擬環境
另一個創建測試網路的方法是使用testrpc，testrpc是在本地使用內存模擬的一個以太坊環境，對於開發調試來說，更方便快捷。而且testrpc可以在啟動時幫我們創建10個存有資金的測試賬戶。
進行合約開發時，可以在testrpc中測試通過後，再部署到Geth節點中去。
更新：testrpc 現在已經並入到Truffle 開發框架中，現在名字是Ganache CLI。
Dapp：去中心化的應用程序
以太坊社區把基於智能合約的應用稱為去中心化的應用程序(DecentralizedApp)。如果我們把區塊鏈理解為一個不可篡改的資料庫，智能合約理解為和資料庫打交道的程序，那就很容易理解Dapp了，一個Dapp不單單有智能合約，比如還需要有一個友好的用戶界面和其他的東西。
Truffle
Truffle是Dapp開發框架，他可以幫我們處理掉大量無關緊要的小事情，讓我們可以迅速開始寫代碼-編譯-部署-測試-打包DApp這個流程。
總結
我們現在來總結一下，以太坊是平台，它讓我們方便的使用區塊鏈技術開發去中心化的應用，在這個應用中，使用Solidity來編寫和區塊鏈交互的智能合約，合約編寫好後之後，我們需要用以太坊客戶端用一個有餘額的賬戶去部署及運行合約（使用Truffle框架可以更好的幫助我們做這些事情了）。為了開發方便，我們可以用Geth或testrpc來搭建一個測試網路。
註：本文中為了方便大家理解，對一些概念做了類比，有些嚴格來不是准確，不過我也認為對於初學者，也沒有必要把每一個概念掌握的很細致和准確，學習是一個逐步深入的過程，很多時候我們會發現，過一段後，我們會對同一個東西有不一樣的理解。

❹ 如何安裝 testrpc 和 truffle · EthFans/wiki Wiki · GitHub

For Ubuntu

注意事項: 請勿直接使用 root 用戶，請使用帶有 sudo 許可權的普通用戶安裝 testrpc 和 truffle。
sudo apt-get update

# 安裝系統依賴
sudo apt-get install build-essential git openssl

# 安裝 nodes
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install nodejs

# 修復 npm 全局安裝的文件許可權問題
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'

# 設置 Bash 環境變數
echo [[ -s "$HOME/.profile" ]] && source $HOME/.profile' >> ~/.bash_profile
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.profile
source ~/.profile

# 安裝 testrpc
npm install -g ethereumjs-testrpc

# 安裝 truffle
npm install -g truffle

For Mac
# 安裝 Mac 環境下的編譯套件
xcode-select --install

# 安裝 brew
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

# 安裝 nvm
brew update
brew install nvm
source $(brew --prefix nvm)/nvm.sh
echo "source $(brew --prefix nvm)/nvm.sh" >> ~/.profile

# 通過 nvm 安裝 node
nvm install v5.11.1
nvm alias default 5.11.1

# 安裝 testrpc
npm install -g ethereumjs-testrpc

# 安裝 truffle
npm install -g truffle

❺ 怎麼用rpc查詢以太坊智能合約該筆交易是否out of gas

因為區塊鏈技術對實現智能合約存在天然的優勢。比特幣、瑞泰幣、萊特幣、以太坊等數字加密貨幣都使用了區塊鏈技術。區塊鏈（Blockchain）是比特幣的一個重要概念，本質上是一個去中心化的資料庫，同時作為比特幣的底層技術。區塊鏈是一串使用

❻ rpc框架都有哪些rmi bbo

Dubbo分層

config（配置層 ）

proxy（服務代理層）

registry（ 注冊中心層）

cluster（ 路由層）

monitor（ 監控層）

protocol（ 遠程調用層）

exchange（ 信息交換層）

transport（ 網路傳輸層）

serialize（ 數據序列化層）

對外配置介面
以ServiceConfig, ReferenceConfig為中心，可以直接new配置類，也可以通過spring解析配置生成配置類
Javassist ProxyFactory
Jdk ProxyFactory
服務介面透明代理，生成服務的客戶端Stub和伺服器端Skeleton
以ServiceProxy為中心，擴展介面為ProxyFactory
選擇

Zookeeper

Redis

Multicast

Simple

支持基於網路的集群方式，有廣泛周邊開源產品，建議使用bbo-2.3.3以上版本（推薦使用）
依賴於Zookeeper的穩定性
支持基於客戶端雙寫的集群方式，性能高
要求伺服器時間同步，用於檢查心跳過期臟數據
去中心化，不需要安裝注冊中心
依賴於網路拓普和路由，跨機房有風險
Dogfooding，注冊中心本身也是一個標準的RPC服務
沒有集群支持，可能單點故障
封裝服務地址的注冊與發現
以服務URL為中心，擴展介面為RegistryFactory, Registry, RegistryService
選擇

Spring

Jetty

Log4j

自動載入META-INF/spring目錄下的所有Spring配置
啟動一個內嵌Jetty，用於匯報狀態
大量訪問頁面時，會影響伺服器的線程和內存
自動配置log4j的配置，在多進程啟動時，自動給日誌文件按進程分目錄
用戶不能控制log4j的配置，不靈活
條件路由

腳本路由

基於條件表達式的路由規則，功能簡單易用
有些復雜多分支條件情況，規則很難描述
基於腳本引擎的路由規則，功能強大
沒有運行沙箱，腳本能力過於強大，可能成為後門
Random

RoundRobin

LeastActive

ConsistentHash

隨機，按權重設置隨機概率（推薦使用）
在一個截面上碰撞的概率高，重試時，可能出現瞬間壓力不均
輪循，按公約後的權重設置輪循比率
存在慢的機器累積請求問題，極端情況可能產生雪崩
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差，使慢的機器收到更少請求
不支持權重，在容量規劃時，不能通過權重把壓力導向一台機器壓測容量
一致性Hash，相同參數的請求總是發到同一提供者，當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動
壓力分攤不均
Failover

Failfast

Failsafe

Failback

Forking

Broadcast

失敗自動切換，當出現失敗，重試其它伺服器，通常用於讀操作（推薦使用）
重試會帶來更長延遲
快速失敗，只發起一次調用，失敗立即報錯,通常用於非冪等性的寫操作
如果有機器正在重啟，可能會出現調用失敗
失敗安全，出現異常時，直接忽略，通常用於寫入審計日誌等操作
調用信息丟失
失敗自動恢復，後台記錄失敗請求，定時重發，通常用於消息通知操作
不可靠，重啟丟失
並行調用多個伺服器，只要一個成功即返回，通常用於實時性要求較高的讀操作
需要浪費更多服務資源
廣播調用所有提供者，逐個調用，任意一台報錯則報錯，通常用於更新提供方本地狀態
速度慢，任意一台報錯則報錯
封裝多個提供者的路由及負載均衡，並橋接注冊中心
以Invoker為中心，擴展介面為Cluster, Directory, Router, LoadBalance
Cluster選擇

Router選擇

路由規則

容器

RPC調用次數和調用時間監控
以Statistics為中心，擴展介面為MonitorFactory, Monitor, MonitorService
Dubbo協議

Rmi協議

Hessian協議

連接個數：單連接
連接方式：長連接
傳輸協議：TCP
傳輸方式：NIO非同步傳輸
序列化：Hessian二進制序列化
適用范圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用bbo協議傳輸大文件或超大字元串。
適用場景：常規遠程服務方法調用
採用NIO復用單一長連接，並使用線程池並發處理請求，減少握手和加大並發效率，性能較好（推薦使用）
適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況
Dubbo預設協議不適合傳送大數據量的服務，比如傳文件，傳視頻等，除非請求量很低
Dubbo協議預設每服務每提供者每消費者使用單一長連接，如果數據量較大，可以使用多個連接
為防止被大量連接撐掛，可在服務提供方限制大接收連接數，以實現服務提供方自我保護
在大文件傳輸時，單一連接會成為瓶頸
總結

可與原生RMI互操作，基於TCP協議
偶爾會連接失敗，需重建Stub
參數及返回值需實現Serializable介面
參數及返回值不能自定義實現List, Map, Number, Date, Calendar等介面，只能用JDK自帶的實現，因為hessian會做特殊處理，自定義實現類中的屬性值都會丟失
連接個數：多連接
連接方式：短連接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：Hessian二進制序列化
適用范圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件
適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操作
提供者用Dubbo的Hessian協議暴露服務，消費者直接用標准Hessian介面調用
或者提供方用標准Hessian暴露服務，消費方用Dubbo的Hessian協議調用
基於Hessian的遠程調用協議
可與原生Hessian互操作，基於HTTP協議
需hessian.jar支持，http短連接的開銷大
Hessian協議用於集成Hessian的服務，Hessian底層採用Http通訊，採用Servlet暴露服務，Dubbo預設內嵌Jetty作為伺服器實現
可以和原生Hessian服務互操作

總結

約束

封裝RPC調用
以Invocation, Result為中心，擴展介面為Protocol, Invoker, Exporter
選擇

封裝請求響應模式，同步轉非同步
以Request, Response為中心，擴展介面為Exchanger, ExchangeChannel,ExchangeClient, ExchangeServer
Netty

Mina

Grizzly

性能較好（推薦使用）
一次請求派發兩種事件，需屏蔽無用事件
老牌NIO框架，穩定
待發送消息隊列派發不及時，大壓力下，會出現FullGC
Sun的NIO框架，應用於GlassFish伺服器中
線程池不可擴展，Filter不能攔截下一Filter
抽象mina和netty為統一介面
以Message為中心，擴展介面為Channel, Transporter, Client, Server, Codec
選擇

Hessian

Dubbo

Json

Java

性能較好，多語言支持（推薦使用）
Hessian的各版本兼容性不好，可能和應用使用的Hessian沖突，Dubbo內嵌了hessian3.2.1的源碼
通過不傳送POJO的類元信息，在大量POJO傳輸時，性能較好
當參數對象增加欄位時，需外部文件聲明
純文本，可跨語言解析，預設採用FastJson解析
性能較差
Java原生支持
性能較差
可復用的一些工具
擴展介面為Serialization, ObjectInput, ObjectOutput, ThreadPool
選擇

Business

RPC

Remoting

Service
Config
Proxy
Registry
Cluster
Monitor
Protocol
Exchange
Transport
Serialize
層次結構

層說明

❼ 以太坊架構是怎麼樣的

以太坊最上層的是DApp。它通過Web3.js和智能合約層進行交換。所有的智能合約都運行在EVM（以太坊虛擬機）上，並會用到RPC的調用。在EVM和RPC下面是以太坊的四大核心內容，包括：blockChain, 共識演算法，挖礦以及網路層。除了DApp外，其他的所有部分都在以太坊的客戶端里，目前最流行的以太坊客戶端就是Geth（Go-Ethereum）

❽ 分享一個php如何開發以太坊的教程

以太坊規定了每個節點需要實現的JSON RPC API 應用開發介面，該介面是傳輸無關的，應用程序可以通過HTTP、websocket或IPC等多種 通信機制來使用該介面協議操作以太坊節點：

❾ ETH以太坊Ethereum如何使用RPC調用實現web端充值提現

以太坊源碼go-ethereum怎麼運行
安裝基於MIPS的linux頭文件
$ cd $PRJROOT/kernel
$ tar -xjvf linux-2.6.38.tar.bz2
$ cd linux-2.6.38

在指定路徑下創建include文件夾，用來存放相關頭文件。
$ mkdir -p $TARGET_PREFIX/include

保證linux源碼是干凈的。
$ make mrproper

生成需要的頭文件。
$ make ARCH=mips headers_check
$ make ARCH=mips INSTALL_HDR_PATH=dest headers_install

將dest文件夾下的所有文件復制到指定的include文件夾內。
$ cp -rv dest/include/* $TARGET_PREFIX/include

最後刪除dest文件夾
$ rm -rf dest
$ ls -l $TARGET_PREFIX/include