在Dublin微服務用戶組的一次活動中，Christian Deger進行了一場名為“通往天堂之路：在云端構建微服務”的演講，講述了AutoScout24是如何從使用典型的IT開發流程在一個一體化的應用中部署代碼的方式，轉變為由跨職能的團隊構建與部署微服務架構的歷程。這種技術與組織上的轉變讓業務組織能夠更快速地應對不斷變化的市場情況。

InfoQ最近與來自AutoScout24的一位架構師Deger進行了一次訪談，Deger回答了一些流程方面的問題，以及在啟動這種大規模流程轉變時所遇到的各種挑戰。Deger向采訪者分享了在組織里驅動這一轉變過程的動力以及相關技術，談到了過程中所必需的計劃工作，并且對于Linux、Scala及AWS這些技術選擇提出了他的見解。

InfoQ：歡迎你Christian！能否請你進行一下自我介紹，以及你近期所做的有關微服務的演講“通往天堂之路”背后的核心思想？

Deger：在5年以前，我作為一名.NET軟件開發者加入了AutoScout24，因此我對之前所采用的技術棧的運作方式有所了解，組織對我們當時的技術選擇十分支持。2014年初，新的CEO Greg Ellis上任了，他對于我們所采用的Windows .NET技術棧未來的前景提出了質疑。當時我正負責一個開發團隊的領導工作，但這次轉型的目的是使我們已成熟的IT技術轉為次世代的“web規模”的IT平臺，這中間所面臨的挑戰吸引我開始研究架構師這一角色中更偏重技術的一面。

我們在2014年11月啟動了Tatsu項目，當時僅有1個團隊參與，自那之后，這個轉型項目的規模逐漸擴大到了8個團隊。Tatsu（竜）這個單詞起源于日語，是傳說中一種會飛的動物。在加州某處有一個過山車也與此同名，它很形象地詮釋了我們在這次轉變過程中的體驗。就像乘坐真正的過山車一樣，你最好能夠緊緊抓住某樣東西。對于我們來說，這樣東西就是我們所提出、并且在不斷演變的一系列原則。這些原則能夠作為我們的討論的指導意見，并使我們的方向保持一致。因此，這次演講的核心內容是我們所選擇的途徑、堅守的原則以及所學到的經驗。

InfoQ：AutoScout24從一體化架構轉變為微服務架構，這聽起來是一個規模很大的項目，你們對此進行了哪些前期計劃工作？

Deger：對于AutoScout24來說，這確實是一個很大的項目，但我們并不相信大量的前期設計這種方式。我們當然會在產品的能力與預算的計劃方面保持應有的審慎。但對于我們來說，更重要的一點在于進行一系列合理的初期決策。AWS與Linux是很明顯的選擇，而JVM與Scala的選擇則不是那么容易確定的。但對于我們所具備的.NET經驗來說，這看起來應該是一個良好的起點。工程師之間對編程語言的討論是無法避免的，在AutoScout24選擇Scala時也產生了激烈的爭論。另外我們還打算采用微服務架構，這讓我們能夠容納更多的不同技術，這一決定也起到了很大的作用。

隨后，我們就四處尋找一些合作伙伴，希望能夠在這些領域為我們提供一些支持與指導。最終，我們決定對一個功能進行重寫，以實現我們第一個微服務。在第一個團隊投入開發工作之后，其他人將學習他們的經驗，并且應用到其他功能的實現過程中。

InfoQ：我們還注意到一點，你前面提到除了轉向微服務架構之外，你們還選擇了將系統遷移至云平臺，并從.NET/Windows平臺轉為JVM/Linux環境。事后看來，你是否也會建議其他組織進行這種方式的轉換呢？

Deger：對我們來說，整個轉換項目及其核心決策就是一塊塊拼圖，他們能夠完美地結合在一起。我們當然也可以選擇以更小的步伐完成這次轉變，但這將使我們失去這一機會。我們很了解這個行業，下一波挑戰正在到來。因此，即使是讓我重來一次，我也會不對核心決策進行任何改動。

雖然整個轉變過程是同時啟動的，但我們還是決定盡量減少對于組織帶來的影響。我們先從一個團隊開始嘗試，并且極力強調向他人取經的思想。每兩至三個月，就會有新的團隊加入其中，項目中包括資深工程師與新手。這一過程對于早期加入的各個團隊非常有效，但我們也學到一點，即你必須知道何時停止對團隊進行分解的過程。當相互學習的階段結束、并且項目的交付需要更多的關注時，我們必須讓團隊保持穩定。

從技術角度來說，我們都還有許多JVM或Linux的知識要學習，但我們已經成功地實現了全部自動化。我們的整個基礎設施都由代碼管理，包括不可變的服務器。我從來沒有聽說團隊中有哪位工程師更愿意通過Windows技術棧解決這些問題。

InfoQ：你們的項目只包括“開發”與“生產”環境的構建，而沒有搭建一個預發布環境，你能否對這一點詳細地說明一下嗎？

Deger：當我剛加入AutoScout24時，一共有3個預發布環境與1個生產環境。當時讓每個發布候選通過所有預發布流程始終是一件令人頭疼的事，因為這些環境與生產環境有著不同的配置。此外，這些預發布環境的“安全網”并不能夠始終保證不會在生產環境中出錯，因為這些環境中的數據、負載量與模式與生產環境都是不一致的。

不僅如此，在獨立地發布服務時，一個運行著所有服務的預發布環境還帶來了另一個問題，即與你集成的其他服務的版本與生產環境中有所不同。這些外部服務或許正處于交付周期的未完成階段。既然如何，何必自找麻煩去配置一套預發布環境呢？為什么不讓事情簡單一點，只配置一個環境，讓所有服務在該環境中都可用不就解決了嗎？

