grpcpython使用

A. 什麼時候需要用rpc服務

RPC是指遠程過程調用，也就是說兩台伺服器A，B，一個應用部署在A伺服器上，想要調用B伺服器上應用提供的函數/方法，由於不在一個內存空間，不能直接調用，需要通過網路來表達調用的語義和傳達調用的數據。
為什麼要用RPC呢？就是無法在一個進程內，甚至一個計算機內通過本地調用的方式完成的需求，比如不同的系統間的通訊，甚至不同的組織間的通訊，由於計算能力需要橫向擴展，需要在多台機器組成的集群上部署應用。
RPC就是要像調用本地的函數一樣去調遠程函數。在研究RPC前，我們先看看本地調用是怎麼調的。假設我們要調用函數Multiply來計算lvalue * rvalue的結果:
1 int Multiply(int l, int r) {
2 int y = l * r;
3 return y;
4 }
5
6 int lvalue = 10;
7 int rvalue = 20;
8 int l_times_r = Multiply(lvalue, rvalue);
那麼在第8行時，我們實際上執行了以下操作：
將 lvalue 和 rvalue 的值壓棧
進入Multiply函數，取出棧中的值10 和 20，將其賦予 l 和 r
執行第2行代碼，計算 l * r ，並將結果存在 y
將 y 的值壓棧，然後從Multiply返回
第8行，從棧中取出返回值 200 ，並賦值給 l_times_r
以上5步就是執行本地調用的過程。
在遠程調用時，我們需要執行的函數體是在遠程的機器上的，也就是說，Multiply是在另一個進程中執行的。這就帶來了幾個新問題：
Call ID映射。我們怎麼告訴遠程機器我們要調用Multiply，而不是Add或者FooBar呢？在本地調用中，函數體是直接通過函數指針來指定的，我們調用Multiply，編譯器就自動幫我們調用它相應的函數指針。但是在遠程調用中，函數指針是不行的，因為兩個進程的地址空間是完全不一樣的。所以，在RPC中，所有的函數都必須有自己的一個ID。這個ID在所有進程中都是唯一確定的。客戶端在做遠程過程調用時，必須附上這個ID。然後我們還需要在客戶端和服務端分別維護一個 {函數 <--> Call ID} 的對應表。兩者的表不一定需要完全相同，但相同的函數對應的Call ID必須相同。當客戶端需要進行遠程調用時，它就查一下這個表，找出相應的Call ID，然後把它傳給服務端，服務端也通過查表，來確定客戶端需要調用的函數，然後執行相應函數的代碼。序列化和反序列化。客戶端怎麼把參數值傳給遠程的函數呢？在本地調用中，我們只需要把參數壓到棧里，然後讓函數自己去棧里讀就行。但是在遠程過程調用時，客戶端跟服務端是不同的進程，不能通過內存來傳遞參數。甚至有時候客戶端和服務端使用的都不是同一種語言（比如服務端用C++，客戶端用java或者python）。這時候就需要客戶端把參數先轉成一個位元組流，傳給服務端後，再把位元組流轉成自己能讀取的格式。這個過程叫序列化和反序列化。同理，從服務端返回的值也需要序列化反序列化的過程。網路傳輸。遠程調用往往用在網路上，客戶端和服務端是通過網路連接的。所有的數據都需要通過網路傳輸，因此就需要有一個網路傳輸層。網路傳輸層需要把Call ID和序列化後的參數位元組流傳給服務端，然後再把序列化後的調用結果傳回客戶端。只要能完成這兩者的，都可以作為傳輸層使用。因此，它所使用的協議其實是不限的，能完成傳輸就行。盡管大部分RPC框架都使用TCP協議，但其實UDP也可以，而gRPC乾脆就用了HTTP2。Java的Netty也屬於這層的東西。
所以，要實現一個RPC框架，其實只需要把以上三點實現了就基本完成了。Call ID映射可以直接使用函數字元串，也可以使用整數ID。映射表一般就是一個哈希表。序列化反序列化可以自己寫，也可以使用Protobuf或者FlatBuffers之類的。網路傳輸庫可以自己寫socket，或者用asio，ZeroMQ，Netty之類。

B. python grpc如何給proto文件中map類型的變數賦值

改完之後,你可以選擇project->clean,clean後你項目的R.java文件就會重新生成,所有的資源ID會重新分配,這樣子你所修改的資源才能被Android真正識別,有時這個操作不是必要的,但是如果出現你修改了資源後,你的項目中出現了一些問題,那麼執行Clean是一個必須的選擇,這些資源包括drawable下的圖片,布局裡id的修改,values下資源的修改,你可以著手試一下 Good luck

C. grpc原理

1）需要使用protobuf定義介面，即.proto文件

2）然後使用compile工具生成特定語言的執行代碼，比如JAVA、C/C++、Python等。類似於thrift，為了解決跨語言問題。

3）啟動一個Server端，server端通過偵聽指定的port，來等待Client鏈接請求，通常使用Netty來構建，GRPC內置了Netty的支持。

4）啟動一個或者多個Client端，Client也是基於Netty，Client通過與Server建立TCP長鏈接，並發送請求；Request與Response均被封裝成HTTP2的stream Frame，通過Netty Channel進行交互。

