建站
咨詢
售后
建站咨詢
新聞中心
云計算 在行業(yè)中，微服務(wù)有著眾多不同的定義。某些定義認為它是一種和Unix編程風(fēng)格類似，以構(gòu)建很多能夠?qū)Ｗ⒂谧龊靡患虑榈?、微小的、有自治進程的架構(gòu)風(fēng)格。某些定義認為它是第一個后DevOps革命的架構(gòu)。它從DevOps和持續(xù)交付中吸取到所有的經(jīng)驗，并且對其進行了優(yōu)化。
成都創(chuàng)新互聯(lián)于2013年創(chuàng)立，先為王屋等服務(wù)建站，王屋等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為王屋企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
我足夠“高”了么?
Martin Fowler描述過當組織在考慮實現(xiàn)微服務(wù)架構(gòu)時，必須要有的一組“能力基線”，但大企業(yè)通常有各種理由不太愿意去嘗試和成長以達到這樣的能力。有很多的文字都提到，在成長之路完成后便能收獲微服務(wù)架構(gòu)所能帶來的各種好處。這篇文章將描述一個大企業(yè)為達到Martin Fowler的能力基線，所經(jīng)歷的挑戰(zhàn)和決心。
開篇
在行業(yè)中，微服務(wù)有著眾多不同的定義。某些定義認為它是一種和Unix編程風(fēng)格類似，以構(gòu)建很多能夠?qū)Ｗ⒂谧龊靡患虑榈摹⑽⑿〉?、有自治進程的架構(gòu)風(fēng)格。某些定義認為它是***個后DevOps革命的架構(gòu)。它從DevOps和持續(xù)交付中吸取到所有的經(jīng)驗，并且對其進行了優(yōu)化。
我們采用微服務(wù)的初衷是為了提供一種能夠擴大團隊規(guī)模的途徑。我們從一個單體應(yīng)用開始，康威定律啟迪我們分解這個單體應(yīng)用。經(jīng)過這個過程，我們最終變成了很多小而優(yōu)的團隊來進行交付。
團隊的結(jié)構(gòu)影響著系統(tǒng)的架構(gòu)并不是一個新鮮事了。Nygard總結(jié)得很到位——“團隊的工作分配方式就是架構(gòu)的初稿”。這種最初對團隊伸縮性的需求是將一批***實踐帶入微服務(wù)和持續(xù)集成的催化劑。
團隊的工作分配方式就是架構(gòu)的初稿。
拆分單體應(yīng)用
當我們拆分單體應(yīng)用時，我們面臨的***個挑戰(zhàn)是嘗試找到系統(tǒng)的接縫或者界限上下文。這種嘗試帶來了一個非常有意思的副作用，即我們可以通過識別系統(tǒng)中那些比起其他地方更不容易變化的地方，來解耦我們的系統(tǒng)。這和重構(gòu)代碼以讓你的代碼更經(jīng)得起時間的考驗類似，只不過是在架構(gòu)層次上罷了。
從單體應(yīng)用中分割出多個服務(wù)是很不簡單的。包括創(chuàng)建單獨的代碼倉庫，構(gòu)建管道和基礎(chǔ)設(shè)施建設(shè)。這些都要消耗時間。因為很多企業(yè)都對頻繁構(gòu)建新服務(wù)持悲觀的態(tài)度，我們經(jīng)常會聽到猶豫之聲：“如果構(gòu)建一個服務(wù)都用了這么多時間，我們怎么做其他的服務(wù)呢?”
我們是在每個迭代中逐步攻克這個問題的。我們改進我們的構(gòu)建管道、工程的創(chuàng)建、環(huán)境設(shè)置和部署。這是從微服務(wù)架構(gòu)中所獲得的很大一部分益處——它不僅強制性的將質(zhì)量和成熟度構(gòu)建進你的軟件，而且也包含了開發(fā)流程和實踐。
步入云端
在改進DevOps***實踐的路上，配置環(huán)境成了畔腳石。如果需要另一個部門花幾周的時間，去配置好一個新的機器來托管你的新服務(wù)，你就有麻煩了。幸運的是我們已經(jīng)準備好步入云端，并且已經(jīng)在企業(yè)層面上準備好了支持云部署所必須的工具鏈。
即便有這些工具，開發(fā)人員也必須開始擁有他們的軟件，包括生產(chǎn)環(huán)境的部署和支持。封閉的組織有一個趨勢是將他們的開發(fā)人員與真實地生產(chǎn)環(huán)境隔離開。 “誰構(gòu)建，誰擁有”這個思想非常的重要，它能促進***實踐地成熟。亦即，如果開發(fā)人員已經(jīng)對生產(chǎn)環(huán)境的穩(wěn)定性和支持有濃厚的興趣，那么很有可能是他們構(gòu)建了這個系統(tǒng)。
誰構(gòu)建，誰擁有
消費者驅(qū)動的契約測試
我們已經(jīng)擁有了很多已經(jīng)部署到云端的RESTFul API，并且由團隊自己維護這些API。這就意味著團隊可以不借助其他人的力量進行獨立的開發(fā)。不過，我們開始發(fā)現(xiàn)依賴的服務(wù)在逐漸改變我們的行為。測試和利益相關(guān)者開始抱怨系統(tǒng)不穩(wěn)定——但當我們是單體應(yīng)用時這根本不是問題。
我們使用集成測試來解決這個問題。服務(wù)提供者為其API的消費者維護一組測試，而不是消費者自己為契約寫集成測試。這樣做有很多的好處：首先，如果服務(wù)提供者破壞了契約，它會直接被告知;另外，如果消費者增加了新的測試場景，但這個場景破壞了契約，那么構(gòu)建也同樣會失敗。這些考量驅(qū)動出更重要的事情，也即團隊之間的交流以及盡快的開始這些對話。API始終可以進化，但它會有足夠的約束來保證穩(wěn)定性。
蝴蝶效應(yīng)
解耦單體應(yīng)用的另一個副作用是監(jiān)控的工作量成倍增加。之前你可能在一個應(yīng)用中只有一個終端(endpoint)，而現(xiàn)在你有很多的服務(wù)。為了更好地保證應(yīng)用正常工作，你必須要為支撐你的服務(wù)的基礎(chǔ)設(shè)置上提供足夠的監(jiān)控。
在單體應(yīng)用中，如果一個服務(wù)調(diào)用失敗了，我們會清楚地知道哪里出錯了。但在一個經(jīng)常變化的解耦架構(gòu)中不再成立。當一個服務(wù)失敗了，真實的失敗位置可能是在依賴樹上的數(shù)個服務(wù)。這就意味著平均修復(fù)時間(MTTR)會受影響——我們必須要調(diào)查受影響的服務(wù)，也會調(diào)查這個服務(wù)所有的依賴。我們使用PRTG監(jiān)控工具來解決這個問題。PRTG給我們提供了一個高級的儀表盤(dashboard)來圖形化系統(tǒng)的不同的部件。
我們發(fā)現(xiàn)的另外一種必要地監(jiān)控是分布式的日志收集。這允許我們從不同的服務(wù)器收集日志并且可以做聯(lián)合查詢。我們甚至可以引入相關(guān)性ID來改進它。這樣分布式的日志允許我們跟蹤一個請求的在系統(tǒng)的不同服務(wù)中的跳轉(zhuǎn)過程。
展望
當然我們還有一些需要在未來解決的困難問題。包括一些棘手的組織變化，例如將交付與產(chǎn)品對齊而不是和工程對齊，并且使開發(fā)人員能夠在DevOps的環(huán)境中工作。這也包含了更多的環(huán)境配置，包括更多的通過Ansible來進行基礎(chǔ)設(shè)施自動化。盡管還有未來的挑戰(zhàn)，我們已經(jīng)開始收獲一些引入微服務(wù)先決條件所帶來的好處了。你的微服務(wù)的旅程是怎樣的呢?
原文鏈接：http://insights.thoughtworkers.org/microservices-how-large-enterprise-grew-doing-it/
本文名稱：大企業(yè)是如何在實踐微服務(wù)中成長的
文章起源：http://www.5511xx.com/article/cogjpig.html
