概述

最近讀了【Java微服務】一書，只有第一章看的比較認真，其他章節，如果對微服務已經有些瞭解的，可以大概瀏覽器一下就行。事實上，這本書寫的最好的就是第一章。

下面把第一章中我覺得比較重要的語句摘錄下來。

重要語句

可擴充套件性

隨著整體式應用程式所有的部件都被打包在一起，它在擴充套件時是龐大的，需要擴充套件一切。例如，在餐館訂座應用程式中，即使你想要只擴充套件餐桌預定服務，也要擴充套件整個應用程式，而不能單獨擴充套件餐桌預定服務。它未能以最佳方式利用資源。

微服務提供了只擴充套件那些需要擴充套件的服務的靈活性，它允許對資源的最優利用。

微服務開發使用REST式的web服務開發，REST

伺服器端是無狀態的，使得在這個意義上，它是可擴充套件的，這意味著伺服器之間沒有太多的通訊，從而它可水平擴充套件。

在出故障時回滾版本

很多人可能都曾遇到過由於一個功能故障，致使整個版本延遲釋出的痛苦。

微服務給我們提供僅回滾那些出故障的功能的靈活性。假設在某個生產版本中釋出新的功能、增強功能和bug修復後，你發現支付服務中有缺陷需要立即修復。由於你已經使用基於微服務的架構，可以僅回滾付款服務而不是回滾整個版本。這不僅允許你妥善處理故障，還有助於迅速向客戶交付功能或者修補程式。

採用新技術的問題

整體式應用很難在開發的後期或在產品出於成熟的狀態後引進新技術。技術在逐年進步。例如，你的系統可能會使用Java

設計，幾年後，因為業務需要或為了利用新技術的優勢，你又想使用Ruby或Node JS開發新服務。整體式應用很難利用這些新技術。

微服務是小型、自包含的功能，所以它提供了低風險地嘗試一項新技術的機會。而對整體式系統而言，絕對不能這樣。

減輕開發工作量–可以做得更好

一般來說，大型整體式應用程式的程式碼是開發人員最難理解的，並且新開發人員需要相當長的時間，才能成為生產力。甚至把大型整體式應用程式載入到IDE中都是麻煩的，它會降低IDE執行速度，使開發人員的生產力降低。

大型整體式應用程式中的更改很難實施，並花費更多時間。這是由於有大量的程式碼庫，並且，如果未恰當並徹底的執行影響分析，存在bug

的風險會很高。因此，執行全面影響分析成為開發人員實施更改之前的先決條件。隨著程式碼更改量的增加，與程式碼更改相關聯的風險呈指數級上升。