什么是 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 的形式拆散前后端，放慢开发效率；在倒退到服务越来越多，不得不将一些外围或共用的服务拆分进去，其实倒退到此阶段，如果服务拆分的足够精密，并且独立运行，我感觉就能够将之了解为一个微服务了。