1.云服務(wù)

首先看看百科的介紹：云服務(wù)是基于互聯(lián)網(wǎng)的相關(guān)服務(wù)的增加,、使用和交互模式，通常涉及通過互聯(lián)網(wǎng)來提供動(dòng)態(tài)易擴(kuò)展且經(jīng)常是虛擬化的資源,。恩,，讀起來有點(diǎn)咬口，還是不是很理解,。接下來慢慢來解讀云服務(wù)吧,。
云服務(wù)只是一個(gè)統(tǒng)稱，我們可以將其分成三層：一層IAAS,、二層PAAS,、三層SAAS。

1.1.IAAS基礎(chǔ)設(shè)施服務(wù)

Infrastructure-as-a-Service(基礎(chǔ)設(shè)施即服務(wù)),，把IT基礎(chǔ)設(shè)施作為一種服務(wù)通過網(wǎng)絡(luò)對(duì)外提供,。
在這種服務(wù)模型中，用戶不用自己構(gòu)建一個(gè)數(shù)據(jù)中心,，而是通過租用的方式來使用基礎(chǔ)設(shè)施服務(wù),，包括服務(wù)器、存儲(chǔ)和網(wǎng)絡(luò)等,。例如我們可直接在網(wǎng)絡(luò)上購買阿里云服務(wù)器來使用,，而不用自己構(gòu)建機(jī)房、網(wǎng)絡(luò),、儲(chǔ)存等設(shè)設(shè)備,。
換句話說就是，我們把網(wǎng)絡(luò),、服務(wù)器,、存儲(chǔ)等這些IT基礎(chǔ)設(shè)施作為一種資源,，通過網(wǎng)絡(luò)給用戶提供服務(wù),。

1.2.PAAS平臺(tái)服務(wù)

Platform-as-a-Service(平臺(tái)即服務(wù))，將軟件研發(fā)的平臺(tái)作為一種服務(wù),。
提供商向開發(fā)者端提供平臺(tái)工具,，使他們能夠開發(fā)、運(yùn)行和管理業(yè)務(wù)應(yīng)用程序,，而無需構(gòu)建和維護(hù)基礎(chǔ)架構(gòu)這樣的軟件開發(fā)過程需要的設(shè)施,。

1.3.SAAS軟件服務(wù)

Software-as-a-Service,，軟件即為服務(wù)。通過網(wǎng)絡(luò)提供軟件服務(wù),。
傳統(tǒng)模式下,，廠商通過License將軟件產(chǎn)品部署到企業(yè)內(nèi)部多個(gè)客戶終端實(shí)現(xiàn)交付。除了需要維護(hù)軟件本身以外,，還需要維護(hù)服務(wù)器,、機(jī)房等資源。
SAAS模式下,，平臺(tái)供應(yīng)商將應(yīng)用軟件統(tǒng)一部署在自己的服務(wù)器上,，通過互聯(lián)網(wǎng)獲得平臺(tái)供應(yīng)商提供的服務(wù)。用戶無需建設(shè)機(jī)房,、購買,、維護(hù)、升級(jí)任何軟件和硬件,。只要可以上網(wǎng)即可訪問SAAS應(yīng)用,。

2.單體架構(gòu)

將所有功能都部署在一個(gè)web容器中運(yùn)行的系統(tǒng)。對(duì)于小型系統(tǒng)來說,，倒不是什么特別大的問題,，但是系統(tǒng)龐大時(shí)，缺點(diǎn)將被無限放大,。
1,、維護(hù)成本巨大；
2,、一處修改,，全量部署；
3,、一處奔潰,，容易整個(gè)系統(tǒng)崩潰。
針對(duì)單體架構(gòu)所帶來的問題,，于是SOA架構(gòu)出來了,。

3.SOA架構(gòu)

