1.什么是微服務(wù)

微服務(wù)是什么？有很多小伙伴對此還不是很了解。微服務(wù)是什么可以從兩個方面去理解，什么是"微"、什么是"服務(wù)"， 微 狹義來講就是體積小、著名的"2 pizza 團(tuán)隊"很好的詮釋了這一解釋。 而所謂服務(wù)，一定要區(qū)別于系統(tǒng)，服務(wù)一個或者一組相對較小且獨(dú)立的功能單元，是用戶可以感知最小功能集。

2.微服務(wù)由來

那么微服務(wù)是怎么來的呢？小編來給大家介紹一下。微服務(wù)最早由Martin Fowler與James Lewis于2014年共同提出，微服務(wù)架構(gòu)風(fēng)格是一種使用一套小服務(wù)來開發(fā)單個應(yīng)用的方式途徑，每個服務(wù)運(yùn)行在自己的進(jìn)程中，并使用輕量級機(jī)制通信，通常是HTTP API，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建，并能夠通過自動化部署機(jī)制來獨(dú)立部署，這些服務(wù)使用不同的編程語言實(shí)現(xiàn)，以及不同數(shù)據(jù)存儲技術(shù)，并保持最低限度的集中式管理。

3.為什么需要微服務(wù)?

微服務(wù)對很多行業(yè)來說都是很重要的，大家可能有疑惑，為什么需要微服務(wù)在傳統(tǒng)的IT行業(yè)軟件大多都是各種獨(dú)立系統(tǒng)的堆砌，這些系統(tǒng)的問題總結(jié)來說就是擴(kuò)展性差，可靠性不高，維護(hù)成本高。到后面引入了SOA服務(wù)化，但是，由于 SOA 早期均使用了總線模式，這種總線模式是與某種技術(shù)棧強(qiáng)綁定的，比如：J2EE。這導(dǎo)致很多企業(yè)的遺留系統(tǒng)很難對接，切換時間太長，成本太高，新系統(tǒng)穩(wěn)定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻成為了企業(yè)級奢侈品，中小公司都望而生畏。

4.微服務(wù)本質(zhì)

微服務(wù)的本質(zhì)是什么？這個問題不是很難理解，微服務(wù)關(guān)鍵其實(shí)不僅僅是微服務(wù)本身，而是系統(tǒng)要提供一套基礎(chǔ)的架構(gòu)，這種架構(gòu)使得微服務(wù)可以獨(dú)立的部署、運(yùn)行、升級，不僅如此，這個系統(tǒng)架構(gòu)還讓微服務(wù)與微服務(wù)之間在結(jié)構(gòu)上“松耦合”，而在功能上則表現(xiàn)為一個統(tǒng)一的整體。這種所謂的“統(tǒng)一的整體”表現(xiàn)出來的是統(tǒng)一風(fēng)格的界面，統(tǒng)一的權(quán)限管理，統(tǒng)一的安全策略，統(tǒng)一的上線過程，統(tǒng)一的日志和審計方法，統(tǒng)一的調(diào)度方式，統(tǒng)一的訪問入口等等。

微服務(wù)的目的是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署 。

微服務(wù)提倡的理念團(tuán)隊間應(yīng)該是 inter-operate, not integrate 。inter-operate是定義好系統(tǒng)的邊界和接口，在一個團(tuán)隊內(nèi)全棧，讓團(tuán)隊自治，原因就是因?yàn)槿绻麍F(tuán)隊按照這樣的方式組建，將溝通的成本維持在系統(tǒng)內(nèi)部，每個子系統(tǒng)就會更加內(nèi)聚，彼此的依賴耦合能變?nèi)酰缦到y(tǒng)的溝通成本也就能降低。

5.微服務(wù)折分與設(shè)計

從單體式結(jié)構(gòu)轉(zhuǎn)向微服務(wù)架構(gòu)中會持續(xù)碰到服務(wù)邊界劃分的問題：比如，我們有user 服務(wù)來提供用戶的基礎(chǔ)信息，那么用戶的頭像和圖片等是應(yīng)該單獨(dú)劃分為一個新的service更好還是應(yīng)該合并到user服務(wù)里呢?如果服務(wù)的粒度劃分的過粗，那就回到了單體式的老路;如果過細(xì)，那服務(wù)間調(diào)用的開銷就變得不可忽視了，管理難度也會指數(shù)級增加。目前為止還沒有一個可以稱之為服務(wù)邊界劃分的標(biāo)準(zhǔn)，只能根據(jù)不同的業(yè)務(wù)系統(tǒng)加以調(diào)節(jié)

