grpc應用於微服務的分析,基於python

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
版權聲明：本文爲博主原創文章，轉載請附上博文連接！