Service Oriented Architecture：面向服務(wù)的軟件架構(gòu)，是一種軟件設(shè)計(jì)模式,，主要應(yīng)用于不同應(yīng)用組件之間通過某種協(xié)議來互操作,。 SOA將原來的單體架構(gòu)按照功能細(xì)分為不同的子系統(tǒng)，然后再由各個(gè)子系統(tǒng)依賴服務(wù)中間件來調(diào)用所需服務(wù),。簡(jiǎn)單一點(diǎn)說,，就是SOA架構(gòu)就是將單體架構(gòu)進(jìn)行拆分。
主流SOA實(shí)現(xiàn)方式：REST、SOAP,、RPC,。因?yàn)镾OA不依賴于任何技術(shù)，因此SOAP,、RPC,、REST是對(duì)SOA的不同實(shí)現(xiàn)。

3.1.SOAP

Simple Object Access Protocol：簡(jiǎn)單對(duì)象訪問協(xié)議是交換數(shù)據(jù)的一種協(xié)議規(guī)范,?？稍谌魏蝹鬏攨f(xié)議（諸如 TCP、HTTP,、SMTP,，甚至是 MSMQ）上使用。SOAP廣泛使用的是基于HTTP和xml協(xié)議的實(shí)現(xiàn)（SOAP=RPC+HTTP+XML）,，即Web Service,。

3.2.REST

Representional State Transfer：表征狀態(tài)轉(zhuǎn)移。REST 不同于SOAP,，他不是協(xié)議,，而是一種一種基于HTTP協(xié)議的架構(gòu)。采用Web 服務(wù)使用標(biāo)準(zhǔn)的 HTTP 方法 (GET/PUT/POST/DELETE) 將所有 Web 系統(tǒng)的服務(wù)抽象為資源,。
REST基于HTTP協(xié)議,。
SOAP基于任何傳輸協(xié)議:諸如 TCP、HTTP,、SMTP,，甚至是 MSMQ
REST對(duì)比與SOAP來說，高效,、簡(jiǎn)潔,、性能好、易開發(fā),。更為優(yōu)勢(shì)的是,，在web2.0（2003年）以后，幾乎前端和后端都是用REST方式交互的,。就目前為止,，我肯定沒見過誰在前端使用SOAP和后臺(tái)交互（我相信未來也不會(huì)見到，SOAP的優(yōu)缺點(diǎn)注定了他的不可能）,。
SOAP對(duì)比REST來說,，由于非常成熟，其安全性能比REST要高,。以前的舊項(xiàng)目大多會(huì)提供REST和SOAP（webservice）兩種方式,，不過就目前來說SOAP（webservice）這種方式，基本上新項(xiàng)目中,，很少被使用了,。
原因1：REST方式極致的表現(xiàn)了HTTP的簡(jiǎn)單高效。國內(nèi)的項(xiàng)目,，從訪問量,，用戶量，并發(fā)量來說是任何一個(gè)國家都不可比擬的（9億網(wǎng)民不是蓋的）,，REST的輕量,、快速、簡(jiǎn)單這點(diǎn)比SOAP（webservice）做的要好,，因?yàn)檫@是REST的優(yōu)點(diǎn),；
原因2：統(tǒng)一的接口（同一個(gè)功能需要在PC端，服務(wù)端,，移動(dòng)端,，APP等不同場(chǎng)景下進(jìn)行實(shí)現(xiàn)，REST只需要提供一個(gè)接口,，這是SOAP做不到的）,。編寫一個(gè)REST接口，不管基于什么場(chǎng)景都可以調(diào)用,，但是SOAP（webservice）目前也就應(yīng)用于服務(wù)端調(diào)用服務(wù)端,。
因此如果訪問量小，數(shù)據(jù)量小,，性能要求低,，但安全要求特別高的，并且不需要前端的情況下,，純后端接口,，會(huì)去考慮使用SOAP（webservice）。至于前端和服務(wù)端,，就目前而言,，但凡腦子沒被驢踢，都會(huì)選擇REST,。不過從筆者前后經(jīng)歷的各家公司,，各個(gè)項(xiàng)目組，以及周圍使用人員來說,，使用SOAP（webservice）的人員,，確實(shí)少的可憐，除非一些老項(xiàng)目還在維護(hù),，尤其微服務(wù)起來以后,，SOAP（webservice）方式,，幾乎沒有人會(huì)在新項(xiàng)目中使用。

