我足夠“高”了么?

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

開篇

在行業(yè)中，微服務(wù)有著眾多不同的定義。某些定義認(rèn)為它是一種和Unix編程風(fēng)格類似，以構(gòu)建很多能夠?qū)Ｗ⒂谧龊靡患虑榈?、微小的、有自治進(jìn)程的架構(gòu)風(fēng)格。某些定義認(rèn)為它是***個(gè)后DevOps革命的架構(gòu)。它從DevOps和持續(xù)交付中吸取到所有的經(jīng)驗(yàn)，并且對其進(jìn)行了優(yōu)化。

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

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

團(tuán)隊(duì)的工作分配方式就是架構(gòu)的初稿。

拆分單體應(yīng)用

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

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

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

步入云端

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

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

誰構(gòu)建，誰擁有

消費(fèi)者驅(qū)動的契約測試

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

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

蝴蝶效應(yīng)

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

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

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

展望

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

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