一.什麼是微服務

微服務就是一些協同工作的小而自治的服務。

1. 服務要足夠小

在使用微服務的時候，內聚性是一個很重要的概念。Robert C. Martion對 單一職責原則 有個論述是： 把相同原因而變化的東西聚合到一起，而把不同原因而變化的東西分離開。這個論述很好的強調了內聚性這個概念。

那麼服務要多小才算足夠小呢？

要考慮這些因素：服務越小，微服務架構的優點和缺點也就越明顯。使用的服務越小，獨立性帶來的好處就越多。但是管理大量服務也會越複雜，之後會將這一複雜性。

2. 自治性

一個微服務就是一個獨立的實體。它可以獨立的部署在PAAS(Platform As A Service,平臺即服務)上，也可以作為一個作業系統程序存在。

我們要儘量避免把多個服務部署到一臺機器上。

服務之間通過網路呼叫進行通訊，從而加強服務之間的隔離性，避免緊耦合。

這些服務應該可以彼此間獨立的進行修改，並且某個服務的部署不應該引起該服務消費方的變動。

服務會暴露出API(Application Programming Interface , 應用程式設計介面)，然後服務之間通過這些API進行通訊。API的實現技術應該避免與消費方耦合，這就意味著應該選擇與具體技術不相關的API實現方式，以保證技術的選擇不被限制。

如果系統沒有很好的解耦，那麼一旦出現問題，所有的功能都將不可用。有個黃金法則是：你是否能修改一個服務並對其進行部署，而不影響其他任何服務？

為了達到解耦的目的，你需要正確的建模服務和API。

二.主要好處

它的主要好處包括：技術異構性、彈性、擴充套件、簡化部署、與組織結構相匹配、可組合性、對可替代性的優化

1. 技術異構性

在一個由多個服務相互協作的系統中，可以在不同的服務中使用最適合該服務的技術。嘗試使用一種適合所有場景的標準化技術，會使得所有的場景都無法得到很好的支援。

2.彈性

彈性工程學的一個關鍵概念是艙壁。如果系統中的一個元件不可用了，但並沒有導致級聯故障，那麼系統的其他部分還可以正常執行。服務邊界就是一個很顯然的艙壁。

在單塊系統中，如果服務不可用，那麼所有功能都會不可用。

對於單塊服務的系統而言，可以通過將相同的例項執行在不同的機器上來降低功能完全不可用的概率，

然而微服務系統本身就能夠很好的處理服務不可用和功能降級問題。

微服務系統可以改進彈性，但你還是需要謹慎對待，因為一旦使用了分散式系統，網路會是一個問題，而且還有機器，我們需要了解問題出現時應該如何對使用者進行展示。

 艙壁模式：

艙壁模式（Bulkhead）隔離了每個工作負載或服務的關鍵資源，如連線池、記憶體和CPU。
使用艙壁避免了單個工作負載（或服務）消耗掉所有資源，從而導致其他服務出現故障的場景。
這種模式主要是通過防止由一個服務引起的級聯故障來增加系統的彈性。

下圖描述了實施艙壁的簡單的示例場景：在左側，微服務A，用同一個連線池去請求X和Y兩個服務。
如果服務X或服務的Y其中任何一個行為異常，這會影響連線池的整體行為。
如果艙壁模式實現，如該圖所示的右側，即使微服務X被錯誤操作，只有池X將受到影響。
微服務Y可以繼續為應用程式提供服務.

艙壁的概念在軟體開發中可以被應用在隔離資源上。

而在工業中使用艙壁將船舶劃分為幾個部分，以便在船體破壞的情況下，可以將船舶各個部件密封起來。

泰坦尼克號沉沒的主要原因之一是其艙壁設計失敗，水可以通過上面的甲板倒在艙壁的頂部，最後整個船淹沒

參考網址：

https://lvjun106.iteye.com/blog/2427353

https://www.cnblogs.com/lfs2640666960/p/9543096.html

 3.擴充套件

龐大的單塊服務只能作為一個整體進行擴充套件。即使系統中只有一小部分存在效能問題，也需要對整個服務進行擴充套件。

如果使用較小的多個服務，則可以只對需要擴充套件的服務進行擴充套件，這樣就可以把那些不需要擴充套件的服務執行在更小的，效能稍差的硬體上。

在使用類似Amazon雲服務之類的平臺時，也可以只對需要的服務進行擴充套件，從而節省成本。

4.簡化部署

在有幾百萬行的單塊應用程式中，即使只修改一行程式碼，也需要重新部署整個應用程式才能夠釋出該變更。