3.3.REST ful

如果REST滿足一定條件（C/S,、無狀態(tài),、分層系統(tǒng)、統(tǒng)一接口）,，則稱為REST ful,。你可以理解成REST ful就是更加規(guī)范的REST。

3.4.RPC

RPC（Remote Procedure Call）遠(yuǎn)程過程調(diào)用,，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù),，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。
RPC協(xié)議假定某些傳輸協(xié)議的存在,，如TCP或UDP,，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中,，RPC跨越了傳輸層和應(yīng)用層,。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。
簡(jiǎn)單的理解是一個(gè)節(jié)點(diǎn)請(qǐng)求另一個(gè)節(jié)點(diǎn)提供的服務(wù),。（本地的方法去調(diào)用其他服務(wù)器上的方法）,。

3.5.RPC和REST ful區(qū)別

RPC是以動(dòng)詞為中心的；
REST ful是以名詞為中心的（動(dòng)詞指的是一些方法, 名詞是指資源）
比如RPC實(shí)現(xiàn)增刪查改用戶,，使用動(dòng)詞的方式來區(qū)分增刪查改,。

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

而在restful中，只使用名稱（資源）不是用動(dòng)詞的方法來區(qū)分增刪查改,，而是以請(qǐng)求方式來區(qū)分資源,。因此對(duì)于restful接口中，對(duì)統(tǒng)一資源的操作（增刪查改）,，地址永遠(yuǎn)是同一個(gè),。
不管增刪查改那種方式請(qǐng)求資源，資源都是user,
創(chuàng)建用戶,，則用post請(qǐng)求,，
更新用戶，則用put請(qǐng)求,，
刪除用戶,，則用delete請(qǐng)求，
查詢用戶,，則用get請(qǐng)求,。
比如servlet實(shí)現(xiàn)REST ful

springMVC實(shí)現(xiàn)REST ful

4.微服務(wù)架構(gòu)

4.1.微服務(wù)介紹

SOA架構(gòu)體系中，是將單體架構(gòu)拆分成多個(gè)子系統(tǒng),。
而在微服務(wù)架構(gòu)中,，是將系統(tǒng)業(yè)務(wù)按照功能拆分為更加細(xì)粒度的服務(wù),。所拆分的每一個(gè)服務(wù)都是一個(gè)獨(dú)立的應(yīng)用，這些應(yīng)用對(duì)外提供公共的API（一般使用REST API）,，可以獨(dú)立承擔(dān)對(duì)外服務(wù)的職責(zé),。因此微服務(wù)架構(gòu)的拆分比SOA架構(gòu)的拆分還要細(xì)粒度。

4.2.微服務(wù)架構(gòu)實(shí)現(xiàn)

回一下我們使用微服務(wù)的時(shí)候,，是不是有一種感覺，在當(dāng)前的項(xiàng)目中調(diào)用了其他項(xiàng)目的方法,？
顯而易見微服務(wù)采用的是RPC（遠(yuǎn)程過程調(diào)用）方式實(shí)現(xiàn)的。
值得注意的是：
Dubbo就是一種RPC框架。他的通訊協(xié)議是RPC協(xié)議,；
RPC是基于TCP和HTTP協(xié)議的,，是把http作為一種傳輸協(xié)議，本身還會(huì)封裝一層RPC框架的應(yīng)用層協(xié)議,，不同語言之間調(diào)用需要依賴RPC協(xié)議,。
Spring Cloud也是一種RPC框架。但是他的通訊協(xié)議不是RPC協(xié)議,，而是http協(xié)議,，遵循REST ful風(fēng)格。
Rest基于http作為應(yīng)用協(xié)議,，不同語言之間調(diào)用比較方便,。

4.3.微服務(wù)架構(gòu)對(duì)比SOA架構(gòu)

至此完畢，后續(xù)就會(huì)開始進(jìn)入到Spring Boot了,。