本文會介紹gRPC和協議緩衝。gRPC可以使用協議緩衝作爲它的IDL和底層信息交換格式。如果你剛接觸gRPC或者協議緩衝，那就看本文！如果你想深入或者實戰，查看Quick Starts。
概述在GRPC裏，客戶端可以直接調用不同機器上的服務應用的方法，就像是本地對象一樣，所以創建分佈式應用和服務就很簡單了。在很多RPC(Remote Procedure Call Protocol)系統裏，gRPC是基於定義一個服務，指定一個可以遠程調用的帶有參數和返回類型的的方法。在服務端，服務實現這個接口並且運行gRPC服務處理客戶端調用。在客戶端，有一個stub提供和服務端相同的方法。
在各種環境裏，gRPC客戶端和服務端都能運行並且互相通訊 - 從谷歌內部服務到你自己的桌面 - 並且可以寫在任何gRPC支持的語言。比如，可以簡單的創建java作爲gRPC的服務端，Go，Python或者Ruby作爲客戶端。另外，最新的谷歌APIs將會有gRPC版本的接口，可以方便的在應用裏構建Google功能。
使用協議緩衝
默認gRPC使用protocol buffers,Google成熟開源的序列化結構數據(儘管可以使用其他數據格式，比如JSON)。這裏有簡單的介紹他是如何工作的。如果你已經熟悉了協議緩衝，可以直接看下一章節。
使用協議緩衝的第一步是在proto file裏爲數據定義你想序列化的結構：可以是普通的.proto擴展的文本文件。協議緩衝數據結構爲messages，每條message是一個小的邏輯記錄的信息包含一些name-value對名爲fields。比如：
message Person {
string name = 1;
int32 id = 2;
bool has_ponycopter = 3;
}
然後，一旦你指定了你的數據結構，使用協議緩衝解析器protoc生成數據訪問類在proto定義的語言。這些爲每個字段(比如name()和set_name())和方法序列化/解析整個結構到/從raw bytes提供了簡單的訪問器 - 比如，你選擇的語言是C++，對上面的例子運行編譯會生成一個Person類。然後就可以在應用裏使用這個類去populate，序列化和獲取Person協議緩衝messages。
你將會在示例裏看到更詳細的定義在普通proto文件裏的gRPC services，有RPC方法參數和指定的返回類型作爲協議緩衝messages:
// The greeter service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
gRPC同樣使用protoc和指定的gRPC插件從你的proto文件裏生成代碼。但是，使用gRPC插件，你會得到生成的gRPC客戶端和服務端代碼和普通的用來populating，序列化和獲取你的消息類型protocol buffer代碼。我們將會在下面的實例詳細說明。
可以在Protocol Buffers documentation查看更多的關於protocal buffers, 和如何安裝相應語言的protoc和插件。
Protocol buffer versions
雖然protocal buffers有些時候對開源用戶可用，我們的示例使用了新風格的protocal buffers，叫做proto3,有着更簡單的語法，一些有用的新特性，並且支持更多的語言。現在對以下語言可用：Java,C++,Python,Objective-C,C#,alite-runtime(Android Java),Ruby和JavaScript from theprotocol buffers Github repo，同時Go語言生成器golang/protobuf Github repo，還有更多語言在開發中。查看proto3 language guide瞭解更多，還有相關可用的每種語言的文檔，在release notes查看每個版本的區別。更多的proto3文檔還在更新中。
一般，雖然可以使用proto2(當前默認的protocal buffers版本)，我們還是建議你使用proto3搭配gRPC，讓你可以使用全部的gRPC支持的語言，同時避免與proto2客戶端與proto3服務端通選的兼容問題(或者proto3客戶端-proto2服務端的問題)。
應用場景
gRPC已經應用在Google的雲服務和對外提供的API中，其主要應用場景如下：
- 低延遲、高擴展性、分佈式的系統
- 同雲服務器進行通信的移動應用客戶端
- 設計語言獨立、高效、精確的新協議
- 便於各方面擴展的分層設計，如認證、負載均衡、日誌記錄、監控等
與其他rpc比較
與thrift,dubbo,motan等比較
grpc vs thrift:
gRPC優缺點：
> 優點：
protobuf二進制消息，性能好/效率高（空間和時間效率都很不錯）
proto文件生成目標代碼，簡單易用
序列化反序列化直接對應程序中的數據類，不需要解析後在進行映射(XML,JSON都是這種方式)
支持向前兼容（新加字段採用默認值）和向後兼容（忽略新加字段），簡化升級
支持多種語言（可以把proto文件看做IDL文件）
Netty等一些框架集成
> 缺點：
1）GRPC尚未提供連接池，需要自行實現
2）尚未提供“服務發現”、“負載均衡”機制
3）因爲基於HTTP2，絕大部多數HTTP Server、Nginx都尚不支持，即Nginx不能將GRPC請求作爲HTTP請求來負載均衡，而是作爲普通的TCP請求。（nginx1.9版本已支持）
4） Protobuf二進制可讀性差（貌似提供了Text_Fromat功能）
默認不具備動態特性（可以通過動態定義生成消息類型或者動態編譯支持）
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
用人品去感動別人，用改變去影響別人，用狀態去燃燒別人，用行動去帶動別人，用陽光去照耀別人，用堅持去贏得別人，要求自己每天都去做與目標有關的事情，哪怕每天只進步一點點，堅持下來你就是最優秀卓越的！歡迎大家加入大數據交流羣：725967421 一起交流，一起進步！！
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------