grpc應用於微服務的分析
gRPC 是一個高性能、開源和通用的 RPC 框架，面向移動和 HTTP/2 設計,目前提供 C、Java 和 Go 語言版本，分別是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持.
gRPC 基於 HTTP/2 標准設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特。這些特性使得其在移動設備上表現更好，更省電和節省空間占用。
gRPC 基於如下思想：定義一個服務， 指定其可以被遠程調用的方法及其參數和返回類型
gRPC 允許你定義四類服務方法：
單項 RPC，即客戶端發送一個請求給服務端，從服務端獲取一個應答，就像一次普通的函數調用。
rpc SayHello(HelloRequest) returns (HelloResponse){}
服務端流式 RPC，即客戶端發送一個請求給服務端，可獲取一個數據流用來讀取一系列消息。客戶端從返回的數據流里一直讀取直到沒有更多消息為止。
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){}
客戶端流式 RPC，即客戶端用提供的一個數據流寫入並發送一系列消息給服務端。一旦客戶端完成消息寫入，就等待服務端讀取這些消息並返回應答。
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {}
雙向流式 RPC，即兩邊都可以分別通過一個讀寫數據流來發送一系列消息。這兩個數據流操作是相互獨立的，所以客戶端和服務端能按其希望的任意順序讀寫，例如：服務端可以在寫應答前等待所有的客戶端消息，或者它可以先讀一個消息再寫一個消息，或者是讀寫相結合的其他方式。每個數據流里消息的順序會被保持。
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){}
兼容restapi方法,如果需要兼容restapi可使用grpc-gateway，可生成swagger文件
https://github.com/grpc-ecosystem/grpc-gateway
使用介紹 http://www.cnblogs.com/lienhua34/p/6285829.html
需要go語言支持
服務發現和負載平衡
以上，grpc提供了數據傳遞的功能，但要把他微服務化還要支持服務發現和負載平衡，grpc並未實現這一塊，因此要應用的話還需考慮此部分，grpc提供了設計思想，並在不同語言的gRPC代碼API中已提供了命名解析和負載均衡接口供擴展（在python中並未找到有這部分）
http://www.tuicool.com/articles/7NzYzuZ中介紹設計思想
方法一：運行在docker下，由docker來負責服務發現和負載平衡，公司目前似乎短時間無法做到
方法二：自行實現,服務發現在用etcd,zookeeper等,推薦使用etcd.
ETCD vs ZK
選取ZK作為典型代表與ETCD進行比較，而不考慮[Consul]項目作為比較對象，原因為Consul的可靠性和穩定性還需要時間來驗證（項目發起方自身服務並未使用Consul, 自己都不用)。
一致性協議： ETCD使用[Raft]協議， ZK使用ZAB（類PAXOS協議），前者容易理解，方便工程實現；
運維方面：ETCD方便運維，ZK難以運維；
項目活躍度：ETCD社區與開發活躍，ZK已經快死了；
API：ETCD提供HTTP+JSON, gRPC接口，跨平台跨語言，ZK需要使用其客戶端；
訪問安全方面：ETCD支持HTTPS訪問，ZK在這方面缺失；
綜上，grpc對go語言支持度更好，使用ptyhon，grpc只做到rpc的數據傳遞，其它方面大部份還要自行再架構
參考：http://www.jianshu.com/p/9805545db4ad再談Docker-微服務的場景化應用
http://www.grpc.io/
---------------------
作者：Candyabc
來源：CSDN
原文：https://blog.csdn.net/Candyabc/article/details/73850604
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！