SOA面向服務基礎

面向服務

面向服務的基礎

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

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

SOA的目的是什麼？

• 解耦，重用，簡潔
• 服務接口設計管理
• 標準化的服務接口
• 支持各類消息模式
• 精肯定義的服務契約

如何判斷一個軟件是不是創建在真正意義上的SOA架構風格上的？（是架構風格而不是架構）

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

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

3.業務組件之間的交互是否經過服務進行，即時當前不經過服務，是否可以很容易轉化爲服務進行交互。

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

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

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

什麼是微服務？

相關資料

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

微服務架構設計

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

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

SOA和微服務架構的區別？

微服務是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三種方法。

REST

RPC

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

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

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

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

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

什麼是RPC？

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

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

什麼是rpc框架

先回答第一個問題：什麼是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中流行的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. <?php
2. include ("phprpc/phprpc_server.php");
3. function HelloWorld() {
4. return 'Hello World!';
5. }
6. $server = new PHPRPC_Server();
7. $server->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. <?php
2. include ("phprpc/phprpc_client.php");
3. $client = new PHPRPC_Client('http://127.0.0.1/server.php');
4. echo $client->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 <curl-dir>/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表示服務器端

<?php
     class API {
         public function api($parameter, $option = "foo") {
             return $parameter;
         }
         protected function client_can_not_see() {

         }
     }
         $service = new Yar_Server(new API());
         $service->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

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薄弱的地方

REST，RPC和SOAP的區別？

REST和RPC的性能

接口調用一般包含兩個部分，序列化和通訊協議。常見的序列化協議包括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是多了一層封裝的REST

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形成困擾

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定義了這些錯誤，供開發者識別。但實際上，業務確定會本身定義錯誤標示。那麼，你不以爲那些編號反而會有干擾。不知道的還覺得是網絡鏈接有問題，沒想到只是請求錯誤。