這種部署的影響很大，風險很高，因此相關干係人不敢輕易做部署。於是在實際操作中，部署的頻率就會變的很低。

這意味著在兩次釋出之間我們對軟體做了很多功能增強，但直到最後一刻才把這些大量的變更一次性發布到生成環境中。

這時，另外一個問題就顯現出來了：兩次釋出之間的差異越大，出錯的可能性就更大。

在微服務架構中，各個服務的部署時獨立的，這樣就可以更快的多特定部分的程式碼進行部署。

如果真的出了問題，也只會影響一個服務，並且容器快速回滾，也意味著客戶可以更快的使用我們開發的新功能。

5.與組織結構相匹配

微服務的架構可以很好的將架構和組織結構相匹配，避免出現過大的程式碼庫，從而獲得理想的團隊大小和生產力。

服務的所有權也可以在團隊之間遷移，從而避免異地團隊的出現。

6. 可組合性

分散式系統和麵向服務架構 聲稱的主要好處是易於重用已有功能。

在微服務架構中，根據不同的目的，人們可以通過不同的方式使用同一個功能，在考慮客戶如何使用該軟體時，這一點尤其重要。

現在我們需要考慮的應用種類包括Web , 原生應用、移動端Web 、平板應用及可穿戴裝置等，針對每一種都應該考慮如何對已有的功能進行組合來實現這些應用。

在微服務架構中，系統會開放很多介面供外部使用。當情況發生改變時，可以使用不同的方式構建應用，而整體化應用程式只能提供一個非常粗粒度的介面供外部使用。

7.可替代性的優化

使用微服務架構的團隊可以在需要時輕易重寫服務，或者刪除不再使用的服務。當一個程式碼庫只有幾百行時，人們也不會對它有太多感情上的依賴，所以很容易替換它。

三. 面向服務的架構

SOA(Service-Oriented Architecture, 面向服務的架構)是一種設計方法，其中包含多個服務，而服務之間通過配合最終會提供一系列功能。

一個服務 通常以獨立的形式存在於作業系統程序中。服務之間通過網路呼叫，而非採用程序內呼叫的方式進行通訊。

它的目標是在不影響其他任何人的情況下透明的替換一個服務，只要替換之後的服務的外部介面沒有太大變化即可。這種性質能夠大大簡化軟體運維甚至軟體重寫的過程。

實施SOA時，會遇到這些問題：通訊協議(例如SOAP)如何選擇、第三方中介軟體如何選擇、服務粒度如何確定等。

四. 其他分解技術

當你開始使用微服務時會發現，很多基於微服務的架構主要有兩個優勢：

首先它具有較小的粒度，其次它能夠在解決問題的方法上給予你更多的選擇。

那麼其他的分解技術是否也有相應的好處呢？

1. 共享庫

基本上所有的語言都支援將整個程式碼庫分解成為多個庫，這是一種非常標準的分解技術。這些庫可以由第三方或者自己的組織提供。

不同的團隊和服務可以通過庫的形式共享功能。

團隊可以圍繞庫來進行組織，但是庫有一些缺點。

　　首先，你無法選擇異構的技術。一般來說，這些庫只能在同一種語言中，或者至少在同一個平臺上使用。

　　其次，除非你使用的是動態連結庫，否則每次當庫有更新的時候，都需要重新部署整個程序，以至於無法獨立的部署變更。

　　而最糟糕的影響可能是你會缺乏一個比較明顯的接縫來建立架構的安全性保護措施，從而無法確保系統的彈性。

如果使用共享程式碼來做服務之間的通訊的話，那麼它會成為一個耦合點。

服務之間可以並且應該大量使用第三方庫來重用公共程式碼，但有時候效果不太好。

2.模組

除了簡單的庫之外，有些語言提供了自己的模組分解技術。它們允許對模組進行生命週期管理，這樣就可以把模組部署到執行的程序中，並且可以不停止整個程序的前提下對某個模組進行修改。

作為一個與具體技術相關的模組分解技術，OSGI (Open Source Gateway ,Initiative , 開放服務閘道器協議)值得一提。

五. 沒有銀彈

（沒有銀彈指的是沒有任何一項技術或方法可使軟體工程的生產力在十年內提高十倍。）

如果你之後想要使用微服務，那麼你需要面對分散式系統需要面對的複雜性；

如果你過去的經驗更多的是關於單塊系統，那麼為了得到微服務的好處，你需要在部署，測試，監控等方面做很多工作。

你還需要考慮如何擴充套件系統，並且保證它們的彈性。

如果你發現還需要處理類似分散式事務或者與CAP相關的問題，也不要感到驚訝。

&n