我足夠“高”了么?

Martin Fowler描述過當組織在考慮實現微服務架構時，必須要有的一組“能力基線”，但大企業(yè)通常有各種理由不太愿意去嘗試和成長以達到這樣的能力。有很多的文字都提到，在成長之路完成后便能收獲微服務架構所能帶來的各種好處。這篇文章將描述一個大企業(yè)為達到Martin Fowler的能力基線，所經歷的挑戰(zhàn)和決心。

開篇

在行業(yè)中，微服務有著眾多不同的定義。某些定義認為它是一種和Unix編程風格類似，以構建很多能夠專注于做好一件事情的、微小的、有自治進程的架構風格。某些定義認為它是***個后DevOps革命的架構。它從DevOps和持續(xù)交付中吸取到所有的經驗，并且對其進行了優(yōu)化。

我們采用微服務的初衷是為了提供一種能夠擴大團隊規(guī)模的途徑。我們從一個單體應用開始，康威定律啟迪我們分解這個單體應用。經過這個過程，我們最終變成了很多小而優(yōu)的團隊來進行交付。

團隊的結構影響著系統(tǒng)的架構并不是一個新鮮事了。Nygard總結得很到位——“團隊的工作分配方式就是架構的初稿”。這種最初對團隊伸縮性的需求是將一批***實踐帶入微服務和持續(xù)集成的催化劑。

團隊的工作分配方式就是架構的初稿。

拆分單體應用

當我們拆分單體應用時，我們面臨的***個挑戰(zhàn)是嘗試找到系統(tǒng)的接縫或者界限上下文。這種嘗試帶來了一個非常有意思的副作用，即我們可以通過識別系統(tǒng)中那些比起其他地方更不容易變化的地方，來解耦我們的系統(tǒng)。這和重構代碼以讓你的代碼更經得起時間的考驗類似，只不過是在架構層次上罷了。

從單體應用中分割出多個服務是很不簡單的。包括創(chuàng)建單獨的代碼倉庫，構建管道和基礎設施建設。這些都要消耗時間。因為很多企業(yè)都對頻繁構建新服務持悲觀的態(tài)度，我們經常會聽到猶豫之聲：“如果構建一個服務都用了這么多時間，我們怎么做其他的服務呢?”

我們是在每個迭代中逐步攻克這個問題的。我們改進我們的構建管道、工程的創(chuàng)建、環(huán)境設置和部署。這是從微服務架構中所獲得的很大一部分益處——它不僅強制性的將質量和成熟度構建進你的軟件，而且也包含了開發(fā)流程和實踐。

步入云端

在改進DevOps***實踐的路上，配置環(huán)境成了畔腳石。如果需要另一個部門花幾周的時間，去配置好一個新的機器來托管你的新服務，你就有麻煩了。幸運的是我們已經準備好步入云端，并且已經在企業(yè)層面上準備好了支持云部署所必須的工具鏈。

即便有這些工具，開發(fā)人員也必須開始擁有他們的軟件，包括生產環(huán)境的部署和支持。封閉的組織有一個趨勢是將他們的開發(fā)人員與真實地生產環(huán)境隔離開。 “誰構建，誰擁有”這個思想非常的重要，它能促進***實踐地成熟。亦即，如果開發(fā)人員已經對生產環(huán)境的穩(wěn)定性和支持有濃厚的興趣，那么很有可能是他們構建了這個系統(tǒng)。

誰構建，誰擁有

消費者驅動的契約測試

我們已經擁有了很多已經部署到云端的RESTFul API，并且由團隊自己維護這些API。這就意味著團隊可以不借助其他人的力量進行獨立的開發(fā)。不過，我們開始發(fā)現依賴的服務在逐漸改變我們的行為。測試和利益相關者開始抱怨系統(tǒng)不穩(wěn)定——但當我們是單體應用時這根本不是問題。

我們使用集成測試來解決這個問題。服務提供者為其API的消費者維護一組測試，而不是消費者自己為契約寫集成測試。這樣做有很多的好處：首先，如果服務提供者破壞了契約，它會直接被告知;另外，如果消費者增加了新的測試場景，但這個場景破壞了契約，那么構建也同樣會失敗。這些考量驅動出更重要的事情，也即團隊之間的交流以及盡快的開始這些對話。API始終可以進化，但它會有足夠的約束來保證穩(wěn)定性。

蝴蝶效應

解耦單體應用的另一個副作用是監(jiān)控的工作量成倍增加。之前你可能在一個應用中只有一個終端(endpoint)，而現在你有很多的服務。為了更好地保證應用正常工作，你必須要為支撐你的服務的基礎設置上提供足夠的監(jiān)控。

在單體應用中，如果一個服務調用失敗了，我們會清楚地知道哪里出錯了。但在一個經常變化的解耦架構中不再成立。當一個服務失敗了，真實的失敗位置可能是在依賴樹上的數個服務。這就意味著平均修復時間(MTTR)會受影響——我們必須要調查受影響的服務，也會調查這個服務所有的依賴。我們使用PRTG監(jiān)控工具來解決這個問題。PRTG給我們提供了一個高級的儀表盤(dashboard)來圖形化系統(tǒng)的不同的部件。

我們發(fā)現的另外一種必要地監(jiān)控是分布式的日志收集。這允許我們從不同的服務器收集日志并且可以做聯合查詢。我們甚至可以引入相關性ID來改進它。這樣分布式的日志允許我們跟蹤一個請求的在系統(tǒng)的不同服務中的跳轉過程。

展望

當然我們還有一些需要在未來解決的困難問題。包括一些棘手的組織變化，例如將交付與產品對齊而不是和工程對齊，并且使開發(fā)人員能夠在DevOps的環(huán)境中工作。這也包含了更多的環(huán)境配置，包括更多的通過Ansible來進行基礎設施自動化。盡管還有未來的挑戰(zhàn)，我們已經開始收獲一些引入微服務先決條件所帶來的好處了。你的微服務的旅程是怎樣的呢?

原文鏈接：http://insights.thoughtworkers.org/microservices-how-large-enterprise-grew-doing-it/