自從2011年微服務這個詞被杜撰出來，它就在前瞻的應用開發機構中引起軒然大波。過了短短幾年，微服務即成為主流，根據Nginix最近的調查，36%受調查的企業當前正在使用微服務，另外26%還在研究階段。但到底什么是微服務架構呢?它適合你的機構文化、技能和需要嗎?

 

一起來看看你應該在下一個應用開發項目使用微服務的七個理由，還有五個你成功的道路上必須掃除的障礙。

 

 

微服務是面向服務的體系架構(SOA)的一個變體，它是這樣一個架構樣式，在這里應用程序被分解為多個寬松地耦合的服務。有了細粒度的服務和輕量級的協議，微服務可以提供增強的模塊、使應用更容易開發、測試、部署、還有更重要的是變更和維護。

 

當中心化的、多級的架構被用來在單個代碼庫上創建整個應用時，毫無疑問你的機構仍然受制于單體時期開發的應用。在臺式機主宰IT時期客戶服務模式是一個極好的選擇。但是由于移動設備和云的興起，后臺數據必須對一系列的設備可用，而單體架構不再讓你輕松了，因為不管什么時候做出更改，系統都必須被更新，每次你要添加功能或調整到新環境時，它都為新錯誤創造了可能性。更糟糕的是，由于一切都受到單個代碼庫的束縛，你不能擴展某一個功能或服務，你必須擴展整個應用，這導致極其高昂的成本。

 

有了微服務，你的代碼被分解為以獨立進程運行的獨立服務。在獨立的、通信的服務的編制下，來自一個服務的輸出被用作另一個服務的輸入。微服務對那些對自己的應用所能支持的一些列設備沒有預設概念的企業尤其有用。由于微服務是設備和平臺無關的，它使企業能開發這樣的應用，這種應用能提供跨越多個平臺的持續的用戶體驗，橫跨網頁、手機、物聯網、可穿戴設備和智能手環等環境。網飛(Netflix)、貝寶、亞馬遜、易趣和推特只是其中幾家使用微服務的企業。

 

例如沃爾瑪加拿大，它于2012年將它的軟件架構重構成微服務。該公司在當時一直不具備處理每分鐘600萬頁面的能力，幾乎在一夜之間實現了轉化率大幅增長的結果。停機時間也被最小化了，公司可以用較廉價的x86服務器代替昂貴的商用硬件，結果是總體成本節省了20%~50%。

 

即便你的機構沒有沃爾瑪和亞馬遜的體量，微服務依然可以提供巨大的價值。下面是轉向微服務后你的機構能得到的其中一些好處。

 

 

有了微服務，你的整個應用都去中心化了，不像單體架構，代碼里的一個故障會影響到多個服務和功能，用微服務的話故障的影響很小。甚至當幾個系統都停機維護時，你的用戶也注意不到。

 

 

擴展性是微服務的關鍵方面。因為每一個服務都是一個獨立的組件，你可以擴展一個功能的規模而不影響整個應用。業務關鍵型服務可以被部署在多臺服務器上，在不影響其它服務的性能的情況下增強可用性和性能。

 

 

有了微服務，你就不必受制于單個供應商。你可以靈活地用正確的工具做正確的任務。每個服務都可以用它自己的語言、框架或輔助服務而同時可以和你的應用里的其它服務通信。

 

 

因為微服務是在寬松的耦合服務上工作的，你不必重寫整個代碼庫來增加或修改一個功能。你只變更某一個服務。通過開發可獨立測試或部屬的更小增量的應用，你可以讓你的應用和服務更快的上市。

 

 

微服務還使排錯和測試應用變得更容易。有了這些更小的經過持續交付和測試流程的模塊，你交付無錯應用的能力大大的提高了。

 

 

微服務還可以讓你優化資源。有了微服務，多個團隊在不同的服務上工作，使你可以更快地部署，或在需要時挖掘更多。開發時間縮短了，而你的團隊的代碼將更易于重用。通過解耦服務，你不必在昂貴的機器上操作。基本的x86機器就能做。微服務提升的效率不僅減少了架構成本，還最小化了停機時間。

 

 

不像單體應用，它有專門的團隊致力于單一的功能，比如用戶界面、數據庫、服務器端邏輯、技術層，微服務的跨功能團隊用持續交付模型來處理應用的整個生命周期。當開發者、運營、測試團隊同時在單個服務上工作時，測試和排錯變得容易和迅速。用了這個增量式開發的方法，代碼被持續地開發、測試和部署，你使用現成的庫代碼而不是重新發明輪子。

 

 

接受了微服務的企業已經意識到顯著的好處，忽視這個的機構可能會落伍。盡管微服務看起來很有前途，并不是所有的企業都能從微服務獲利。確保你的企業有足夠的能力管理它。以下是給機構的一些提醒。

 

 

有了增量式開發和持續交付，微服務讓你的機構長葆活力。員工應該立即調配資源以跟上最大化利用微服務所需的步伐。如果部署服務器要數天或數月的時間，你就會陷入嚴重的麻煩。同樣地，你應該快速地部署新服務和應用。

 

 

因為每一個服務都依賴它自己的語言、平臺和應用程序接口(API)，你將安排多個團隊同時在你的微服務項目的不同實體上工作。你需要穩健的監控來有效地監控和管理整個架構，因為如果你不知道服務什么時候會出故障或機器什么時候會停機，當這些情況發生的時候根本就不可能追蹤。

 

 

在跨功能團隊中工作，你的業務應該加入開發運維實踐和文化。在傳統的場合，開發者專注于特性和功能，而運營團隊則掉入了生產挑戰的陷進。在運維里，每個人都為服務的調配負責，當然也包括故障。

 

 

有了微服務，測試不再是直接的。每一個服務都有它自己的依賴關系，有些是直接的，有些是傳遞的。當功能被增加的時候，新的依賴關系會產生。要關注所有一切變得不實際。還有，當你的服務數量增加的時候，復雜性也增加了。不管是數據庫錯誤、網絡延遲、緩存問題、服務不可用性，你的微服務架構最好能處理合理級別的故障。所以，適應性測試和故障注入是必不可少的。

 

 

設計時為故障做好準備是很重要的。你應該準備好處理多個故障問題，比如系統停機、緩慢的服務和不期望的回應。在這里，負載均衡是很重要的，但是有后備計劃是另一個重要的選擇。當故障發生的時候，陷入困境的服務應該能繼續以降級的功能運行而不會使整個系統崩潰。