什么是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 的全称是 Remote Procedure Call 是一种过程间通信形式。
它容许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不必程序员显式编码这个近程调用的细节。即无论是调用本地接口/服务的还是近程的接口/服务，实质上编写的调用代码基本相同。
比方两台服务器A，B，一个利用部署在A服务器上，想要调用B服务器上利用提供的函数或者办法，因为不在一个内存空间，不能间接调用，这时候须要通过就能够利用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 实现服务的输入和输出性能，能够和 Spring框架无缝集成
（5）还有SpringCloud框架，微服务全家桶。为开发人员提供了疾速构建分布式系统的一些工具，包含配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。
微服务在实质上，就是rpc。rpc有基于tcp的，http的，mq的等等。spring cloud是基于spring boot的，spring boot 实现的是http协定的rpc，算是rpc的一个子集。
什么是SOA
SOA（Service-Oriented Architecture），中文全称：面向服务的架构。
艰深点来讲，SOA提倡将不同应用程序的业务性能封装成“服务”并宿主起来，通常以接口和契约的模式裸露并提供给外界利用拜访（通过替换音讯），达到不同零碎可重用的目标。
SOA是一个组件模型，它能将不同的服务通过定义良好的接口和契约分割起来。服务是SOA的基石。

业务零碎合成为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力
通过服务的组合和编排来实现下层的业务流程
作用：简化保护,升高整体危险,伸缩灵便

微服务架构
什么是微服务架构
架构设计概念,各服务间隔离（分布式也是隔离）,自治（分布式依赖整体组合）其它个性(繁多职责,边界,异步通信,独立部署)是分布式概念
作用：各服务可独立利用，组合服务也可零碎利用(巨石利用[monolith]的简化实现策略-平台思维)

微服务和SOA的区别
微服务是SOA架构演进的后果。两者说到底都是对外提供接口的一种架构设计形式,随着互联网的倒退，简单的平台、业务的呈现，导致SOA架构向更细粒度、更通过化水平倒退，就成了所谓的微服务了。
总之，微服务是SOA倒退进去的产物，它是一种比拟现代化的细粒度的SOA实现形式。
SOA与微服务的区别在于如下几个方面：
微服务相比于SOA更加精密，微服务更多的以独立的过程的形式存在，相互之间并无影响；
微服务提供的接口方式更加通用化，例如HTTP RESTful形式，各种终端都能够调用，无关语言、平台限度；
微服务更偏向于分布式去中心化的部署形式，在互联网业务场景下更适宜。
SOA架构次要针对企业级、采纳ESB服务（ESB企业服务总线），十分重，须要序列化和反序列化，采纳XML格局传输。
微服务架构次要互联网公司，轻量级、玲珑，独立运行，基于Http+Rest+JSON格局传输。
为什么要应用微服务？
技术为业务而生，架构也为业务而呈现，当然SOA和微服务也是因为业务的倒退而呈现。https://www.cnblogs.com/wwct/...
平台随着业务的倒退从 All in One 环境就能够满足业务需要（以Java来说，可能只是一两个war包就解决了）。倒退到须要拆分多个利用，并且采纳MVC的形式拆散前后端，放慢开发效率；在倒退到服务越来越多，不得不将一些外围或共用的服务拆分进去，其实倒退到此阶段，如果服务拆分的足够精密，并且独立运行，我感觉就能够将之了解为一个微服务了。