SOA面向服务基础

摘要：面向服务面向服务的基础面向服务的三层应用层，服务层，数据层应用层用于给用户展示，，，，安卓。在服务器端，进程保持睡眠状态直到调用信息到达为止。编译完成，提示我们已经在下了。

面向服务的三层：应用层，服务层，数据层

* 应用层：用于给用户展示，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定义了这些错误，供开发者识别。
但实际上，业务肯定会自己定义错误标示。那么，你不觉得那些编号反而会有干扰。不知道的还以为是网络连接有问题，没想到只是请求错误。