❶ 從 0 到 1：全面理解 RPC 遠程調用
責編 | 胡巍巍
什麼是RPC呢？網路給出的解釋是這樣的：「RPC（Remote Procere Call Protocol）——遠程過程調用協議，它是一種通過網路從遠程計算機程序上請求服務，而不需要了解底層網路技術的協議」。
這個概念聽起來還是比較抽象，沒關系，繼續往後看，後面概念性的東西，我會講得足夠清楚，讓你完全掌握 RPC 的基礎內容。
在 OpenStack 里的進程間通信方式主要有兩種，一種是基於HTTP協議的RESTFul API方式，另一種則是RPC調用。
那麼這兩種方式在應用場景上有何區別呢？
有使用經驗的人，就會知道：
首先，給你提兩個問題，帶著這兩個問題再往下看：
1、RPC 和 REST 區別是什麼？2、為什麼要採用RPC呢？
首先，第一個問題：RPC 和 REST 區別是什麼？
你一定會覺得這個問題很奇怪，是的，包括我，但是你在網路上一搜，會發現類似對比的文章比比皆是，我在想可能很多初學者由於基礎不牢固，才會將不相乾的二者拿出來對比吧。既然是這樣，那為了讓你更加了解陌生的RPC，就從你熟悉得不能再熟悉的 REST 入手吧。
01、所屬類別不同
REST，是Representational State Transfer 的簡寫，中文描述表述性狀態傳遞（是指某個瞬間狀態的資源數據的快照，包括資源數據的內容、表述格式(XML、JSON)等信息。）
REST 是一種軟體架構風格。這種風格的典型應用，就是HTTP。其因為簡單、擴展性強的特點而廣受開發者的青睞。
而RPC 呢，是 Remote Procere Call Protocol 的簡寫，中文描述是遠程過程調用，它可以實現客戶端像調用本地服務(方法)一樣調用伺服器的服務(方法)。
而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的，按理說它和REST不是一個層面意義上的東西，不應該放在一起討論，但是誰讓REST這么流行呢，它是目前最流行的一套互聯網應用程序的API設計標准，某種意義下，我們說 REST 可以其實就是指代 HTTP 協議。
02、使用方式不同
03、面向對象不同
從設計上來看，RPC，所謂的遠程過程調用 ，是面向方法的 ，REST：所謂的 Representational state transfer ，是面向資源的，除此之外，還有一種叫做 SOA，所謂的面向服務的架構，它是面向消息的，這個接觸不多，就不多說了。
04、序列化協議不同
介面調用通常包含兩個部分，序列化和通信協議。
通信協議，上面已經提及了，REST 是 基於 HTTP 協議，而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的。
常見的序列化協議，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是 JSON-RPC，或者 XML-RPC。
通過以上幾點，我們知道了 REST 和 RPC 之間有很明顯的差異。
然後第二個問題：為什麼要採用RPC呢？
那到底為何要使用 RPC，單純的依靠RESTful API不可以嗎？為什麼要搞這么多復雜的協議，渣渣表示真的學不過來了。
關於這一點，以下幾點僅是我的個人猜想，僅供交流哈：
說了這么多，我們該如何選擇這兩者呢？我總結了如下兩點，供你參考：
「遠程調用」意思就是：被調用方法的具體實現不在程序運行本地，而是在別的某個地方（分布到各個伺服器），調用者只想要函數運算的結果，卻不需要實現函數的具體細節。
光說不練嘴把式，接下來，我將分別用三種不同的方式全面地讓你搞明白 rpc 遠程調用是如何實現的。
01、基於 xml-rpc
Python實現 rpc，可以使用標准庫里的 SimpleXMLRPCServer，它是基於XML-RPC 協議的。
有了這個模塊，開啟一個 rpc server，就變得相當簡單了。執行以下代碼：
有了 rpc server，接下來就是 rpc client，由於我們上面使用的是 XML-RPC，所以 rpc clinet 需要使用xmlrpclib 這個庫。
然後，我們通過 server_proxy 對象就可以遠程調用之前的rpc server的函數了。
SimpleXMLRPCServer是一個單線程的伺服器。這意味著，如果幾個客戶端同時發出多個請求，其它的請求就必須等待第一個請求完成以後才能繼續。
若非要使用 SimpleXMLRPCServer 實現多線程並發，其實也不難。只要將代碼改成如下即可。
02、基於json-rpc
SimpleXMLRPCServer 是基於 xml-rpc 實現的遠程調用，上面我們也提到 除了 xml-rpc 之外，還有 json-rpc 協議。
那 python 如何實現基於 json-rpc 協議呢？
答案是很多，很多web框架其自身都自己實現了json-rpc，但我們要獨立這些框架之外，要尋求一種較為干凈的解決方案，我查找到的選擇有兩種
第一種是 jsonrpclib
第二種是 python-jsonrpc
先來看第一種 jsonrpclib
它與 Python 標准庫的 SimpleXMLRPCServer 很類似（因為它的類名就叫做 SimpleJSONRPCServer ，不明真相的人真以為它們是親兄弟）。或許可以說，jsonrpclib 就是仿照 SimpleXMLRPCServer 標准庫來進行編寫的。
它的導入與 SimpleXMLRPCServer 略有不同，因為SimpleJSONRPCServer分布在jsonrpclib庫中。
服務端
客戶端
再來看第二種python-jsonrpc，寫起來貌似有些復雜。
服務端
客戶端
調用過程如下
還記得上面我提到過的 zabbix API，因為我有接觸過，所以也拎出來講講。zabbix API 也是基於 json-rpc 2.0協議實現的。
因為內容較多，這里只帶大家打個，zabbix 是如何調用的：直接指明要調用 zabbix server 的哪個方法，要傳給這個方法的參數有哪些。
03、基於 zerorpc
以上介紹的兩種rpc遠程調用方式，如果你足夠細心，可以發現他們都是http+rpc 兩種協議結合實現的。
接下來，我們要介紹的這種（zerorpc），就不再使用走 http 了。
zerorpc 這個第三方庫，它是基於TCP協議、 ZeroMQ 和 MessagePack的，速度相對快，響應時間短，並發高。zerorpc 和 pyjsonrpc 一樣，需要額外安裝，雖然SimpleXMLRPCServer不需要額外安裝，但是SimpleXMLRPCServer性能相對差一些。
調用過程如下
客戶端除了可以使用zerorpc框架實現代碼調用之外，它還支持使用「命令行」的方式調用。
客戶端可以使用命令行，那服務端是不是也可以呢？
是的，通過 Github 上的文檔幾個 demo 可以體驗到這個第三方庫做真的是優秀。
比如我們可以用下面這個命令，創建一個rpc server，後面這個 time Python 標准庫中的 time 模塊，zerorpc 會將 time 注冊綁定以供client調用。
經過了上面的學習，我們已經學會了如何使用多種方式實現rpc遠程調用。
通過對比，zerorpc 可以說是脫穎而出，一支獨秀。
為此，我也做了一番思考：
OpenStack 組件繁多，在一個較大的集群內部每個組件內部通過rpc通信頻繁，如果都採用rpc直連調用的方式，連接數會非常地多，開銷大，若有些 server 是單線程的模式，超時會非常的嚴重。
OpenStack 是復雜的分布式集群架構，會有多個 rpc server 同時工作，假設有 server01，server02，server03 三個server，當 rpc client 要發出rpc請求時，發給哪個好呢？這是問題一。
你可能會說輪循或者隨機，這樣對大家都公平。這樣的話還會引出另一個問題，倘若請求剛好發到server01，而server01剛好不湊巧，可能由於機器或者其他因為導致服務沒在工作，那這個rpc消息可就直接失敗了呀。要知道做為一個集群，高可用是基本要求，如果出現剛剛那樣的情況其實是很尷尬的。這是問題二。
集群有可能根據實際需要擴充節點數量，如果使用直接調用，耦合度太高，不利於部署和生產。這是問題三。
引入消息中間件，可以很好的解決這些問題。
解決問題一：消息只有一份，接收者由AMQP的負載演算法決定，默認為在所有Receiver中均勻發送(round robin)。
解決問題二：有了消息中間件做緩沖站，client 可以任性隨意的發，server 都掛掉了？沒有關系，等 server 正常工作後，自己來消息中間件取就行了。
解決問題三：無論有多少節點，它們只要認識消息中間件這一個中介就足夠了。
既然講到了消息隊列，如果你之前沒有接觸過這塊內容，最好花幾分鍾的時間跟我好好過下關於消息隊列的幾個基礎概念。
首先，RPC只是定義了一個通信介面，其底層的實現可以各不相同，可以是 socket，也可以是今天要講的 AMQP。
AMQP(Advanced Message Queuing Protocol)是一種基於隊列的可靠消息服務協議，作為一種通信協議，AMQP同樣存在多個實現，如Apache Qpid，RabbitMQ等。
以下是 AMQP 中的幾個必知的概念：
Publisher：消息發布者
Queue：用來保存消息的存儲空間，消息沒有被receiver前，保存在隊列中。
Exchange：用來接收Publisher發出的消息，根據Routing key 轉發消息到對應的Message Queue中，至於轉到哪個隊列里，這個路由演算法又由exchange type決定的。
Exchange type：主要四種描述exchange的類型。
direct：消息路由到滿足此條件的隊列中(queue,可以有多個)：routing key = binding key
topic：消息路由到滿足此條件的隊列中(queue,可以有多個)：routing key 匹配 binding pattern. binding pattern是類似正則表達式的字元串，可以滿足復雜的路由條件。
fanout：消息路由到多有綁定到該exchange的隊列中。
binding ：binding是用來描述exchange和queue之間的關系的概念，一個exchang可以綁定多個隊列，這些關系由binding建立。前面說的binding key /binding pattern也是在binding中給出。
為了讓你明白這幾者的關系，我畫了一張模型圖。
關於AMQP，有幾下幾點值得注意：
前面鋪墊了那麼久，終於到了講真實應用的場景。在生產中RPC是如何應用的呢？
其他模型我不太清楚，在 OpenStack 中的應用模型是這樣的
至於為什麼要如此設計，前面我已經給出了自己的觀點。
接下來，就是源碼解讀 OpenStack ，看看其是如何通過rpc進行遠程調用的。如若你對此沒有興趣（我知道很多人對此都沒有興趣，所以不浪費大家時間），可以直接跳過這一節，進入下一節。
目前Openstack中有兩種RPC實現，一種是在oslo messaging,一種是在openstack.common.rpc。
openstack.common.rpc是舊的實現，oslo messaging是對openstack.common.rpc的重構。openstack.common.rpc在每個項目中都存在一份拷貝，oslo messaging即將這些公共代碼抽取出來，形成一個新的項目。oslo messaging也對RPC API 進行了重新設計，對多種 transport 做了進一步封裝，底層也是用到了kombu這個AMQP庫。（註：Kombu 是Python中的messaging庫。Kombu旨在通過為AMQ協議提供慣用的高級介面，使Python中的消息傳遞盡可能簡單，並為常見的消息傳遞問題提供經過驗證和測試的解決方案。）
關於oslo_messaging庫，主要提供了兩種獨立的API:
因為 notify 實現是太簡單了，所以這里我就不多說了，如果有人想要看這方面內容，可以收藏我的博客(http://python-online.cn) ，我會更新補充 notify 的內容。
OpenStack RPC 模塊提供了 rpc.call，rpc.cast, rpc.fanout_cast 三種 RPC 調用方法，發送和接收 RPC 請求。
rpc.call 和 .rpc.cast 從實現代碼上看，他們的區別很小，就是call調用時候會帶有wait_for_reply=True參數，而cast不帶。
要了解 rpc 的調用機制呢，首先要知道 oslo_messaging 的幾個概念主要方法有四個：
transport：RPC功能的底層實現方法，這里是rabbitmq的消息隊列的訪問路徑
transport 就是定義你如何訪連接消息中間件，比如你使用的是 Rabbitmq，那在 nova.conf中應該有一行transport_url的配置，可以很清楚地看出指定了 rabbitmq 為消息中間件，並配置了連接rabbitmq的user，passwd，主機，埠。
target用來表述 RPC 伺服器監聽topic，server名稱和server監聽的exchange，是否廣播fanout。
rpc server 要獲取消息，需要定義target，就像一個門牌號一樣。
rpc client 要發送消息，也需要有target，說明消息要發到哪去。
endpoints：是可供別人遠程調用的對象
RPC伺服器暴露出endpoint，每個 endpoint 包涵一系列的可被遠程客戶端通過 transport 調用的方法。直觀理解，可以參考nova-conctor創建rpc server的代碼，這邊的endpoints就是 nova/manager.py:ConctorManager
dispatcher：分發器，這是 rpc server 才有的概念
只有通過它 server 端才知道接收到的rpc請求，要交給誰處理，怎麼處理？
在client端，是這樣指定要調用哪個方法的。
而在server端，是如何知道要執行這個方法的呢？這就是dispatcher 要乾的事，它從 endpoint 里找到這個方法，然後執行，最後返回。
Serializer：在 python 對象和message(notification) 之間數據做序列化或是反序列化的基類。
主要方法有四個：
每個notification listener都和一個executor綁定，來控制收到的notification如何分配。默認情況下，使用的是blocking executor(具體特性參加executor一節）
模仿是一種很高效的學習方法，我這里根據 OpenStack 的調用方式，抽取出核心內容，寫成一個簡單的 demo，有對 OpenStack 感興趣的可以了解一下，大部分人也可以直接跳過這章節。
注意以下代碼不能直接運行，你還需要配置 rabbitmq 的連接方式，你可以寫在配置文件中，通過 get_transport 從cfg.CONF 中讀取，也可以直接將其寫成url的格式做成參數，傳給 get_transport 。而且還要nova或者其他openstack組件的環境中運行（因為需要有ctxt這個環境變數）
簡單的 rpc client
簡單的 rpc server
【End】
熱 文 推 薦
☞Facebook 發幣 Libra；谷歌十億美金為窮人造房；第四代樹莓派 Raspberry Pi 4 發布 | 開發者周刊
☞WebRTC 將一統實時音視頻天下？
☞小米崔寶秋：小米 AIoT 深度擁抱開源
☞華為在美研發機構 Futurewei 意欲分家？
☞老司機教你如何寫出沒人敢維護的代碼！
☞Python有哪些技術上的優點？比其他語言好在哪兒？
☞上不了北大「圖靈」、清華「姚班」，AI專業還能去哪上？
☞公鏈史記 | 從鴻蒙初辟到萬物生長的十年激盪……
☞邊緣計算容器化是否有必要？
☞馬雲曾經偶像，終於把阿里留下的1400億敗光了！
你點的每個「在看」，我都認真當成了喜歡
❷ 如何使用Python連接遠程Windows伺服器
在伺服器的電腦上添加第二塊網卡，用於連接Internet。用域管理員賬戶在遠程訪問伺服器上登錄。為第二塊網卡添加公網IP地址
在遠程訪問伺服器上，從「管理工具」中打開，「伺服器管理器」窗口，選中「角色」，單擊「添加角色」，打開「添加角色向導」窗口。
在彈出來的「開始之前」窗口中點擊「是」按鈕。
單擊「下一步」「進入選擇伺服器角色」」窗口，選擇「網路策略和訪問服務」單擊「下一步」。
在「網路策略和訪問服務」簡介窗口單擊「下一步」，在「選擇角色服務」窗口選擇「路由和遠程訪問服務」。
接下來會顯示安裝進度
等安裝好了以後，點擊關閉就可以了。
❸ RPC框架（1 - 實現服務端注冊一個服務）
基於這樣一個假設，那就是客戶端已經知道了服務端的地址，這部分會由後續的服務發現機制完善。通用介面
hello方法需要傳遞一個對象，HelloObject對象，定義如下：
注意這個對象需要實現 Serializable 介面，因為它需要在調用過程中從客戶端傳遞給服務端。
接著我們在服務端對這個介面進行實現，實現的方式也很簡單，返回一個字元串就行：
服務端需要哪些信息，才能唯一確定服務端需要調用的介面的方法呢？
那麼服務端知道以上四個條件，就可以找到這個方法並且調用了。我們把這四個條件寫到一個對象里，到時候傳輸時傳輸這個對象就行了。即 RpcRequest 對象：
那麼伺服器調用完這個方法後，需要給客戶端返回哪些信息呢？
如果調用成功的話，顯然需要返回值，如果調用失敗了，就需要失敗的信息，這里封裝成一個 RpcResponse 對象：
這里還多寫了兩個靜態方法，用於快速生成成功與失敗的響應對象。其中，statusCode屬性可以自行定義，客戶端服務端一致即可。
客戶端方面，由於在 客戶端這一側我們並沒有介面的具體實現類，就沒有辦法直接生成實例對象 。這時，我們可以 通過動態代理的方式生成實例，並且調用方法時生成需要的RpcRequest對象並且發送給服務端 。
這里我們採用JDK動態代理，代理類是需要實現 InvocationHandler 介面的。
我們需要傳遞host和port來指明服務端的位置。並且使用getProxy()方法來生成代理對象。
InvocationHandler 介面需要實現invoke()方法，來指明代理對象的方法被調用時的動作。 在這里，我們顯然就需要生成一個RpcRequest對象，發送出去，然後返回從服務端接收到的結果即可：
生成RpcRequest很簡單，我 使用Builder模式來生成這個對象 。發送的邏輯我使用了一個RpcClient對象來實現，這個對象的作用， 就是將一個對象發過去，並且接收返回的對象。
我的實現很簡單，直接使用Java的序列化方式，通過Socket傳輸。 創建一個Socket，獲取ObjectOutputStream對象，然後把需要發送的對象傳進去即可，接收時獲取ObjectInputStream對象，readObject()方法就可以獲得一個返回的對象。
服務端的實現就簡單多了， 使用一個ServerSocket監聽某個埠，循環接收連接請求，如果發來了請求就創建一個線程，在新線程中處理調用。 這里創建線程採用線程池：
這里簡化了一下， RpcServer暫時只能注冊一個介面，即對外提供一個介面的調用服務，添加register方法，在注冊完一個服務後立刻開始監聽：
這里向工作線程WorkerThread傳入了socket和用於服務端實例service。
WorkerThread實現了Runnable介面，用於接收RpcRequest對象，解析並且調用，生成RpcResponse對象並傳輸回去。 run方法如下：
其中，通過class.getMethod方法，傳入方法名和方法參數類型即可獲得Method對象。如果你上面RpcRequest中使用String數組來存儲方法參數類型的話，這里你就需要通過反射生成對應的Class數組了。通過method.invoke方法，傳入對象實例和參數，即可調用並且獲得返回值。
服務端側，我們已經在上面實現了一個HelloService的實現類HelloServiceImpl，我們只需要創建一個RpcServer並且把這個實現類注冊進去就行了：
服務端開放在9000埠。
客戶端方面，我們需要通過動態代理，生成代理對象，並且調用，動態代理會自動幫我們向服務端發送請求的：
我們這里生成了一個HelloObject對象作為方法的參數。
首先啟動服務端，再啟動客戶端,測試結果：
❹ python怎麼經過protobuf完成rpc
客戶方像挪用當地辦法同樣去挪用長途介面辦法，RPC 結構供給介面的署理完成，理論的挪用將拜託給署理RpcProxy
。署理封裝挪用資訊並將挪用轉交給RpcInvoker 去理論履行。在客戶真個RpcInvoker 經過銜接器RpcConnector
去保持與效勞端的通道RpcChannel，並運用RpcProtocol
履行協定編碼（encode）並將編碼後的懇求音訊經過通道發送給效勞方。RPC 效勞端接納器 RpcAcceptor
接納客戶真個挪用懇求，一樣運用RpcProtocol 履行協定解碼（decode）。解碼後的挪用資訊傳送給RpcProcessor
去掌握處置挪用進程，末了再拜託挪用給RpcInvoker 去理論履行並前往挪用後果。
protobuf
rpc在下面組件中首要表演RpcProtocol的人物，使得咱們省去了協定的描繪，而且protobuf協定在編碼和時間效力都是上十分高效的，這也是許多公司選用protobuf作為數值序列化和通訊協議的起因。一起protobuf
rpc界說了一個籠統的rpc結構，以下圖所示：
RpcServiceStub和RpcService類是protobuf編譯器依據proto界說天生的類，RpcService界說了效勞端表露給客戶真個函數介面，詳細完成需求用戶本人擔當這個類來完成。RpcServiceStub界說了效勞端表露函數的描繪，並將客戶端對RpcServiceStub中函數的挪用同一轉換到挪用RpcChannel中的CallMethod辦法，CallMethod經過RpcServiceStub傳過去的函數描繪符和函數參數對該次rpc挪用停止encode，最後經過RpcConnecor發送給效勞方。自己以客戶端相反的進程最後挪用RpcSerivice中界說的函數。現實上，protobuf
rpc的結構僅僅RpcChannel中界說了空的CallMethod，以是詳細怎麼樣停止encode和挪用RpcConnector都要本人完成。RpcConnector在protobuf中沒有界說，以是這個完結由用戶本人完成，它的效果那是收發rpc音訊包。在效勞端，RpcChannel經過挪用RpcService中的CallMethod來詳細挪用RpcService中表露給客戶真個函數。
引見了這么多，關於怎樣用protobuf rpc來完成一個rpc確定仍是一頭霧水吧，下面就用protobuf rpc來完成一個簡略的python版rpc demo吧。
下面間接給出demo描繪PRC的proto文件，至於proto文件的編寫規定能夠參考protobuf官網。
common.proto文件：
package game;
message RequestMessage
{
required string message = 1;
}
message ResponseMessage
{
required string message = 1;
}
game_service.proto文件：
package game;
import "common.proto";
option py_generic_services = true;
service GameService
{
rpc connect_server(RequestMessage) returns(RequestMessage);
}
common.proto文件描繪了RPC中收發的音訊；game_service.proto描繪了效勞器導出的connect_server函數，該函數承受RequestMessage目標作為參數，並前往RequestMessage目標。在運用PRC協定時，必需加之option
py_generic_services =
true;可選項，要否則編譯器不會天生蘊含connect_server函數的GameService描繪。
運用編譯器protoc編譯proto文件，詳細號令為：
protoc.exe --python_out=. game_service.proto
編譯後天生的文件為game_service_pb2.py，該文件首要是完成了GameService和GameService_Stub類。GameService_Stub類用於客戶端挪用者來挪用GameService的效勞。
後面曾經說了，在客戶端，RpcChannel只完成了一個空的CallMethod，以是需求擔當RpcChannel從新這個函數來encode音訊和發送音訊。在效勞端RpcChannel需求挪用CallMethod來挪用Service中的函數。詳細完成以下：
class MyRpcChannel(service.RpcChannel):
def __init__(self, rpc_service, conn):
super(MyRpcChannel, self).__init__()
self.logger = LogManager.get_logger("MyRpcChannel")
def CallMethod(self, method_descriptor, rpc_controller, request, response_class, done):
""""protol buffer rpc 需求的函數，用來發送rpc挪用"""
self.logger.info('CallMethod')
cmd_index = method_descriptor.index
assert(cmd_index < 65535)
data = request.SerializeToString()
total_len = len(data) + 2
self.conn.send_data(''.join([pack('<I', total_len), pack('<H', cmd_index), data]))
def from_request(self):
""""從收集剖析出一個完好的懇求以後調的函數"""
index_data = self.rpc_request.data[0:2]
cmd_index = unpack('<H', index_data)[0]
rpc_service = self.rpc_service
s_descriptor = rpc_service.GetDescriptor()
method = s_descriptor.methods[cmd_index]
try:
request = rpc_service.GetRequestClass(method)()
serialized = self.rpc_request.data[2:]
request.ParseFromString(serialized)
rpc_service.CallMethod(method, self.controller, request, None)
except:
self.logger.error("Call rpc method failed!")
self.logger.log_last_except()
return True
末了那是擔當GameService，並完成connect_server函數了。
class GameService(game_service_pb2.GameService):
def __init__(self):
self.logger = LogManager.get_logger("GameService")
def connect_server(self, rpc_controller, request, callback):
self.logger.info('%s', request.message)
至於用於收集收發音訊的RpcConnector，可使用python的asyncore庫完成，詳細完成在這就不評論了。
從下面的完成來看，protobuf rpc的完成首要囊括編寫proto文件並編譯天生對應的service_pb2文件，擔當RpcChannel並完成CallMethod和挪用Service的CallMethod，擔當Service來完成表露給客戶真個函數。
❺ Python實現WebService介面(SOAP)
Web Service是一個[平台](https://ke..com/item/平台/1064049)獨立的，低耦合的，自包含的、基於可[編程](https://ke..com/item/編程)的web的應用程序，可使用開放的[XML](https://ke..com/item/XML)（[標准通用標記語言](https://ke..com/item/標准通用標記語言/6805073)下的一個子集）[標准](https://ke..com/item/標准/219665)來[描述](https://ke..com/item/描述/8928757)、發布、發現、協調和配置這些應用程序，用於開發分布式的交互操作的[應用程序](https://ke..com/item/應用程序/5985445)。 [1]
Web Service技術， 能使得運行在不同機器上的不同應用無須藉助附加的、專門的第三方軟體或硬體， 就可相互交換數據或集成。依據Web Service規范實施的應用之間， 無論它們所使用的語言、 平台或內部協議是什麼， 都可以相互交換數據。Web Service是自描述、 自包含的可用網路模塊， 可以執行具體的業務功能。Web Service也很容易部署， 因為它們基於一些常規的產業標准以及已有的一些技術，諸如[標准通用標記語言](https://ke..com/item/標准通用標記語言/6805073)下的子集[XML](https://ke..com/item/XML)、HTTP。Web Service減少了應用介面的花費。Web Service為整個企業甚至多個組織之間的業務流程的集成提供了一個通用機制。
**SOAP**
SOAP即[簡單對象訪問協議](https://ke..com/item/簡單對象訪問協議)(Simple Object Access Protocol)，它是用於交換[XML](https://ke..com/item/XML)（[標准通用標記語言](https://ke..com/item/標准通用標記語言)下的一個子集）編碼信息的輕量級協議。它有三個主要方面：XML-envelope為描述信息內容和如何處理內容定義了框架，將程序對象編碼成為XML對象的規則，執行[遠程過程調用](https://ke..com/item/遠程過程調用)(RPC)的約定。SOAP可以運行在任何其他[傳輸協議](https://ke..com/item/傳輸協議)上。例如，你可以使用 SMTP，即網際網路[電子郵件協議](https://ke..com/item/電子郵件協議)來傳遞SOAP消息，這可是很有誘惑力的。在[傳輸層](https://ke..com/item/傳輸層)之間的頭是不同的，但XML有效負載保持相同。
Web Service 希望實現不同的系統之間能夠用「[軟體](https://ke..com/item/軟體)-軟體對話」的方式相互調用，打破了軟體應用、網站和各種設備之間的格格不入的狀態，實現「基於Web無縫集成」的目標。
使用Python實現服務端
service.py 服務端啟動文件
app.py webservice介面
使用Python實現客戶端
client.py
上面調用的客戶端介面，測試結果如下：
❻ python3 使用socket怎麼連接遠程伺服器
方法如下：
1、按WIN+Q組合鍵打開搜索框，輸入"遠程桌面連接"，點擊下方提示的遠程桌面連接
2、在打開的連接窗口，輸入遠程機器的計算機名或IP地址，和埠
3、系統可能會有一些提示，點擊確認。
4、登入遠程主機後，輸入遠程主機的用戶名和密碼即可
❼ rabbitmq rpc python怎麼用
首先，客戶機調用進程發送一個有進程參數的調用消息到服務端的消息隊列里，然後等待應答信息。
在伺服器端，進程保持睡眠狀態直到調用信息到達為止。
當一個調用信息到達，伺服器獲得進程參數，計算結果，發送答復信息，然後等待下一個調用信息，最後，客戶端調用進程接收答復信息，獲得進程結果，然後調用執行繼續進行。
❽ Python RPyC如何實現客戶端與服務端通信
python實現socket客戶端和服務端示例：
1、伺服器端：
#socket通信客戶端
defclient():
mysocket=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
mysocket.connect(('127.0.0.1',8000))
mysocket.send('hello')
while1:
data=mysocket.recv(1024)
ifdata:
printdata
else:
break
mysocket.close()
#伺服器端
2、客戶端：
defserver():
ser=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
ser.bind(('127.0.0.1',8000))
ser.listen(5)
while1:
client,addr=ser.accept()
print'accept%sconnect'%(addr,)
data=client.recv(1024)
printdata
client.send('get')
client.close()
❾ python使用XML-RPC進行文件共享中時建立了server.py和client文件,但是要怎麼運行
直接雙擊運行就行。
或者輸入命令：
path_to_python/python.exe server.py
另一個控制台：path_to_python/python.exe client.py
前提是你裝了python
xml-rpc是通過socket通信，和放在什麼位置沒關系。
❿ 用python開發一個簡單的xml-rpc伺服器，提供用戶和密碼服務怎麼做
使用python的一些web框架，xml庫。
框架如果要簡單的話flask，如果高並發，使用tornado。
其他的根據自己的業務來。