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定义了这些错误，供开发者识别。但实际上，业务确定会本身定义错误标示。那么，你不以为那些编号反而会有干扰。不知道的还觉得是网络链接有问题，没想到只是请求错误。