微服務架構成功之路

標籤：

本文來源於我在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的觀點是一致的。

很多Team Dev認為微服務架構風格要比單體架構更加優秀。不過，還有一些團隊認為微服務會導致生產力的降低。就像其他任何架構風格一樣，微服務也會帶來成本和收益。要想做出明智的選擇，你需要對其有清晰、透徹的理解，然後將其應用到具體的上下文中。

微服務帶來的好處有：

• 明確的模組邊界：微服務強化了模組化結構，這對於大型系統來說尤為重要。
• 獨立部署：簡單的服務很容易部署，由於是自治的，因此當某個模組本身出現問題時一般不會導致系統崩潰。
• 技術多樣性：藉助於微服務，你可以混合使用多種語言、開發架構和資料存放區技術。

微服務的代價有：

• 分布式：分布式系統難以編寫，遠程調用會慢一些，並且總是存在著失敗的風險。
• 最終一致性：對於一個分布式系統來說，保持強一致性是非常困難的事情，這意味著每個組件都需要管理最終一致性。
• 營運複雜性：你需要一個成熟的營運團隊來管理大量的服務，而這些服務部署的頻率可能會很高。

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

真正的成功？

微服務架構真正的成功之處在於組織該如何擁抱小型、跨職能團隊，並且鼓勵扁平、自我管理的組織，他們可以以傳統組織圖無法匹敵的速度進行創新，並且快速成功。

兩披薩團隊

我曾經有幸與Amazon團隊一同工作，從而瞭解到了他們的組織文化。Amazon的一個規定是組織團隊必須要遵循“兩批薩”原則。簡單來說就是一個團隊的成員有兩個披薩就能吃飽了。這背後的想法可以通過Amazon CEO Jeff Bezos的話總結為：

管理者：我們需要保持團隊間更多的溝通和交流。

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

要想打造並保持自治、創新性的團隊，你不需要“更多的溝通”，你需要的是“有效溝通”。說起來容易做起來難，不過首先我們就需要確保團隊的人數要足夠少。這樣，團隊成員之間就能更好地瞭解彼此，他們會形成良好的人際關係、保持信任和動力。J Richard Hackman研究了團隊與集體動態，發現成員之間的溝通鏈會隨著團隊成員的增加而增加。

跨職能

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

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

建立更多的職能部門會產生“鼓勵壞行為”的結果。比如說，開發人員應該關注於編寫並交付高品質代碼這件事。他們還應該考慮非功能方面，如安全、效能、延展性、高可用等等。不過，如果開始建立應用程式資料庫團隊、QA團隊，或是單獨的營運團隊，那麼開發人員就只會關注於“重要的事情”，將其他事情拋給別人。

下面這些話熟悉嗎？

• 我沒時間測試，QA會做的。
• 我無需瞭解資料庫的工作方式，DBA會做的。
• 我只負責寫代碼，營運會搞定高可用的。

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

SOA與微服務

重申一次，我認為我們所聽到的關於微服務的成功故事不一定是技術上的成功，我們實際上冒著抓不住要點的風險，並且可能會重蹈SOA的覆轍。SOA的很多原則都是微服務的基石，不過SOA並沒有走向終點。很多人使用SOA的原因就是為了用而用；廠商、委員會與協會一起過來告訴我們什麼是我們“需要”的。最終，SOA也提出了關於組織圖的相同目標，不過卻迷失在了WS-*規範中。

開源社區

仔細想想，你會發現這些小型、跨職能的微服務團隊看起來像是小型開源項目一樣。大家一起工作，不怕與別人分享自己的觀點；每個人都熱衷於構建高品質軟體，由於團隊規模足夠小並且聚焦，因此可以構建出模組化軟體。他們是開發人員、測試、營運，一切工作都有著相同的目標，而這正是DevOps與微服務的真諦之所在。

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

微服務架構成功之路