[[127190]]

編者按：微服務架構（MSA）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，并提供更加靈活的服務支持。

【51CTO譯文】作為加快Web和移動應用程序開發進程的一種方法，微服務架構在2014年開始受到關注。今年，更多的企業組織會獲得微服務帶來的好處。

使用服務構建應用程序這個概念一直具有吸引力。要是既然可以匯編通過標準API利用相同服務的多個應用程序，何必要從頭開始編寫代碼呢？只要正確配置那些服務，你應該能獲得巨大的規模經濟效益。

在過去，試圖踐行這個概念的做法在過度設計（尤其是CORBA 和 SOA趨勢）的重壓之下未能如愿以償。但是微服務最令人關注的方面之一在于，使用微服務在過去是開發人員推動之下的草根現象。大致上來說，微服務就是可通過API訪問的、單一用途的小型程序。這回，服務理念深得人心。

想了解微服務架構的實際案例，只要看一下Stefan Borsje在2014年撰寫的這篇博客：How we build microservices at Karma，他是專門向廣大消費者銷售無線熱點設備的Karma公司的***技術官兼聯合創始人。據Borsje聲稱，該公司在開發網上商店時，其開發團隊“無意中使用了”微服務。

我們從一個大型的后端應用程序著手，必要時將它分解成多個部分。隨著不斷地構建應用程序，我們開始清楚自己在努力解決的那個問題；而我們對這個問題越熟悉，我們需要為該應用程序的不同部分設置邊界就來得越明顯。每當我們遇到應該是獨立部分的組件，我們就將它變成一個服務。

起初，這些部分相對較大，但是與其他用戶采用微服務的情況一樣，我們也發現那些部分可以變得越來越小。

比如說，那個整體式應用程序最初有一個“商店”組件，Borsje的開發團隊將其細分為訂單處理、訂單執行和跟蹤等服務。連面向公眾的前端也被分解成了多個服務。Borsje表示，將細粒度功能分隔成獨立服務大幅提升了工作效率，這在一方面歸功于開發人員在開發時不需要操心整體式應用程序的所有依賴項。

對Karma來說，微服務存在的***問題在于測試方面。正如Borsje所說：“行動和最終結果相距甚遠，以至于很難發現準確的因果關系。整條鏈中可能會出現問題，但這條鏈中到底哪個環節出了問題呢？”

《敏捷宣言》一書的合著者Martin Fowler在去年3月份整理出了人們青睞微服務的原因，隨后在11月份發布了一篇演示文稿，較為詳細地概述了多層微服務測試體系。他支持單個服務的單元測試，這不足為奇，不過他承認這不足以確定整個系統是否在正常運行。他貼心地列出了一系列整合、組件、契約和端到端測試策略，這些策略有望幫助開發人員盡量弄明白微服務最棘手的問題之一。

另一個問題是：你無法總是預測哪些微服務在某些情形下可能無力滿足需求。我確信，這是Karma將其電子商務平臺部署在亞馬遜網絡服務（AWS）上的一個原因。在AWS環境下，自動擴展功能能夠在有需要的地方添加計算能力，有助于確保沒有哪個服務成為瓶頸。請注意：微服務的典型代表Netfilx也使用AWS――換句話說，微服務和云相輔相成。從理論上來說，你可以使用VMware或OpenStack，自行構建具有自動擴展功能的私有云，但是這么做困難重重，這是公有云勝出的一大原因。

支持微服務的另一項***技術是Docker，這項技術用于包裝應用程序，然后將它們部署在Linux容器中。事實證明，微服務和Docker可謂是天作之合，這是各大公有云現在都支持Docker的一大原因。

很顯然，沒有人聲稱微服務解決得了所有問題。但是微服務架構可能會在其他基于服務的解決方案失敗的地方取得成功，因為它是自下而上出現的。開發人員確定服務類型和服務的細粒度；隨著這股趨勢波及到大企業，開發團隊就能夠決定哪些服務對整個企業而言是同類中***的服務。

如果使用過去的硬連線基礎設施，不可能實現這種臨時擴建（ad hoc build-out）。同樣重要的是，開發人員在協作方面已大有改進，文化的轉變有助于自然有序地構建軟件架構，而不是遵守從上面下達的命令和規定。

據我所聞，許多企業的開發人員已經在采用微服務架構，無論管理層知情還是不知情。借助合適的云基礎設施，無論是公有云還是私有云， 微服務架構不僅能夠提高開發人員的工作效率，還能幫助開發人員開發出以往不可能構建的新型應用程序。

英文原文：Why 2015 will be the year of microservices

布加迪編譯