對於GRPC的「鼓吹」，本文不多表述，截止到今日，GRPC仍然處於開發階段，尚沒有release版本，而且特性也很多需要補充；GRPC基於protobuf 3.x，但是protobuf 3.x也沒有release版本；雖然HTTP2協議已成定局，但尚未被主流web容器包括代理伺服器支持，這意味著GRPC在HTTP負載均衡方面尚有欠缺；最終，在短期內我們還不能在proction環境中實施，可以做技術儲備。不過GRPC的缺點，在將來將會成為它的優點，我們需要時間等待它的成熟。

1）GRPC尚未提供連接池

2）尚未提供「服務發現」、「負載均衡」機制

3）因為基於HTTP2，絕大部多數HTTP Server、Nginx都尚不支持，即Nginx不能將GRPC請求作為HTTP請求來負載均衡，而是作為普通的TCP請求。（nginx將會在1.9版本支持）

4）GRPC尚不成熟，易用性還不是很理想；就本人而言，我還是希望GRPC能夠像hessian一樣：無IDL文件，無需代碼生成，介面通過HTTP表達。

5）Spring容器尚未提供整合。

在實際應用中，GRPC尚未完全提供連接池、服務自動發現、進程內負載均衡等高級特性，需要開發人員額外的封裝；最大的問題，就是GRPC生成的介面，調用方式實在是不太便捷（JAVA），最起碼與thrift相比還有差距，希望未來能夠有所改進。

D. grpc python，client怎樣給map類型填值

相比於TSimpleServer效率提升主要體現在IO多路復用上，TNonblockingServer採用非阻塞IO，同時監控多個socket的狀態變化；

E. python後端開發需要學什麼

第一階段：Python語言基礎

主要學習Python最基礎知識，如Python3、數據類型、字元串、函數、類、文件操作等。階段課程結束後，學員需要完成Pygame實戰飛機大戰、2048等項目。

第二階段：Python語言高級

主要學習Python庫、正則表達式、進程線程、爬蟲、遍歷以及MySQL資料庫。

第三階段：Pythonweb開發

主要學習HTML、CSS、JavaScript、jQuery等前端知識，掌握python三大後端框架(Django、 Flask以及Tornado)。需要完成網頁界面設計實戰;能獨立開發網站。

第四階段：Linux基礎

主要學習Linux相關的各種命令，如文件處理命令、壓縮解壓命令、許可權管理以及Linux Shell開發等。

第五階段：Linux運維自動化開發

主要學習Python開發Linux運維、Linux運維報警工具開發、Linux運維報警安全審計開發、Linux業務質量報表工具開發、Kali安全檢測工具檢測以及Kali 密碼破解實戰。

第六階段：Python爬蟲

主要學習python爬蟲技術，掌握多線程爬蟲技術，分布式爬蟲技術。

第七階段：Python數據分析和大數據

主要學習numpy數據處理、pandas數據分析、matplotlib數據可視化、scipy數據統計分析以及python 金融數據分析;Hadoop HDFS、python Hadoop MapRece、python Spark core、python Spark SQL以及python Spark MLlib。

第八階段：Python機器學習

主要學習KNN演算法、線性回歸、邏輯斯蒂回歸演算法、決策樹演算法、樸素貝葉斯演算法、支持向量機以及聚類k-means演算法。

關於python後端開發需要學什麼的內容，青藤小編就和您分享到這里了。如果您對python編程有濃厚的興趣，希望這篇文章可以為您提供幫助。如果您還想了解更多關於python編程的技巧及素材等內容，可以點擊本站的其他文章進行學習。

F. grpc python，client怎樣給map類型填值

如下這樣賦值

import hellorequired_pb2
test = hellorequired_pb2.HelloRequired()
test.args["key1"] = "value1"
test.args["key2"] = "value2"
print test
"""
輸出如下
args {
key: "key1"
value: "value1"
}
args {
key: "key2"
value: "value2"
}
"""

G. grpc proto 文件 c++ java 可以共用嗎

ProtoBuf 是一套介面描述語言（IDL）和相關工具集（主要是 protoc，基於 C++ 實現），類似 Apache 的 Thrift）。
用戶寫好 .proto 描述文件，之後使用 protoc 可以很容易編譯成眾多計算機語言（C++、Java、Python、C#、Golang 等）的介面代碼。這些代碼可以支持 gRPC，也可以不支持。

H. 請教python與java之間rpc通信，rabbitmq相關

JSON 簡單粗暴
msgPack格式, 支持廣泛, 類似 JSON , 但是效率更高
Thrift 全家桶, 爽爽爽
protobuf + gRpc

I. 用thrift 或 gRPC 之類的框架做 app 和伺服器的通信合適嗎

完全可以的。
thrift是Facebook開源出來的項目，現在交給了Apache來管理。thrift是用來針對不同語言系統之間數據調用的。thrift支持c,c++,Erlang,java,python,ruby,php等語言。thrift允許定義一個簡單的定義文件中的數據類型和服務介面，這個文件就是IDL（Interface Definition Language），以作為輸入文件，編譯器生成代碼。簡單的說就是thrift定義了統一的文件(對象或者結構體，服務介面)，使用thrift的編譯器能夠生成對應語言的代碼文件。thrft之所以是跨語言的原意就是他通過語言無關的自定義語言來生成語言相關的代碼。

J. grpc使用python時，想做分布式部署，實現負載平衡，求詳細方案