摘要：面向服務面向服務的基礎面向服務的三層應用層，服務層，數據層應用層用于給用戶展示，，，，安卓。在服務器端，進程保持睡眠狀態直到調用信息到達為止。編譯完成，提示我們已經在下了。

面向服務的三層：應用層，服務層，數據層

* 應用層：用于給用戶展示，PC，H5，IOS，安卓。
* 服務層：業務邏輯，提供接口（商品，訂單，支付，用戶，物流）。
* 數據層：提供數據支持（mysql, MongoDB, redis, 緩存，文件）。

SOA的目的是什么？

解耦，重用，簡潔

服務接口設計管理

標準化的服務接口

支持各種消息模式

精確定義的服務契約

如何判斷一個軟件是否是建立在真正意義上的SOA架構風格上的？（是架構風格而不是架構） - 知乎
1.是否做了業務組件化，業務組件是否和技術組件分離？

2.系統內流程交互是否演化為業務組件之間的服務交互，減少系統內業務組件之間的強耦合程度。

3.業務組件之間的交互是否通過服務進行，即時當前不通過服務，是否能夠很容易轉化為服務進行交互。

4.是否滿足最基本的組件化開發思路，組件之間相對松散獨立，可以獨立部署，可以獨立進行版本管理等。

5.如果軟件存在多個子系統，子系統之間是否通過總線進行集成?

6.是否有專門的代理服務層或接入服務，適配器等，方便和外圍系統的集成?
主要考慮幾下幾點：
1、是否將系統劃分為多個業務子系統或模塊；
2、子系統或模塊之間是否是松耦合關系；
3、有沒有一個中間件或平臺，將各子系統集成起來。
主要還是業務是否組件化，原來也許關注的是一個一個系統，而現在眼中這些系統知識平臺的一些組件，負責著某一領域的管理職責，而更高的業務需求是通過組件的協作完成。業務組件可以自由組合，靈活構建上層功能，但是自身相對穩定，有點面向對象設計的感覺，只不過面對的層次更高。

微服務實戰：從架構到發布（一） - 力譜宿云 LeapCloud - SegmentFault

微服務架構設計

大部分公司并不需要微服務 - SDK.CN - 中國領先的開發者服務平臺

REST?RPC?是時候改變你對微服務的認知了！

