1.什么是微服務

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

2.微服務由來

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

3.為什么需要微服務?

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

4.微服務本質

微服務的本質是什么？這個問題不是很難理解，微服務關鍵其實不僅僅是微服務本身，而是系統要提供一套基礎的架構，這種架構使得微服務可以獨立的部署、運行、升級，不僅如此，這個系統架構還讓微服務與微服務之間在結構上“松耦合”，而在功能上則表現為一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的界面，統一的權限管理，統一的安全策略，統一的上線過程，統一的日志和審計方法，統一的調度方式，統一的訪問入口等等。

微服務的目的是有效的拆分應用，實現敏捷開發和部署 。

微服務提倡的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統的邊界和接口，在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。

5.微服務折分與設計

從單體式結構轉向微服務架構中會持續碰到服務邊界劃分的問題：比如，我們有user 服務來提供用戶的基礎信息，那么用戶的頭像和圖片等是應該單獨劃分為一個新的service更好還是應該合并到user服務里呢?如果服務的粒度劃分的過粗，那就回到了單體式的老路;如果過細，那服務間調用的開銷就變得不可忽視了，管理難度也會指數級增加。目前為止還沒有一個可以稱之為服務邊界劃分的標準，只能根據不同的業務系統加以調節

拆分的大原則是當一塊業務不依賴或極少依賴其它服務，有獨立的業務語義，為超過2個的其他服務或客戶端提供數據，那么它就應該被拆分成一個獨立的服務模塊。

微服務設計原則

單一職責原則

意思是每個微服務只需要實現自己的業務邏輯就可以了，比如訂單管理模塊，它只需要處理訂單的業務邏輯就可以了，其它的不必考慮。

服務自治原則

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

輕量級通信原則

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

接口明確原則

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

6.什么樣的項目適合微服務

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

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

小：微服務體積小，2 pizza 團隊。

獨：能夠獨立的部署和運行。

輕：使用輕量級的通信機制和架構。

松：為服務之間是松耦合的。

7.微服務優勢與缺點

(1)特性

每個微服務可獨立運行在自己的進程里;

一系列獨立運行的微服務共同構建起了整個系統;

每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，比如：訂單管理，用戶管理等;

微服務之間通過一些輕量級的通信機制進行通信，例如通過REST API或者RPC的方式進行調用。

(2)特點

易于開發和維護

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

啟動較快

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

局部修改容易部署

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

技術棧不受限

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

按需伸縮

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

(3)缺點

運維要求較高

對于單體架構來講，我們只需要維護好這一個項目就可以了，但是對于微服務架構來講，由于項目是由多個微服務構成的，每個模塊出現問題都會造成整個項目運行出現異常，想要知道是哪個模塊造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。

分布式的復雜性

對于單體架構來講，我們可以不使用分布式，但是對于微服務架構來說，分布式幾乎是必會用的技術，由于分布式本身的復雜性，導致微服務架構也變得復雜起來。

接口調整成本高

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

重復勞動

對于單體架構來講，如果某段業務被多個模塊所共同使用，我們便可以抽象成一個工具類，被所有模塊直接調用，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接調用的，從而我們便不得不在每個微服務上都建這么一個工具類，從而導致代碼的重復。

8.微服務開發框架

目前微服務的開發框架，最常用的有以下四個：

Spring Cloud：http://projects.spring.io/spring-cloud(現在非常流行的微服務架構)

Dubbo：http：//dubbo.io

Dropwizard：http://www.dropwizard.io (關注單個微服務的開發)

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

9.Sprint cloud 和 Sprint boot區別

Spring Boot:

旨在簡化創建產品級的Spring應用和服務，簡化了配置文件，使用嵌入式web服務器，含有諸多開箱即用微服務功能，可以和spring cloud聯合部署。

Spring Cloud：

微服務工具包，為開發者提供了在分布式系統的配置管理、服務發現、斷路器、智能路由、微代理、控制總線等開發工具包。

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