技術雷達之微服務架構

文/王健

最近幾年，微服務架構異軍突起，與容器技術相輔相成，成為架構設計領域熱議的話題。而《技術雷達》作為ThoughtWorks出品的一份關於技術趨勢的報告，在技術社區也一直有著非常好的口碑。本篇文章就試圖結合技術雷達與微服務架構，以往期技術雷達中微服務架構的演變來審視一下這個新興架構的整個發展過程。

相信大家了解微服務架構或者聽說微服務架構也都是近兩年的事情，從Google Trends的搜索數據統計上看，微服務架構確實也是從2014年才逐漸興起，到目前呈現出一個爆發的趨勢。

但技術雷達在2012年的3月份就已經提及了微服務架構相關的內容，在當時，其所處的狀態還是評估（Assess）階段，這就說明技術雷達早在2012年初的時候就已經成功捕獲到微服務架構這個新的技術架構。

（微服務2012年第一次出現在技術雷達上）

到底什麼才是微服務架構，Martin Fowler在那篇著名的描述微服務架構的文章中第一次定義了微服務架構並闡述了其九大特性。而我一開始接觸微服務架構的時候也覺得這好像不是一個新的概念，很早之前就有RPC和SOA這種面向服務的分散式架構，又冒出一個新的微服務架構，他們到底有什麼區別？

看到Martin Fowler的定義以後，才慢慢清楚他們的區別，在Martin Fowler的定義中有幾個關鍵字可以讓我們甄別一個分散式架構是傳統的面向服務架構還是新的微服務架構：每個服務是不是跑在獨立的進程中？是不是採用輕量級的通訊機制？是不是可以做到獨立的部署？

(微服務架構的定義)

時間來到了2012年的10月份，在這期的技術雷達中，微服務架構已經從評估（Assess）階段被移到實驗（Trial）階段。什麼叫實驗階段？ThoughtWorks內部有一個解釋，就是這項技術已經可以運用在實際項目中，但你仍要控制風險，也就是說此項技術已經可以在風險比較低的項目中使用了。

一個項目要能被移到試驗的階段，還有一個必須要滿足的條件，就是必須在ThoughtWorks自己的項目中已經開始實際使用。幸運的是，我當時所在的項目也是在2012年10月份左右開始採用微服務架構的，結果也是非常好的。我們在3個月完成一個新的應用並成功上線，當時客戶評價很高。

實際體驗下來，微服務架構對我們究竟有哪些好處？這幾點是我體會到的：

首先是組件化，作為一個軟體開發人員，我們一直都有一個夢想，就是希望有朝一日可以把一堆組件像樂高一樣通過直接拼裝的方式快速構建我們的應用。無論是最早基於拖拽的方式構建應用，還是現在大熱的前端組件化，我們一直都在試圖尋找一種更好的組件化方式，微服務架構也是其中之一。但構建軟體本身仍是一個非常複雜的過程，微服務架構為我們提供了一種組件化的可能，但直到現在還不好說它能不能達到我們作為整體組件化的目標，但是至少從實際體驗來看，它確實能給我們帶來組件化的很多好處。

然後是彈性架構，在2015年11月期技術雷達中推薦了亞馬遜的彈性計算平台，如果我們的系統是由按業務劃分的服務構成，結合容器技術和雲平台我們就可以構建一個極具彈性的架構。通過雲平台實時的監控，一旦發現資源緊張，立刻就可以通過雲平台和容器技術自動瞬間擴展出成百上千的服務資源，在高峰過去之後又可以立即把所有的服務註銷掉，釋放資源，整個過程完全是自動化的。

n

去中心化和快速響應也是微服務架構給我們帶來的好處。在單體架構下，會非常依賴於項目一開始時對於技術選擇，一旦選擇了一個技術棧，那麼之後幾年都被綁定在了這樣一個技術棧下，很難應對變化。微服務架構則給我們提供了一個更細粒度使用技術的可能，在不同的服務里可以使用完全不同的技術棧，不同的語言、框架甚至資料庫，真正做到用最適合的技術解決最適合的問題，從而讓我們可以更加敏捷地響應需求和市場的變化，增加了競爭力。

(微服務架構的好處)

從2012年10月份一直到2014年的7月份，在這個時間段有大量與微服務架構相關的工具、技術和框架出現在技術雷達上。包含了很多領域：語言、測試，框架、CI、CD、持續交付，安全等等。

