微服務架構成功之路
近年來，在軟件開發領域關于微服務的討論呈現出火爆的局面，有人傾向于在系統設計與開發中采用微服務方式實現軟件系統的松耦合、跨部門開發；同 時，反對之聲也很強烈，持反對觀點的人表示微服務增加了系統維護、部署的難度，導致一些功能模塊或代碼無法復用，同時微服務允許使用不同的語言和框架來開 發各個系統模塊，這又會增加系統集成與測試的難度，而且隨著系統規模的日漸增長，微服務在一定程度上也會導致系統變得越來越復雜。盡管一些公司已經在生產 系統中采用了微服務架構，并且取得了良好的效果；但更多公司還是處在觀望的態度。
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的觀點是一致的。
很多開發團隊認為微服務架構風格要比單體架構更加優秀。不過，還有一些團隊認為微服務會導致生產力的降低。就像其他任何架構風格一樣，微服務也會帶來成本和收益。要想做出明智的選擇，你需要對其有清晰、透徹的理解，然后將其應用到具體的上下文中。
微服務帶來的好處有：
- 明確的模塊邊界：微服務強化了模塊化結構，這對于大型系統來說尤為重要。
- 獨立部署：簡單的服務很容易部署，由于是自治的，因此當某個模塊本身出現問題時一般不會導致系統崩潰。
- 技術多樣性：借助于微服務，你可以混合使用多種語言、開發框架和數據存儲技術。 </ul>
- 分布式：分布式系統難以編寫，遠程調用會慢一些，并且總是存在著失敗的風險。
- 最終一致性：對于一個分布式系統來說，保持強一致性是非常困難的事情，這意味著每個組件都需要管理最終一致性。
- 運維復雜性：你需要一個成熟的運維團隊來管理大量的服務，而這些服務部署的頻率可能會很高。 </ul>
- 我沒時間測試，QA會做的。
- 我無需了解數據庫的工作方式，DBA會做的。
- 我只負責寫代碼，運維會搞定高可用的。 </ul>
微服務的代價有：
因此，當我們在一些業界大會上，在開發者博客上談論微服務的成功故事時，我認為我們并沒有抓住要點。是否成功與采用了什么依賴管理器、類加載器 結構、Linux容器或是云服務并沒有直接的關系；而是與一些更加基礎、與Docker/Kubernetes/SpringBoot相比不那么潮的東西 有關。
真正的成功？
微服務架構真正的成功之處在于組織該如何擁抱小型、跨職能團隊，并且鼓勵扁平、自我管理的組織，他們可以以傳統組織結構無法匹敵的速度進行創新，并且快速成功。
兩披薩團隊
我曾經有幸與Amazon團隊一同工作，從而了解到了他們的組織文化。Amazon的一個規定是組織團隊必須要遵循“兩批薩”原則。簡單來說就是一個團隊的成員有兩個披薩就能吃飽了。這背后的想法可以通過Amazon CEO Jeff Bezos的話總結為：
管理者：我們需要保持團隊間更多的溝通和交流。
Bezos：不，溝通是件非常糟糕的事情。
</div>要想打造并保持自治、創新性的團隊，你不需要“更多的溝通”，你需要的是“有效的溝通”。說起來容易做起來難，不過首先我們就需要確保團隊的人 數要足夠少。這樣，團隊成員之間就能更好地了解彼此，他們會形成良好的人際關系、保持信任和動力。J Richard Hackman研究了團隊與集體動態，發現成員之間的溝通鏈會隨著團隊成員的增加而增加。
跨職能
我覺得下面這句話能夠很好地說明為何一個團隊應該是跨職能的：
當將人們從一系列行為動作中分離開來時，壞行為就出現了。
創建更多的職能部門會產生“鼓勵壞行為”的結果。比如說，開發者應該關注于編寫并交付高質量代碼這件事。他們還應該考慮非功能方面，如安全、性 能、可伸縮性、高可用等等。不過，如果開始創建應用數據庫團隊、QA團隊，或是單獨的運維團隊，那么開發者就只會關注于“重要的事情”，將其他事情拋給別 人。
下面這些話熟悉嗎？
與上面做法相反的是形成跨職能團隊：讓一個團隊的人搞定數據庫、運維和測試等工作，或是讓一個人擔任多個角色。這正是當下很多互聯網公司的做 法，如Amazon、Netflix、非死book和Google等。通過這種方式，你就會負責團隊的一切事情，沒有機會將事情拋給別人去做。
SOA與微服務
重申一次，我認為我們所聽到的關于微服務的成功故事不一定是技術上的成功，我們實際上冒著抓不住要點的風險，并且可能會重蹈SOA的覆轍。 SOA的很多原則都是微服務的基石，不過SOA并沒有走向終點。很多人使用SOA的原因就是為了用而用；廠商、委員會與協會一起過來告訴我們什么是我們 “需要”的。最終，SOA也提出了關于組織結構的相同目標，不過卻迷失在了WS-*規范中。
開源社區
仔細想想，你會發現這些小型、跨職能的微服務團隊看起來像是小型開源項目一樣。大家一起工作，不怕與別人分享自己的觀點；每個人都熱衷于構建高 質量軟件，由于團隊規模足夠小并且聚焦，因此可以構建出模塊化軟件。他們是開發者、測試、運維，一切工作都有著相同的目標，而這正是DevOps與微服務 的真諦之所在。
原文 http://www.infoq.com/cn/news/2015/07/success-of-microservices