云服务和SOA架构以及微服务架构的区别及联系

截止目前，如果之前有看我文章的，关于SSM框架的原理，应该都差不多理解了，毕竟都是看我写过源码的人了，接下来会进入Spring Boot和Spring Cloud的原理，源码解析。在此之前，我们需要了解如下几个概念。云服务、SOA架构、微服务架构。
1、 基于IOC原理，手写SpringIOC源码
2、 基于MVC原理，手写SpringMVC源码
3、 基于连接池和AOP原理，手写MyBatis源码

1.云服务

首先看看百科的介绍：云服务是基于互联网的相关服务的增加、使用和交互模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。恩，读起来有点咬口，还是不是很理解。接下来慢慢来解读云服务吧。
云服务只是一个统称，我们可以将其分成三层：一层IAAS、二层PAAS、三层SAAS。

1.1.IAAS基础设施服务

Infrastructure-as-a-Service(基础设施即服务)，把IT基础设施作为一种服务通过网络对外提供。
在这种服务模型中，用户不用自己构建一个数据中心，而是通过租用的方式来使用基础设施服务，包括服务器、存储和网络等。例如我们可直接在网络上购买阿里云服务器来使用，而不用自己构建机房、网络、储存等设设备。
换句话说就是，我们把网络、服务器、存储等这些IT基础设施作为一种资源，通过网络给用户提供服务。

1.2.PAAS平台服务

Platform-as-a-Service(平台即服务)，将软件研发的平台作为一种服务。
提供商向开发者端提供平台工具，使他们能够开发、运行和管理业务应用程序，而无需构建和维护基础架构这样的软件开发过程需要的设施。

1.3.SAAS软件服务

Software-as-a-Service，软件即为服务。通过网络提供软件服务。
传统模式下，厂商通过License将软件产品部署到企业内部多个客户终端实现交付。除了需要维护软件本身以外，还需要维护服务器、机房等资源。
SAAS模式下，平台供应商将应用软件统一部署在自己的服务器上，通过互联网获得平台供应商提供的服务。用户无需建设机房、购买、维护、升级任何软件和硬件。只要可以上网即可访问SAAS应用。

2.单体架构

将所有功能都部署在一个web容器中运行的系统。对于小型系统来说，倒不是什么特别大的问题，但是系统庞大时，缺点将被无限放大。
1、维护成本巨大；
2、一处修改，全量部署；
3、一处奔溃，容易整个系统崩溃。
针对单体架构所带来的问题，于是SOA架构出来了。

3.SOA架构

Service Oriented Architecture：面向服务的软件架构，是一种软件设计模式，主要应用于不同应用组件之间通过某种协议来互操作。 SOA将原来的单体架构按照功能细分为不同的子系统，然后再由各个子系统依赖服务中间件来调用所需服务。简单一点说，就是SOA架构就是将单体架构进行拆分。
主流SOA实现方式：REST、SOAP、RPC。因为SOA不依赖于任何技术，因此SOAP、RPC、REST是对SOA的不同实现。

3.1.SOAP

Simple Object Access Protocol：简单对象访问协议是交换数据的一种协议规范。可在任何传输协议（诸如 TCP、HTTP、SMTP，甚至是 MSMQ）上使用。SOAP广泛使用的是基于HTTP和xml协议的实现（SOAP=RPC+HTTP+XML），即Web Service。

3.2.REST

Representional State Transfer：表征状态转移。REST 不同于SOAP，他不是协议，而是一种一种基于HTTP协议的架构。采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源。
REST基于HTTP协议。
SOAP基于任何传输协议:诸如 TCP、HTTP、SMTP，甚至是 MSMQ
REST对比与SOAP来说，高效、简洁、性能好、易开发。更为优势的是，在web2.0（2003年）以后，几乎前端和后端都是用REST方式交互的。就目前为止，我肯定没见过谁在前端使用SOAP和后台交互（我相信未来也不会见到，SOAP的优缺点注定了他的不可能）。
SOAP对比REST来说，由于非常成熟，其安全性能比REST要高。以前的旧项目大多会提供REST和SOAP（webservice）两种方式，不过就目前来说SOAP（webservice）这种方式，基本上新项目中，很少被使用了。
原因1：REST方式极致的表现了HTTP的简单高效。国内的项目，从访问量，用户量，并发量来说是任何一个国家都不可比拟的（9亿网民不是盖的），REST的轻量、快速、简单这点比SOAP（webservice）做的要好，因为这是REST的优点；
原因2：统一的接口（同一个功能需要在PC端，服务端，移动端，APP等不同场景下进行实现，REST只需要提供一个接口，这是SOAP做不到的）。编写一个REST接口，不管基于什么场景都可以调用，但是SOAP（webservice）目前也就应用于服务端调用服务端。
因此如果访问量小，数据量小，性能要求低，但安全要求特别高的，并且不需要前端的情况下，纯后端接口，会去考虑使用SOAP（webservice）。至于前端和服务端，就目前而言，但凡脑子没被驴踢，都会选择REST。不过从笔者前后经历的各家公司，各个项目组，以及周围使用人员来说，使用SOAP（webservice）的人员，确实少的可怜，除非一些老项目还在维护，尤其微服务起来以后，SOAP（webservice）方式，几乎没有人会在新项目中使用。

3.3.REST ful

如果REST满足一定条件（C/S、无状态、分层系统、统一接口），则称为REST ful。你可以理解成REST ful就是更加规范的REST。

3.4.RPC

RPC（Remote Procedure Call）远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
简单的理解是一个节点请求另一个节点提供的服务。（本地的方法去调用其他服务器上的方法）。

3.5.RPC和REST ful区别

RPC是以动词为中心的；
REST ful是以名词为中心的（动词指的是一些方法, 名词是指资源）
比如RPC实现增删查改用户，使用动词的方式来区分增删查改。

void createUser();
void deleteUser();
void queryUser();
void updateUser();

而在restful中，只使用名称（资源）不是用动词的方法来区分增删查改，而是以请求方式来区分资源。因此对于restful接口中，对统一资源的操作（增删查改），地址永远是同一个。
不管增删查改那种方式请求资源，资源都是user,
创建用户，则用post请求，
更新用户，则用put请求，
删除用户，则用delete请求，
查询用户，则用get请求。
比如servlet实现REST ful

springMVC实现REST ful

4.微服务架构

4.1.微服务介绍

SOA架构体系中，是将单体架构拆分成多个子系统。
而在微服务架构中，是将系统业务按照功能拆分为更加细粒度的服务。所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API（一般使用REST API），可以独立承担对外服务的职责。因此微服务架构的拆分比SOA架构的拆分还要细粒度。

4.2.微服务架构实现

回一下我们使用微服务的时候，是不是有一种感觉，在当前的项目中调用了其他项目的方法？
显而易见微服务采用的是RPC（远程过程调用）方式实现的。
值得注意的是：
Dubbo就是一种RPC框架。他的通讯协议是RPC协议；
RPC是基于TCP和HTTP协议的，是把http作为一种传输协议，本身还会封装一层RPC框架的应用层协议，不同语言之间调用需要依赖RPC协议。
Spring Cloud也是一种RPC框架。但是他的通讯协议不是RPC协议，而是http协议，遵循REST ful风格。
Rest基于http作为应用协议，不同语言之间调用比较方便。

4.3.微服务架构对比SOA架构

至此完毕，后续就会开始进入到Spring Boot了。