微服務是SOA的更深一步。 隨著互聯網的發展，復雜的平臺、業務的出現，導致SOA架構向更細粒度、更通過化程度發展，就成了所謂的微服務了。
[](http://www.cnblogs.com/fengzh...
[](http://www.infoq.com/cn/artic...

微服務強調一個去中心化，上述的公司的組織架構會被打散，沒有老板，沒有管理層，每一個人都是一個服務，做著自己的事情，
[](https://www.zhihu.com/questio...

微服務是SOA的升級版，做到更細的粒度，處理了更多的問題。
例如現在的微服務都會側重解決：
服務發現、負載均衡、服務高可用、分布式請求日志跟蹤

服務提供了一個簡單的接口，抽象了底層的復雜性，然后用戶可以訪問獨立的服務，而不需要去了解服務底層平臺實現。所以，SOA架構的實現不依賴于技術，因此，能夠被各種不同的技術實現

SOAP, RPC
REST
DCOM
CORBA
OPC-UA
Web services
DDS
Java RMI
WCF (Microsoft"s implementation of web services now forms a part of WCF)
Apache Thrift
SORCER
都是SOA的具體實現方法而已。

最常用的就是REST，RPC，SOAP三種方法。

一個虐你千百遍的問題：“RPC好，還是RESTful好？” - 王啟軍 - CSDN博客
http://blog.csdn.net/douliw/a...

RPC是一種進程遠程調用的方式，更強調的是異構平臺之間進程通信的機制。它可以使用多種協議（包括HTTP以及其他base在TCP的自定義協議）和序列化方式（Json/xml/二進制），組件之間的耦合度比較高。服務管理的機制相對較弱。

RPC就是通過網絡，調用遠程機器上的方法。

有基于TCP 跟 HTTP的兩種實現，其原理都是

從tcp或者http頭部把需要調用的方法，參數(包括類型)讀出來，服務端利用php/java反射，調用本地的方法。

RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程序在內的應用程序更加容易。

RPC采用C/S模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，然后等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息到達為止。當一個調用信息到達，服務器獲得進程參數，計算結果，發送答復信息，然后等待下一個調用信息，最后，客戶端調用進程接收答復信息，獲得進程結果，然后調用執行繼續進行。

先回答第一個問題：什么是RPC框架？ 如果用一句話概括RPC就是：遠程調用框架（Remote Procedure Call）
那什么是遠程調用？
通常我們調用一個PHP中的方法，比如這樣一個函數方法: localAdd(10, 20)，localAdd方法的具體實現要么是用戶自己定義的，要么是php庫函數中自帶的，也就說在localAdd方法的代碼實現在本地，它是一個本地調用！
遠程調用意思就是：被調用方法的具體實現不在程序運行本地，而是在別的某個遠程地方。

比如 A (client) 調用 B (server) 提供的remoteAdd方法：

1. 首先A與B之間建立一個TCP連接；

2. 然后A把需要調用的方法名（這里是remoteAdd）以及方法參數（10， 20）序列化成字節流發送出去；

3. B接受A發送過來的字節流，然后反序列化得到目標方法名，方法參數，接著執行相應的方法調用（可能是localAdd）并把結果30返回；

4. A接受遠程調用結果,輸出30。

##遠程調用的好處

解耦：當server需要對方法內實現修改時，client完全感知不到，不用做任何變更；這種方式在跨部門，跨公司合作的時候經常用到，并且方法的提供者我們通常稱為：服務的暴露。

RPC框架就是把我剛才說的這幾點些細節給封裝起來，給用戶暴露簡單友好的API使用。

php中流行的rpc框架有哪些
既然php是世界上最好的語言，那php中流行的RPC框架有哪些呢？
先列舉下： phprpc，yar, thrift, gRPC, swoole, hprose
因為時間和精力有限，不可能一個一個的去學習和使用，我選幾個世面上用的最多的幾個用下吧。因為RPC原理是一樣的，都是Client/Server模式，只是每個框架的使用方式不一樣而已。
主要講解一下 phprpc 和 yar 是我目前聽說和接觸最多的了。
phprpc先從官網下載最新穩定版的phprpc:下載鏈接 解壓。
安裝我們會發現里面有很多文件和文件夾，結構如下：

* dhparams/
* pecl/
* bigint.php
* compat.php
* phprpc_date.php
* xxtea.php
* dhparams.php
* phprpc_server.php
* phprpc_client.php

其中有dhparams和pecl是文件夾，pecl中的是php的xxtea擴展，按照官網的描述，可以安裝也可以不安裝，不安裝phprpc也是可以運行的。但是如果你需要更快的加密處理能力，可以安裝下。
我還是安裝吧。畢竟加密能力更快，是好事：
安裝步驟如下，先將pecl下的xxtea文件夾復制到php源碼的etx目錄：/lamp/php-5.4.11/ext下。然后用phpize進行擴展重新編譯。

1. [root@localhost /]# cd /lamp/php-5.4.11/ext/xxtea
2. [root@localhost xxtea]# /usr/local/php/bin/phpize
3. [root@localhost xxtea]# ./configure --enable-xxtea=shared --with-php-config=/usr/local/php/bin/php-config
4. make && make install

OK ,編譯完成，提示我們xxtea.so已經在/usr/local/php/lib/php/extensions/no-debug-zts-20100525/xxtea.so 下了。
下面，我們就需要在php.ini的最后將這個xxtea.so加上：
[root@localhost /]# vi /usr/local/php/etc/php.ini

[xxtea]
extension=xxtea.so

好。加好了后，我們需要重啟下apache或者php-fpm
重啟apache
[root@localhost /]# /usr/local/apache/bin/apachectl restart

平滑重啟php-fpm
kill -USR2 cat /usr/local/php/var/run/php-fpm.pid

重啟完畢后，打開phpinfo()頁面，搜索一下，應該就能夠看到xxtea了。
開始使用先來個簡單的例子，phprpc也是分為服務器端和客戶端的。所以文件夾中對應的就是phprpc_server.php 和 phprpc_client.php
我們參考官網的幾個例子，練習下：
server.php 服務端：這樣寫就完成了一個最簡單的helloword的接口。

1. add("HelloWorld");
8. $server->start();

運行下server.php，我擦，居然報錯了！！！
PHP Strict Standards: Non-static method PHPRPC_Server::initSession()....
Cannot redeclare gzdecode().....

google了下，說是先把 phprpc_server.php的413行的initSession()改成static function
static function initSession() {

****

}

PS. 我了個擦，這么大的錯誤，phprpc是怎么發布的！！！
在把compat.php 的第 71行的 gzdecode()函數，php5.4已經實現了這個函數了。這樣函數就被重寫了，就報錯了，所以加個判斷：
if (!function_exists("gzdecode")) {

//將gzdecode函數包括進來

}

好。改完，保存。再運行下server.php 。ok 了。不報錯了。輸出：
phprpc_functions="YToxOntpOjA7czo5OiJoZWxsb3dvcmQiO30=";

我們接下來寫客戶端 client.php, 看是如何寫的？

1. HelloWorld();
5. ?>

我們在執行以下client.php，如愿以償的輸出了：
Hello Word!

這樣一個簡單的Server/Clent交付就搞定了。雖然中間出了點差錯，但是總體來說還是蠻簡單易懂的!
其他的更高級的用法可以參考官網的。
yaryar 是國內著名的php大神鳥哥惠新宸的大作，在微博產品中已經開始使用。它也是一款rpc框架。它由于使用純C編寫的用于php的擴展，所以，效率應該是蠻高的，而且支持異步并行，這點還是贊的。
下載安裝官網下載：http://pecl.php.net/package/yar 最新的版本 yar-1.2.4.tgz
然后解壓復制到php源碼的etx目錄：/lamp/php-5.4.11/ext下。然后用phpize進行擴展重新編譯。

1. [root@localhost yar-1.2.4]# /usr/local/php/bin/phpize
2. [root@localhost yar-1.2.4]# ./configure --with-php-config=/usr/local/php/bin/php-config

但是出現了點問題：提示，curl 有問題：
configure: error: Please reinstall the libcurl distribution - easy.h should be in /include/curl/

估計是我本機curl 有問題，那用yum 安裝一下吧：
yum -y install curl-devel

安裝完成curl 后繼續編譯安裝，就沒啥問題了：

1. [root@localhost yar-1.2.4]# /usr/local/php/bin/phpize
2. [root@localhost yar-1.2.4]# ./configure --with-php-config=/usr/local/php/bin/php-config
3. [root@localhost yar-1.2.4]# make && make install

成功之后，提示我們 yar.so 擴展在已經在/usr/local/php/lib/php/extensions/no-debug-zts-20100525/ 下了。
我們vi編輯一下 php.ini ,最后面加上yar.so擴展，然后重啟一下 apache 或者php-pfm就可以了。
[root@localhost /]# vi /usr/local/php/etc/php.ini

[yar]
extension=yar.so

好。加好了后，我們需要重啟下apache或者php-fpm
重啟apache
[root@localhost /]# /usr/local/apache/bin/apachectl restart

平滑重啟php-fpm
kill -USR2 cat /usr/local/php/var/run/php-fpm.pid

重啟完畢后，打開phpinfo()頁面，搜索一下，應該就能夠看到yar了。
開始使用和其他的rpc框架一樣，yar也是server/client模式，所以，我們也一樣，開始寫一個簡單的例子來說下如何調用。
yar_server.php表示服務器端

     handle();

好，我們在瀏覽器里運行一下，就會出現如下圖所示的輸出。很高端啊！！！鳥哥說這樣做的用途是可以一目了然的知道我這個rpc提供了多少接口，把api文檔都可以省略了。

好，我們開始寫yar_client.php 這個是客戶端：

     $client = new Yar_Client("http://127.0.0.1/yar_server.php");
     echo $client->api("helo word");

好，像其他的 swoole，hprose等基本都是這個原理，只是看誰的功能更加，用起來更順手罷了。

SOAP可支持任何傳輸協議，從HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，簡單郵件傳送協議），甚至JMS（Java Messaging Service，Java消息傳遞服務）。不過，由于XML較為冗長且解析費時，因此采用XML也成為一個弊端。
SOAP的使用場景：異步處理與調用，有狀態的操作，數據格式必須一致。
SOAP是基于HTTP和XML的實現，因此會更容易做業務隔離，在系統可維護性和可擴展性上優于RPC。
簡單來說： SOAP = HTTP+XML+RPC

對于PRC的概念不太清楚，貌似在.NET中接觸到的也不太多，就說說SOAP和REST吧。

SOAP和REST嚴格來說不是兩個對等的概念，姑且理解成兩種服務設計思想和及其具體的實現架構吧。

正如前文有大牛回答的，二者各有自己的使用場景。如果創建的分布式服務要求較好的安全性，對于傳輸等底層實現要求較強的可定制性，可以考慮SOAP；如果要求設計實現簡單，一般來說安全性要求不高可以考慮REST。這只是一般情況，但偏于面向資源的服務使用REST有天然的優勢。

就我們的項目來說，SOAP在.NET中現在經常使用WCF框架，而RESTful則多使用Web API。WCF中雖然也有RESTful實現，但并不好用。

SOAP(簡單對象訪問協議)是什么？SOAP是一種數據交換協議規范，是一種輕量的、簡單的、基于XML的協議的規范。它有什么優點？簡單總結為： 易用，靈活，跨語言，跨平臺。
易用：是因為它的消息是基于xml并封裝成了符合http協議，因此,它符合任何路由器、 防火墻或代理服務器的要求。
靈活：表現在極具拓展性，SOAP 無需中斷已有的應用程序, SOAP 客戶端、 服務器和協議自身都能發展。而且SOAP 能極好地支持中間介質和層次化的體系結構。
跨語言：soap可以使用任何語言來完成，只要發送正確的soap請求即可。
跨平臺：基于soap的服務可以在任何平臺無需修改即可正常使用。

REST可以看著是http協議的一種直接應用，默認基于json作為傳輸格式，使用簡單，學習成本低效率高，但是安全性較低，而SOAP可以看著是一個重量級的協議，基于xml，SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規范組成了WS-Security來實現安全控制的，當前已經得到了各個廠商的支持，.net ，php ，java 都已經對其有了很好的支持 。這是REST薄弱的地方

接口調用通常包含兩個部分，序列化和通信協議。常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等；通信比較流行的是http、soap、websockect，RPC通常基于TCP實現，常用框架例如netty。

RESTful通常采用http+JSON實現。

JSON-RPC是指通信協議采用二進制方式，而不是http，序列化采用JSON的形式。

http vs 高性能二進制協議

http相對更規范，更標準，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平臺，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，相應的，如果采用http，無疑在你實現SDK之前，支持了所有語言，所以，現在開源中間件，基本最先支持的幾個協議都包含RESTful。但是，由于受限于HTTP協議，需要帶HTTP請求頭，導致傳輸起來效率或者說安全性不如RPC。
RPC協議性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能達到http的二倍。響應時間也更為出色。千萬不要小看這點性能損耗，公認的，微服務做的比較好的，例如，netflix、阿里，曾經都傳出過為了提升性能而合并服務。如果是交付型的項目，性能更為重要，因為你賣給客戶往往靠的就是性能上微弱的優勢。

RPC的應用場景：大型分布式開發。使用socket來通信，其目的就是更快更安全，但是相對的，略有開發難度。
而RPC是基于TCP或自定義協議實現的不同，性能會略高于到遠高于REST不等，但是異構系統間的耦合度會更高，間接增加系統的故障率和排錯難度。
對于RPC本身可以走HTTP ,TCP等不同的協議，比如淘寶的Dubbo框架，RPC是可以選擇走TCP協議還是走HTTP協議的。

簡單來說成熟的rpc庫相對http容器，跟多的是封裝了“服務發現”，”錯誤重試“，“注冊中心”，有豐富的監控管理，發布，下線接口，動態擴展等，一類面向服務的高級特性。可以這么理解，rpc框架是面向服務的更高級的封裝。如果把一個http server容器上封裝一層服務發現和函數代理調用，那它就已經可以做一個rpc框架了。

所以為什么要用rpc調用？

因為良好的rpc調用是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http調用則缺少了這些特性。

基于以上兩點，性能和封裝的考量下，REST只適用于業務比較簡單的場景。所以，（但是，場景是否簡單也是相對的，RPC適用于真正大型的分布式開發。）

REST目前基于HTTP/HTTPS；使用HTTP來通信，是個不錯的方案。因為目前大部分語言的標準庫都是支持HTTP的，而且HTTP這種無狀態的請求，更容易接受。同時套用了HTTP定義的動詞和狀態碼，更容易接受。實現起來較RPC框架使用的socket通信而言，也更簡單一些。

REST的使用場景：有限的帶寬和資源，無狀態的CURD操作，緩存考慮（利用無狀態操作的特性，使得信息可以被緩存，REST是很好的選擇）

REST的優點是套用了HTTP那一套狀態碼和動詞，很方便。但是相應的，套用了HTTP的，也造成了對于開發者的困擾。

所有的接口，服務器端原本就存在有相應的函數，它們本來就有自身的命名空間，接受的參數、返回值、異常等等。
采用輕便的方式暴露出來即可。
無需把一堆函數重新歸納到“資源”，再削減腦袋把所有的操作都映射為“增刪改查”。
對應到web上，rpc的成熟方案非常多，有古老的soap，也有輕量的json rpc。
RESTful使用了HTTP的4xx，5xx的那些錯誤定義。相當于HTTP定義了這些錯誤，供開發者識別。
但實際上，業務肯定會自己定義錯誤標示。那么，你不覺得那些編號反而會有干擾。不知道的還以為是網絡連接有問題，沒想到只是請求錯誤。