作為一種新型軟件設計模式，微服務架構能夠將大型應用程序拆分為多種松散耦合的不同組件。為了加快部署速度，提高可擴展性以及制定更為靈活的開發流程，Nike和Netflix等公司已經開始采用這種設計模式。但是在保證微服務基礎架構平穩運行方面，運維團隊還面臨著諸多管理方面的挑戰，比如從服務發現到自動化發布。

“我們想要對現有軟件的可擴展性進行優化，避免在開發早期，基礎架構規模設計過于龐大，”API監控服務公司Runscope CEO John Sheehan表示。

這家公司最初只提供一些按照功能劃分的關鍵服務，比如管理用戶身份以及存儲測試數據等來實現一些底層的重復功能。而現在Runscope已經擁有50多種不同規模的內部服務，在2014年當中平均每天要部署超過30種服務。

“如果某項服務需要使用更多的資源，我們將會對其進行單獨擴展，而不必為整個集群分配更多的資源，” Sheehan說，“這種相互分離的方式還能夠加快我們的服務部署速度。”

為了保證這種方式的最終成功，Runscope在自動化、部署和管理工具方面進行了大量投資，并且為應用開發人員準備了能夠不斷構建和使用服務的庫和框架。如果沒有這些投資，那么管理這些服務的所產生的系統開銷可能已經超過了其所帶來的收益。

“如果你愿意在基礎架構方面進行投資，那么規模較小、可重復使用的微服務所帶來的種種好處將會顯著提高ROI，” Sheehan說。

運維團隊面臨的全新挑戰

任何一種新技術都是一把雙刃劍。微服務架構引入了網絡層隔離的概念，這將會引發大量全新問題，比如延遲時間以及網絡不可用等等。運維團隊不僅需要理解指定服務的運行原理，還要理解哪些服務和關聯可能影響應用程序的性能表現，這也就是為什么API監控和測試變得如此關鍵的原因。

所有這些微小部分決定了應用程序的性能體驗。

“如果你不了解這些組成部分之間的相互作用如何影響性能表現，那么就不能發現那些可以幫助提升應用程序穩定性的運行數據，” Sheehan說。由于網絡當中出現了一些其他的變化因素，因此必須關注一些之前從未出現的問題。

監控和測試這些組件對于解決問題來說是十分重要的。

微服務架構允許每種服務運行在自己的技術棧當中，因此運維團隊必須了解如何操作和維護適用于不同服務的技術棧。

重新設計發布流程

微服務架構將單一的應用程序拆分為獨立的微服務單元，將軟件開發工作分配給多個松耦合團隊。

“使用微服務架構的團隊必須擴展軟件發布管理流程，以解決服務依賴性、網絡分發以及自主發布時間計劃等問題，”SOA中間件提供商WSO2平臺架構師Chris Haddad表示。

終端用戶應用程序通常會使用多種微服務，比如產品分類、用戶配置文件和分組等。此外，微服務之間也可能存在關聯性。在多個團隊和分布式網絡拓撲當中分發微服務為企業帶來了新的應用發布挑戰。

“成功的團隊將會在其軟件發布流程當中引入服務版本控制、發布測試、增量升級以及發布回滾等功能，” Haddad說。

運維團隊應該建立實現增量升級的相關流程。這種類型的更新意味著在上一個版本的基礎上部署一個新的微服務版本，之后逐漸將流量引入到新版本當中。

增量升級將用戶的影響范圍拆分為多個部分，允許技術團隊在真實的生產環境當中進行“冒煙測試”。基于A/B測試分析，如果某種剛剛部署的微服務出現問題或者用戶體驗十分糟糕，那么技術團隊應該安全地將其回滾到之前的微服務版本。開發團隊應該在發布管理流程當中加入安全和清晰的回滾功能。

為動態網絡供應做準備

微服務架構允許企業使用多種微型服務組成一個獨立的應用程序。盡管在很多大型企業當中，比如Netflix和Nike，這種方式已經非常流行，但還是應該認真考慮微服務架構對于底層網絡和基礎架構將會造成哪些影響。

微服務能夠改變虛擬網絡的速度和結構，并且對底層服務產生影響。運維團隊和開發人員必須思考如何將網絡服務改造為以應用程序為中心——比如實現負載均衡、緩存、性能表現、監控和應用安全等功能，而不是以下這些功能——比如防御DDos攻擊、VPN以及其他，應用程序基礎架構提供商F5 Networks的首先技術架構師Lori MacVittie表示。

那些以應用程序為中心的服務都會和應用程序產生關聯，因此會產生一種和應用程序緊密相關的服務模型。本質上，每種微服務都可以由一套與之關聯的應用程序服務組成。在軟件發布過程當中，企業需要提供和配置大量應用程序及其相關服務。

“隨著運維和開發團隊之間的協作不斷加強，現在已經能夠確保微服務以及其他相關服務順利發布了，” MacVittie說。

在云中使用微服務架構還存在一些潛在問題。比如應用程序出現問題時，大多數應用程序提供商并不會主動向客戶提供其網絡基礎架構詳細信息，MacVittie說。

如果依靠內部團隊維護基礎架構，企業還需要考慮安全問題。安全服務強制阻止的惡意請求不會對應用程序產生太大壓力，反而是安全服務可能影響應用程序的性能表現。這可能是最容易被人忽略的影響應用程序性能表現的因素，但是可以通過使用恰當的安全服務進行修復。

實現服務發現

松耦合是微服務架構的關鍵準則。各個組件需要使用單獨的基礎架構尋找需要通信的服務IP地址。服務發現層必須和云環境——也就是虛擬機被創建和銷毀的地方——當中的基礎架構一樣是動態的。

“你可以將服務發現工具理解為基礎架構的連接紐帶，”數據中心管理工具提供商HashiCorp的客戶服務總監Kevin Fishner表示。

Consul、etcd和Zookeeper都是不錯的服務發現工具。為了幫助配置動態服務，還可以使用一些自動化工具，比如Puppet、Chef、Ansible和Salt等。

Fishner說，企業還應該考慮和基架構相關的創建和管理工具，比如Terraform、CloudFormation和Heat。隨著Docker這種容器工具的逐漸流行，企業需要使用新的調度機制，從Mesos到Kubernetes，都是頂級的基礎架構管理工具。

成功計劃

遷移到微服務架構并不是一個十分容易的過程，因此開發人員和運維團隊需要相互配合才能取得最后的成功。

“盡管微服務架構的理論基礎就是在遵守合同的前提下，讓每個擁有服務的團隊都能夠獨立部署服務，但是這種情況卻很少發生，” Codenvy CEO Tyler Jewell表示，他所管理的是一家使用微服務構建云集成開發平臺的公司。

Codenvy用戶和應用程序進行交互，而這些應用程序是依賴于多種微服務的獨立系統。Codenvy向用戶發布的新功能都會依賴于多種微服務，其中許多還需要擴展新特性。因此需要保證所有相關組件——也就是應用程序和微服務——必須同時完成部署。

“因此，我們必須在計劃和發布協調方面進行改進。對于任何階段的部署來說，這都不是一個十分容易的過程，” Jewell說。