拆分的大原則是當(dāng)一塊業(yè)務(wù)不依賴或極少依賴其它服務(wù)，有獨(dú)立的業(yè)務(wù)語義，為超過2個的其他服務(wù)或客戶端提供數(shù)據(jù)，那么它就應(yīng)該被拆分成一個獨(dú)立的服務(wù)模塊。

微服務(wù)設(shè)計原則

單一職責(zé)原則

意思是每個微服務(wù)只需要實(shí)現(xiàn)自己的業(yè)務(wù)邏輯就可以了，比如訂單管理模塊，它只需要處理訂單的業(yè)務(wù)邏輯就可以了，其它的不必考慮。

服務(wù)自治原則

意思是每個微服務(wù)從開發(fā)、測試、運(yùn)維等都是獨(dú)立的，包括存儲的數(shù)據(jù)庫也都是獨(dú)立的，自己就有一套完整的流程，我們完全可以把它當(dāng)成一個項目來對待。不必依賴于其它模塊。

輕量級通信原則

首先是通信的語言非常的輕量，第二，該通信方式需要是跨語言、跨平臺的，之所以要跨平臺、跨語言就是為了讓每個微服務(wù)都有足夠的獨(dú)立性，可以不受技術(shù)的鉗制。

接口明確原則

由于微服務(wù)之間可能存在著調(diào)用關(guān)系，為了盡量避免以后由于某個微服務(wù)的接口變化而導(dǎo)致其它微服務(wù)都做調(diào)整，在設(shè)計之初就要考慮到所有情況，讓接口盡量做的更通用，更靈活，從而盡量避免其它模塊也做調(diào)整。

6.什么樣的項目適合微服務(wù)

微服務(wù)可以按照業(yè)務(wù)功能本身的獨(dú)立性來劃分，如果系統(tǒng)提供的業(yè)務(wù)是非常底層的，如：操作系統(tǒng)內(nèi)核、存儲系統(tǒng)、網(wǎng)絡(luò)系統(tǒng)、數(shù)據(jù)庫系統(tǒng)等等，這類系統(tǒng)都偏底層，功能和功能之間有著緊密的配合關(guān)系，如果強(qiáng)制拆分為較小的服務(wù)單元，會讓集成工作量急劇上升，并且這種人為的切割無法帶來業(yè)務(wù)上的真正的隔離，所以無法做到獨(dú)立部署和運(yùn)行，也就不適合做成微服務(wù)了。

能不能做成微服務(wù)，取決于四個要素：

?。何⒎?wù)體積小，2 pizza 團(tuán)隊。

獨(dú)：能夠獨(dú)立的部署和運(yùn)行。

輕：使用輕量級的通信機(jī)制和架構(gòu)。

松：為服務(wù)之間是松耦合的。

7.微服務(wù)優(yōu)勢與缺點(diǎn)

(1)特性

每個微服務(wù)可獨(dú)立運(yùn)行在自己的進(jìn)程里;

一系列獨(dú)立運(yùn)行的微服務(wù)共同構(gòu)建起了整個系統(tǒng);

每個服務(wù)為獨(dú)立的業(yè)務(wù)開發(fā)，一個微服務(wù)一般完成某個特定的功能，比如：訂單管理，用戶管理等;

微服務(wù)之間通過一些輕量級的通信機(jī)制進(jìn)行通信，例如通過REST API或者RPC的方式進(jìn)行調(diào)用。

(2)特點(diǎn)

易于開發(fā)和維護(hù)

由于微服務(wù)單個模塊就相當(dāng)于一個項目，開發(fā)這個模塊我們就只需關(guān)心這個模塊的邏輯即可，代碼量和邏輯復(fù)雜度都會降低，從而易于開發(fā)和維護(hù)。

啟動較快

這是相對單個微服務(wù)來講的，相比于啟動單體架構(gòu)的整個項目，啟動某個模塊的服務(wù)速度明顯是要快很多的。

局部修改容易部署