從2012年的3月份微服務架構第一次出現在技術雷達上一直到2014年7月份，雖然微服務架構已經有了比較大的發展，技術雷達上也已經推薦了大量相關的內容，但在當時社區中談論微服務架構的聲音並不多，這也體現出了技術雷達的前瞻性。

技術雷達上微服務架構相關項目

從2014年7月份開始微服務在社區就開始呈現出一種爆發的趨勢，但在緊接著的2015年1月刊的技術雷達中卻出現一個非常有意思的項目：Microservice Envy。通俗點兒講就是「微服務紅眼病」，或者說是「微服務你有我也要」。

這意味著在社區剛剛爆發，對於微服務架構踩下油門的時候，我們已經踩下了一腳剎車。但這並不是代表我們不看好微服務架構，而是認為需要認真思考我們是否真正需要以及何時以何種方式使用微服務架構，不能看別的人都在使用也盲目切換到微服務架構下。

這是因為微服務架構並不是免費的午餐，使用微服務架構是需要門檻和成本的。我們需要問自己：用微服務我們夠「個」嗎？或是說用微服務我們夠「格」么？我們是否有這個能力和足夠的資源駕馭這個新的架構？

n

Martin Fowler在他的《企業應用架構模式》中，就提到了分散式對象設計的第一原則：「設計分散式對象的第一個原則就是不要使用分散式對象」。因為分散式系統會給我們帶來很大的挑戰，讓系統複雜度大幅增加的同時，我們還需要面對開發環境、測試、部署、運維、監控，一致性和事務等一系列的問題。?

(Microservice Envy)

所以說，微服務架構雖然看起來非常美好，但是也是有很大附加成本的。通過下面這張圖可以看到，橫軸是時間軸，縱軸是生產力。

當軟體的複雜度很低的時候，單體架構下的生產力是要高於微服務架構的，但隨著複雜度的不斷增加，無論是單體應用還是微服務應用的生產力都會下降，只是微服務架構的下降會相對緩慢一些。

這也容易理解，因為在微服務架構中，我們的系統是由很多的小的服務組成，每一個服務都很小，相對簡單，技術棧也很獨立。這樣做局部的變更也會更加容易，隨著系統複雜度的不斷增加，微服務的優勢也就慢慢地體現出來了。

那要如何應對呢？為了追求生產力的最大化，一開始我們可以選擇從一個單體架構開始，然後爭取在微服務架構生產力超越單體架構的那個複雜度點切換到微服務架構上來，這樣才能實現生產力的最大化。這就是Martin Fowler提出的單體應用優先原則（MonolithFirst），以單體架構開始，通過演進式設計逐漸重構到微服務架構。

(MonolithFirst)

n

為了保證從單體架構演進到微服務架構的重構過程安全可控，還需要有一套良好的質量守護機制。下圖描述的就是Martin Fowler提出的微服務架構下的測試策略，我所在項目就是按照這種方式來劃分和設計我們各種不同類型的測試，幫助我們在對於服務的抽取合併分離的重構過程中做到安全可控。

(Testing Strategies in a Microservice Architecture)

我們剛才提到了康威定律，康威定律說的是設計系統的組織產生的設計和架構等價於組織間的溝通結構。而康威定律還有一個逆定律：如果想改變一個設計架構方式，首先要改變組織結構。我們經常發現推動技術架構的轉型和演進很難，因為我們在調整技術架構的同時卻忽略了組織結構也要對應做相應的調整以匹配技術架構的變化，當組織結構與技術架構不匹配的時候，就會相互拉扯，這些都是在當時的技術雷達中著重強調的。

截至目前，以上內容都還是在談論2015年以前各期技術雷達里的內容。在這之後直到現在，技術雷達也還在持續地推薦微服務架構相關的內容。所以說踩下剎車並不是因為我們走錯了路，只是走的太快了，需要時刻提醒自己不要盲目，要清楚微服務給我們帶來了什麼和有著什麼樣的挑戰，最終解決我們的問題。

來到最新的幾期技術雷達，微服務架構還在不斷的演進，而且慢慢的與其他新興的技術融合形成一整套的新的不同以往的構建軟體的解決方案。例如無伺服器架構、對Docker的應用、對PaaS各種雲的應用等，這些技術的發展，會不會對微服務架構的演進提供更多可能？是否可以為微服務架構早一天落地、改變我們的開發方式提供可能？讓我們大家一起拭目以待。

更多精彩洞見，請關注微信公眾號：思特沃克

推薦閱讀：