阿里P8架构师谈：Restful、SOAP、RPC、SOA、微服务之间的区别（转载）

转载来源：https://youzhixueyuan.com/the-difference-between-restful-soap-rpc-soa-and-micro-service.html

 

内容大纲：

1.介绍Restful、SOAP、RPC、SOA以及微服务

2.重点谈谈SOA与微服务的区别

3.以及为何要使用微服务架构

什么是Restful

Restful是一种架构设计风格，提供了设计原则和约束条件，而不是架构，而知足这些约束条件和原则的应用程序或设计就是 Restful架构或服务。

主要的设计原则：

•  资源与URI
•  统一资源接口(HTTP方法如GET，PUT和POST)
•  资源的表述
•  资源的连接
•  状态的转移

总之，RESTful的核心就是后端将资源发布为URI，前端经过URI访问资源，并经过HTTP动词表示要对资源进行的操做。

什么是SOAP

简单对象访问协议是一种数据交换协议规范，是一种轻量的、简单的、基于XML的协议的规范。SOAP协议和HTTP协议同样，都是底层的通讯协议，只是请求包的格式不一样而已，SOAP包是XML格式的。

SOAP的消息是基于xml并封装成了符合http协议，所以，它符合任何路由器、 防火墙或代理服务器的要求。

SOAP可使用任何语言来完成，只要发送正确的soap请求便可，基于soap的服务能够在任何平台无需修改便可正常使用。

RPC

RPC就是从一台机器（客户端）上经过参数传递的方式调用另外一台机器（服务器）上的一个函数或方法（能够统称为服务）并获得返回的结果。

RPC 会隐藏底层的通信细节（不须要直接处理Socket通信或Http通信）

RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（相似于Http的工做方式）

RPC 在使用形式上像调用本地函数（或方法）同样去调用远程的函数（或方法）。

4种典型RPC远程调用框架

（1）RMI实现，利用java.rmi包实现，基于Java远程方法协议(Java Remote Method Protocol)和java的原生序列化。

（2）Hessian，是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。 基于HTTP协议，采用二进制编解码。

（3）thrift是一种可伸缩的跨语言服务的软件框架。thrift容许你定义一个描述文件，描述数据类型和服务接口。依据该文件，编译器方便地生成RPC客户端和服务器通讯代码。

 

（4）dubbo，阿里的RPC框架。

（5）还有SpringCloud框架，微服务全家桶。为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。

微服务在本质上，就是rpc。rpc有基于tcp的，http的，mq的等等。spring cloud是基于spring boot的，spring boot 实现的是http协议的rpc，算是rpc的一个子集。

 

什么是SOA

SOA（Service-Oriented Architecture），中文全称：面向服务的架构。

通俗点来说，SOA提倡将不一样应用程序的业务功能封装成“服务”并宿主起来，一般以接口和契约的形式暴露并提供给外界应用访问（经过交换消息），达到不一样系统可重用的目的。

SOA是一个组件模型，它能将不一样的服务经过定义良好的接口和契约联系起来。服务是SOA的基石。

微服务和SOA的区别

微服务是SOA架构演进的结果。二者说到底都是对外提供接口的一种架构设计方式,随着互联网的发展，复杂的平台、业务的出现，致使SOA架构向更细粒度、更经过化程度发展，就成了所谓的微服务了。

总之，微服务是SOA发展出来的产物，它是一种比较现代化的细粒度的SOA实现方式。

SOA与微服务的区别在于以下几个方面：

1.  微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并没有影响；
2.  微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各类终端均可以调用，无关语言、平台限制；
3.  微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

为何要使用微服务？

技术为业务而生，架构也为业务而出现，固然SOA和微服务也是由于业务的发展而出现。出现SOA和微服务框架与业务的发展、平台的壮大密不可分，下面借用dubbo的网站架构发展图和说明：

•  单一应用架构
•  当网站流量很小时，只需一个应用，将全部功能都部署在一块儿，以减小部署节点和成本。
•  此时，用于简化增删改查工做量的 数据访问框架(ORM) 是关键。
•  垂直应用架构
•  当访问量逐渐增大，单一应用增长机器带来的加速度愈来愈小，将应用拆成互不相干的几个应用，以提高效率。
•  此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
•  分布式服务架构
•  当垂直应用愈来愈多，应用之间交互不可避免，将核心业务抽取出来，做为独立的服务，逐渐造成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
•  此时，用于提升业务复用及整合的 分布式服务框架(RPC) 是关键。
•  流动计算架构
•  当服务愈来愈多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增长一个调度中心基于访问压力实时管理集群容量，提升集群利用率。
•  此时，用于提升机器利用率的 资源调度和治理中心(SOA) 是关键。

平台随着业务的发展从 All in One 环境就能够知足业务需求（以Java来讲，可能只是一两个war包就解决了）。

发展到须要拆分多个应用，而且采用MVC的方式分离先后端，加快开发效率；在发展到服务愈来愈多，不得不将一些核心或共用的服务拆分出来，其实发展到此阶段，若是服务拆分的足够精细，而且独立运行，我以为就能够将之理解为一个微服务了。