我們希望能夠“更大膽些”，但并不是說要犯傻，因此我們進行了大量的調查研究，以了解如何才能放心地將代碼直接部署至生產環境。在過程中我們經歷了一些失誤，服務本身可能會出錯，新的特性也可能不像預期中的方式運行，服務之間的集成也可能會出錯。

• 我們采取了動態特性開關策略，它幫助我們實現代碼部署與特性發布的分解，這使我們對于新特性的發布實現了完全控制。我們在過去兩年多時間內構建了自己的工具，名為FeatureBee（https://github.com/AutoScout24/FeatureBee），用于金絲雀發布、A/B測試以及驗收測試。舉例來說，AutoScout24的每位員工都可以通過Chrome擴展自行開啟一個新特性。就在最近，Pete Hodgson在Marin Fowler的網站中解釋了這一概念：http://martinfowler.com/articles/feature-toggles.html
• 客戶驅動契約（CDC）能夠幫助我們驗證某個服務是否破壞了與正在生產環境中所運行的版本的服務之間的契約。服務可以在自己的發布管道中運行由使用者提供的契約測試，而無需與已發布的服務進行集成。我們目前正在將這些測試遷移至Pact（https://github.com/realestate-com-au/pact）。
• 我們為會新服務應用Shadow Traffic，這讓我們得以在正式發布之前消除所有性能問題。但我們在一開始應用此方法時效果并不好，因為某些服務沒有包含在最初的發布中，而他們又會對狀態進行變更。因此，我們的方法是在實例級別結合使用金絲雀發布與shadow
  traffic。出于這一原因，我們需要為在金絲雀發布階段寫入的數據進行標記，以用于生產環境。

InfoQ：在整個遷移過程中，對于所必須的技術變革來說，打造“自治的”團隊具有怎樣的重要性？

Deger：對于我們來說，打造自治的團隊非常重要，因為我們相信自治的團隊能夠實現組織的伸縮性，同時保證團隊的效率。一個具有自由度與責任感的文化是非常強大的工具。

我們之前的團隊就已經實現了某種程度上的跨職能性，所缺乏的部分主要是仍然要將部署工作移交給運維團隊。因此，我們嘗試將原先的運維人員吸引到我們的產品團隊中，讓整個團隊對服務的運行與改進負責。最終誕生了我們的座右銘：“我們現在都是工程師”。

盡管如此，我們仍需要密切留意團隊中的各種“T型人才”是怎樣為整個產品功能的做出貢獻的，人們很可能會時不時地產生松懈倒退的表現。如果將有關基礎設施的用戶故事都分配給來自運維背景的工程師，他們就會成為團隊中的“單點故障”。我們必須確保“誰創建的東西，就由誰負責運行”思想中的“誰”代表的是整個團隊。從另一方面來說，許多開發者借此機會拓展了他們的技能，這是我們所樂于看到的。

InfoQ：我對于本次演講中所提到的“原則”這一部分非常感興趣。在這些遷移過程中，你與你的團隊所學到的最重要的原則（或者是一系列原則）是什么？

Deger：我們圍繞著“無共享”這一原則展開了各種有價值的討論。當然，系統中一定會共享某些內容，因此對于該原則總是需要進一步解釋。顯然，共享的行為應當成為一個服務，而多個服務不應使用共享的數據存儲源。這一原則的重要性在于它改變了我們原本所有的思想。我們以前所學到的知識總是教育我們要保持DRY，或是進行標準化。大批工程師都希望能夠創建一個共享的庫。但共享的庫會使服務對這種特定的實現以及底層平臺產生耦合。我們的目標不是對于它的效率進行優化，而是為了加快前進步伐。

舉例來說，我們在系統中共享了一個統一的日志記錄基礎設施。這是一種宏觀的需求，因為我們需要對于來自所有服務的事件進行關聯。除了基礎設施之外，事件的數據契約也是共享的。但是事件發布功能的最初實現則并非共享的，因為人們對于直接拷貝單一的類這一做法有很強烈的反對意見。很快，團隊就可以在無需協作的情況下對于自己的實現版本按照自身需求進行改進了。在經過好幾個月之后，整個實現終于穩定下來了。我們最終決定構建一個內部的OSS庫，在其中包含所有改進內容。新的團隊可以自己決定如何使用這個庫。

另一個例子是我們的儀表板服務。第一個團隊搭建了一個儀表板服務器，而第二個團隊在同一個實例中添加了另一個儀表板。但兩個團隊在訪問某個指標的時候，無意中使用了服務中的同一個全局狀態。我們在兩天后才發現了這一問題，因為我們觀察到這兩個儀表板中的數值每5分鐘就會切換一次。這是一個關于耦合方面的糟糕例子。現在，每個團隊都自己運行一個儀表板服務器。

第二個原則的爭議較少，但非常實用，即AWS優先：“AWS平臺服務勝于托管服務、自運行OSS以及自展開的解決方案。”我們需要決定在組織的技術棧中引入哪種平臺服務，因此我們提醒自己，我們的目標是利用AWS的托管服務。因為我們希望避免那些繁重的負擔，而專注于自身的領域并加快腳步。雖然我們有時仍然可以選擇其他的方案，但必須要給出充分的理由。

在YouTube上可以找到“通往天堂之路：在云端構建微服務”這個演講的視頻，也可以在Deger的SlideShare帳號中下載對應的幻燈片。

查看英文原文：AutoScout24’s Journey to Microservices: Christian Deger on Transformation, Principles and Technology