本文來源于我在InfoQ中文站翻譯的文章，原文地址是：http://www.infoq.com/cn/news/2015/07/success-of-microservices

近年來，在軟件開發領域關于微服務的討論呈現出火爆的局面，有人傾向于在系統設計與開發中採用微服務方式實現軟件系統的松耦合、跨部門開發；同一時候，反對之聲也非常強烈，持反對觀點的人表示微服務添加了系統維護、部署的難度，導致一些功能模塊或代碼無法復用。同一時候微服務同意使用不同的語言和框架來開發各個系統模塊。這又會添加系統集成與測試的難度，而且隨著系統規模的日漸增長，微服務在一定程度上也會導致系統變得越來越復雜。

雖然一些公司已經在生產系統中採用了微服務架構，而且取得了良好的效果。但很多其它公司還是處在觀望的態度。

Christian Posta是Red Hat的中間件專家與架構師、開源愛好者。同一時候也是Apache ActiveMQ、Apache Camel、Fabric8、HawtIO等諸多項目的提交者。

近日。Posta撰文談到了微服務架構的一些成功故事，揭示出微服務架構成功的內在表現。同一時候還談到了對成功的微服務架構的理解。

我們都非常清晰微服務架構所帶來的優點，非常多人也建議我們為何以及怎樣要採用微服務。同一時候。我們也知道諸如Amazon、Netflix以及Gilt等公司成功應用微服務架構的故事。

只是，就像我之前在文章You’re not going to do microservices中所談及的那樣。正確使用微服務，而且讓公司或組織成功實施微服務是一件非常困難的事情。決定使用Dropwizard/SpringBoot/WildflySwarm/Docker并不意味著你就在使用微服務，能夠說二者之間并沒有什么直接的關系。其實。過早地將應用或服務拆分為更加小型的服務是須要採取一種折衷的辦法的。在這一點上，我與Martin Fowler的觀點是一致的。

非常多開發團隊覺得微服務架構風格要比單體架構更加優秀。只是，另一些團隊覺得微服務會導致生產力的減少。就像其它不論什么架構風格一樣，微服務也會帶來成本和收益。要想做出明智的選擇。你須要對其有清晰、透徹的理解，然后將其應用到詳細的上下文中。

微服務帶來的優點有：

• 明白的模塊邊界：微服務強化了模塊化結構。這對于大型系統來說尤為重要。

• 獨立部署：簡單的服務非常easy部署，因為是自治的，因此當某個模塊本身出現故障時一般不會導致系統崩潰。
• 技術多樣性：借助于微服務。你能夠混合使用多種語言、開發框架和數據存儲技術。

微服務的代價有：

• 分布式：分布式系統難以編寫，遠程調用會慢一些，而且總是存在著失敗的風險。

• 終于一致性：對于一個分布式系統來說，保持強一致性是非常困難的事情。這意味著每一個組件都須要管理終于一致性。
• 運維復雜性：你須要一個成熟的運維團隊來管理大量的服務，而這些服務部署的頻率可能會非常高。

因此，當我們在一些業界大會上，在開發人員博客上談論微服務的成功故事時。我覺得我們并沒有抓住要點。是否成功與採用了什么依賴管理器、類載入器結構、Linux容器或是云服務并沒有直接的關系。而是與一些更加基礎、與Docker/Kubernetes/SpringBoot相比不那么潮的東西有關。

真正的成功？

微服務架構真正的成功之處在于組織該怎樣擁抱小型、跨職能團隊，而且鼓舞扁平、自我管理的組織，他們能夠以傳統組織結構無法匹敵的速度進行創新，而且高速成功。

兩披薩團隊

我以前有幸與Amazon團隊一同工作，從而了解到了他們的組織文化。

Amazon的一個規定是組織團隊必須要遵循“兩批薩”原則。簡單來說就是一個團隊的成員有兩個披薩就能吃飽了。這背后的想法能夠通過Amazon CEO Jeff Bezos的話總結為：

管理者：我們須要保持團隊間很多其它的溝通和交流。

Bezos：不，溝通是件非常糟糕的事情。

要想打造并保持自治、創新性的團隊，你不須要“很多其它的溝通”，你須要的是“有效的溝通”。

說起來easy做起來難，只是首先我們就須要確保團隊的人數要足夠少。這樣，團隊成員之間就能更好地了解彼此。他們會形成良好的人際關系、保持信任和動力。J Richard Hackman研究了團隊與集體動態，發現成員之間的溝通鏈會隨著團隊成員的添加而添加。

跨職能

我覺得以下這句話能夠非常好地說明為何一個團隊應該是跨職能的：

當將人們從一系列行為動作中分離開來時，壞行為就出現了。

創建很多其它的職能部門會產生“鼓舞壞行為”的結果。

比方說。開發人員應該關注于編寫并交付高質量代碼這件事。他們還應該考慮非功能方面，如安全、性能、可伸縮性、高可用等等。只是，假設開始創建應用數據庫團隊、QA團隊，或是單獨的運維團隊，那么開發人員就僅僅會關注于“重要的事情”，將其它事情拋給別人。

以下這些話熟悉嗎？

• 我沒時間測試，QA會做的。
• 我無需了解數據庫的工作方式，DBA會做的。
• 我僅僅負責寫代碼，運維會搞定高可用的。

與上面做法相反的是形成跨職能團隊：讓一個團隊的人搞定數據庫、運維和測試等工作。或是讓一個人擔任多個角色。這正是當下非常多互聯網公司的做法，如Amazon、Netflix、Facebook和Google等。通過這樣的方式，你就會負責團隊的一切事情，沒有機會將事情拋給別人去做。

SOA與微服務

重申一次。我覺得我們所聽到的關于微服務的成功故事不一定是技術上的成功。我們實際上冒著抓不住要點的風險。而且可能會重蹈SOA的覆轍。SOA的非常多原則都是微服務的基石，只是SOA并沒有走向終點。非常多人使用SOA的原因就是為了用而用。廠商、委員會與協會一起過來告訴我們什么是我們“須要”的。終于。SOA也提出了關于組織結構的同樣目標。只是卻迷失在了WS-*規范中。

開源社區

細致想想，你會發現這些小型、跨職能的微服務團隊看起來像是小型開源項目一樣。

大家一起工作。不怕與別人分享自己的觀點；每一個人都熱衷于構建高質量軟件，因為團隊規模足夠小而且聚焦，因此能夠構建出模塊化軟件。他們是開發人員、測試、運維，一切工作都有著同樣的目標，而這正是DevOps與微服務的真諦之所在。

親愛的InfoQ讀者，你對于近幾年來火熱的微服務討論有何看法，你覺得在當下所從事的項目中有必要採用微服務架構么？採用微服務架構會對當前的開發、測試與運維帶來那些變化，歡迎寫下你的觀點與大家一同交流。

總結

以上是生活随笔為你收集整理的微服务架构成功之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。