在開發(fā)中發(fā)現(xiàn)了一個問題，如果是單體架構(gòu)的話，我們就需要重新發(fā)布并啟動整個項目，非常耗時間，但是微服務(wù)則不同，哪個模塊出現(xiàn)了bug我們只需要解決那個模塊的bug就可以了，解決完bug之后，我們只需要重啟這個模塊的服務(wù)即可，部署相對簡單，不必重啟整個項目從而大大節(jié)約時間。

技術(shù)棧不受限

比如訂單微服務(wù)和電影微服務(wù)原來都是用java寫的，現(xiàn)在我們想把電影微服務(wù)改成nodeJs技術(shù)，這是完全可以的，而且由于所關(guān)注的只是電影的邏輯而已，因此技術(shù)更換的成本也就會少很多。

按需伸縮

我們上面說了單體架構(gòu)在想擴(kuò)展某個模塊的性能時不得不考慮到其它模塊的性能會不會受影響，對于我們微服務(wù)來講，完全不是問題，電影模塊通過什么方式來提升性能不必考慮其它模塊的情況。

(3)缺點(diǎn)

運(yùn)維要求較高

對于單體架構(gòu)來講，我們只需要維護(hù)好這一個項目就可以了，但是對于微服務(wù)架構(gòu)來講，由于項目是由多個微服務(wù)構(gòu)成的，每個模塊出現(xiàn)問題都會造成整個項目運(yùn)行出現(xiàn)異常，想要知道是哪個模塊造成的問題往往是不容易的，因?yàn)槲覀儫o法一步一步通過debug的方式來跟蹤，這就對運(yùn)維人員提出了很高的要求。

分布式的復(fù)雜性

對于單體架構(gòu)來講，我們可以不使用分布式，但是對于微服務(wù)架構(gòu)來說，分布式幾乎是必會用的技術(shù)，由于分布式本身的復(fù)雜性，導(dǎo)致微服務(wù)架構(gòu)也變得復(fù)雜起來。

接口調(diào)整成本高

比如，用戶微服務(wù)是要被訂單微服務(wù)和電影微服務(wù)所調(diào)用的，一旦用戶微服務(wù)的接口發(fā)生大的變動，那么所有依賴它的微服務(wù)都要做相應(yīng)的調(diào)整，由于微服務(wù)可能非常多，那么調(diào)整接口所造成的成本將會明顯提高。

重復(fù)勞動

對于單體架構(gòu)來講，如果某段業(yè)務(wù)被多個模塊所共同使用，我們便可以抽象成一個工具類，被所有模塊直接調(diào)用，但是微服務(wù)卻無法這樣做，因?yàn)檫@個微服務(wù)的工具類是不能被其它微服務(wù)所直接調(diào)用的，從而我們便不得不在每個微服務(wù)上都建這么一個工具類，從而導(dǎo)致代碼的重復(fù)。

8.微服務(wù)開發(fā)框架

目前微服務(wù)的開發(fā)框架，最常用的有以下四個：

Spring Cloud：http://projects.spring.io/spring-cloud(現(xiàn)在非常流行的微服務(wù)架構(gòu))

Dubbo：http：//dubbo.io

Dropwizard：http://www.dropwizard.io (關(guān)注單個微服務(wù)的開發(fā))

Consul、etcd&etc.(微服務(wù)的模塊)

9.Sprint cloud 和 Sprint boot區(qū)別

Spring Boot:

旨在簡化創(chuàng)建產(chǎn)品級的Spring應(yīng)用和服務(wù)，簡化了配置文件，使用嵌入式web服務(wù)器，含有諸多開箱即用微服務(wù)功能，可以和spring cloud聯(lián)合部署。

Spring Cloud：

微服務(wù)工具包，為開發(fā)者提供了在分布式系統(tǒng)的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線等開發(fā)工具包。

以上就是動力節(jié)點(diǎn)小編介紹的"微服務(wù)的介紹"，希望對大家有幫助，想了解更多可查看Java教程。動力節(jié)點(diǎn)在線學(xué)習(xí)教程，針對沒有任何Java基礎(chǔ)的讀者學(xué)習(xí),讓你從入門到精通,主要介紹了一些Java基礎(chǔ)的核心知識，讓同學(xué)們更好更方便的學(xué)習(xí)和了解Java編程，感興趣的同學(xué)可以關(guān)注一下。