微服務(wù)的基礎(chǔ)知識點有哪些

本篇內(nèi)容主要講解“微服務(wù)的基礎(chǔ)知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“微服務(wù)的基礎(chǔ)知識點有哪些”吧!

微服務(wù)基礎(chǔ)

我認(rèn)為微服務(wù)作為架構(gòu)由以下因素演進(jìn)而來：

1. 21世紀(jì)初，大量創(chuàng)業(yè)公司使用一門語言像rails，來快速擴(kuò)展他們的業(yè)務(wù)和團(tuán)隊。遇到某些困難后，他們開始思考，可以用一門語言做哪些合理的事情。

2. 云計算的發(fā)展讓我們更便捷、簡單地獲得服務(wù)器實例運行軟件。

3. 我們都認(rèn)可使用分布式系統(tǒng)架構(gòu)，尤其是網(wǎng)絡(luò)調(diào)用來解決問題。

伸縮調(diào)整、易于獲取新硬件、分布式系統(tǒng)與網(wǎng)絡(luò)，將這些因素結(jié)合起來，會發(fā)現(xiàn)它們在我提出的“microservice for CRUD”概念中作用巨大。如果你將一家公司拓展到將近成功的水平，但在技術(shù)/工程團(tuán)隊拓展上遇到麻煩。將龐大單一的管理拆分成service-style的架構(gòu)會有很大幫助。這是我的親身經(jīng)歷。

微服務(wù)的要點看起來像這樣：

• 服務(wù)支持獨立伸縮。如果系統(tǒng)服務(wù)的一部分有高負(fù)荷或相對其它服務(wù)有高容量的需求，你可以擴(kuò)展服務(wù)來滿足需求。這在單一系統(tǒng)架構(gòu)（譯者注：比如說Java Web中把代碼編譯成一個war包發(fā)布）里可行，但是有時也會變得很復(fù)雜。

• 服務(wù)允許在可控的范圍內(nèi)故障。在您系統(tǒng)中各個模塊可獨立操作的情況下，可以通過拆分成不同的服務(wù)來提高可用性。例如，一款商業(yè)app，如果產(chǎn)品的搜索流程崩潰，但是它仍然可以提供檢測服務(wù)，這將是一件好事?？墒菍嶋H操作起來比理論要復(fù)雜得多，并且人們對于微服務(wù)有許多愚蠢的認(rèn)識，比如暗示服務(wù)重疊沒有價值。通過設(shè)置實現(xiàn)可控的故障并不是必須的，但擁有它情況會好些，但讓單一架構(gòu)做到這一點（設(shè)置獨立可控的故障域）并不容易。

• 服務(wù)要能支持開發(fā)團(tuán)隊人員獨立良好地工作在各自負(fù)責(zé)的模塊。再次聲明，這單一架構(gòu)系統(tǒng)中你是可以做到的，因為我就做到了。但整體上的挑戰(zhàn)（以及與monorepo（單個代碼倉庫）中服務(wù)相關(guān)的挑戰(zhàn)）是，當(dāng)這些“域（譯者注：可理解為范圍）”的概念以源代碼呈現(xiàn)時，工程師要努力去理解理論上與實際編碼上的區(qū)別。如果我能看到所有代碼，并且它們可以編譯在一起，就像是一個交付件（而不是各個服務(wù)單獨拆分構(gòu)建），我更趨向把它作為整體。這樣我就可以從這里抓起代碼在另一個地方使用，從那里獲取數(shù)據(jù)在這里使用，等。

我還準(zhǔn)備了一些筆記。人們經(jīng)常弄混“Monolith”和“monorepo”。一個Monolith風(fēng)格的應(yīng)用是指把一組代碼編譯成單獨的服務(wù)交付件（過程中可能會產(chǎn)生額外的客戶端交付件）。你可以通過配置文件來讓交付件做幾乎任何你能想象的事情，包括上文所有的service-type，但是如果所有代碼沒有集中放到一個倉庫中，這樣做最后會生成很大的鏡像，也會導(dǎo)致混亂，因為團(tuán)隊有時會根據(jù)不同的構(gòu)建工具和配置文件編譯生成不同的交付版本。我依然認(rèn)為這種架構(gòu)是單一架構(gòu)。

Monorepo或者是monolith repository是一種模型，它指一個單一的代碼倉庫，包含了你正在編碼的系統(tǒng)的所有代碼（很可能還不包括OSS/外部依賴的源代碼）。代碼倉庫中的代碼由多個獨立的應(yīng)用交付件組成，這些代碼都可以獨立編譯/打包和測試，不需要整個倉庫的代碼。monorepo的一個優(yōu)勢是，當(dāng)修改了共享庫的版本后，依賴共享庫的開發(fā)人員可以更容易地開發(fā)，而不用去等其他團(tuán)隊更新依賴庫的版本后再開發(fā)。monorepo模型最大的缺點是，支持它的OSS工具不多，因為大部分OSS工具不是這么構(gòu)建的。所以需要大量投資開發(fā)新的工具來支持monorepo模型。

基于CRUD應(yīng)用的微服務(wù)

在介紹CRUD應(yīng)用由單一架構(gòu)到微服務(wù)架構(gòu)演進(jìn)之前，我會先介紹構(gòu)建中等規(guī)模CRUD平臺所需的架構(gòu)設(shè)計。這種平臺有一個不錯的用例，它涉及“事務(wù)”和“元數(shù)據(jù)”。

事務(wù):指用戶做了一個行為，你想把它持久化，這里數(shù)據(jù)的一致性最有價值。CRUD中的Create，Update，Delete操作頻率比Read低得多。

元數(shù)據(jù):描述用戶的信息，但是只能由內(nèi)部內(nèi)容創(chuàng)建者修改，外部用戶（比如審查者）很少能修改。通常具有很高的可緩存性。甚至有時能夠容忍一定程度的臨時不一致性（顯示陳舊的數(shù)據(jù)）。

CRUD依賴型公司還有哪些能做的事呢，尤其是分析領(lǐng)域？當(dāng)然有，你可能需要根據(jù)用戶在瀏覽網(wǎng)站時的行為以及其它個性化的操作來頻繁地調(diào)整結(jié)果。但是做到實時調(diào)整結(jié)果很困難，因為你不一定總是能從用戶那里得到足夠的數(shù)據(jù)來達(dá)到最好的效果，所以這（指上文調(diào)整結(jié)果）不是系統(tǒng)的一級關(guān)注點。

這種架構(gòu)在遷移過程中是相對簡單的：

• 確定獨立實體。這篇論文Life Beyond Txns有很多有趣又實用的定義。越早遷移架構(gòu)越好，否則系統(tǒng)臃腫后不得不實現(xiàn)一個分布式事務(wù)。你可能希望擁有企業(yè)產(chǎn)品，用戶等服務(wù)的數(shù)據(jù)，再集成其它面向企業(yè)的邏輯和聚合服務(wù)。

• 從實體中抽象出邏輯，集成到服務(wù)實體中。盡可能不要去改變數(shù)據(jù)模型，并且通過重定向訪問新的服務(wù)實體APIs。

基本上就這些了。你需要做的是收集足夠的用戶函數(shù)、數(shù)據(jù)和術(shù)語，然后改成微服務(wù)架構(gòu)并開發(fā)新的功能。

這些服務(wù)不是典型的SOA，也不是很小的微服務(wù)。擁有數(shù)據(jù)的服務(wù)會更復(fù)雜。你可能不想要太多服務(wù)，因為你希望在滿足用戶請求的同時，不需要太多的網(wǎng)絡(luò)跳轉(zhuǎn)，甚至不需要分布式事務(wù)（理想情況）。

可能你不需要每天都開發(fā)新的服務(wù)，特別是當(dāng)你有一個五十人的工程團(tuán)隊和一個長期的產(chǎn)品路線圖時，你可能不會為了“點一下按鈕就動態(tài)添加一個新的功能”而投入大量的工程時間到開發(fā)編排和工具上。

決定投入多少時間在工具上很簡單:開發(fā)人員花費在自動添加新服務(wù)的時間VS實現(xiàn)和維護(hù)自動化程序的時間VS隨著時間的推移，你希望添加多少新的服務(wù)？比較下它們就可以了。顯然，如果你認(rèn)為讓人們能夠快速頻繁開發(fā)微小的服務(wù)很重要，你最好投入更多的時間和開發(fā)更多的工具。與所有工程優(yōu)化決策一樣，這樣做不代表它完全正正確，但是在可預(yù)見的未來，它是正確的，而且我們還需要不斷地重新評估。

在這個實例中，我發(fā)現(xiàn)有許多是微服務(wù)必須具備的。比如上文中我提到過很多次的編排。但是如果你不需要自動啟動服務(wù)或頻繁地遷移服務(wù)，你則不需要動態(tài)服務(wù)發(fā)現(xiàn)（如果需要的話，負(fù)載均衡器是一個不錯的選擇）。

允許團(tuán)隊為每個服務(wù)選擇合適的語言、框架和數(shù)據(jù)存儲也不是必須的。事實上，對于你的團(tuán)隊這樣做可能是一個令人頭疼的問題而不是福音。
 

為每個微服務(wù)創(chuàng)建單獨的數(shù)據(jù)存儲。
不要讓所有微服務(wù)都使用同一個后端存儲服務(wù)。因為使用單一的數(shù)據(jù)存儲，不同團(tuán)隊編寫的微服務(wù)就可以容易地共享數(shù)據(jù)庫結(jié)構(gòu)，也會減少許多重復(fù)的工作。但是，如果某個團(tuán)隊更新了數(shù)據(jù)庫結(jié)構(gòu)，使用該結(jié)構(gòu)的其他服務(wù)也需要調(diào)整。

這是真實存在的，但是對于較小的團(tuán)隊，可以通過事先約定好規(guī)則來禁止共享數(shù)據(jù)庫結(jié)構(gòu)（如果還有顧慮，可以通過代碼審查、自動測試和檢測來預(yù)防）。如果你很仔細(xì)地定義數(shù)據(jù)相關(guān)的服務(wù)，不太可能發(fā)生這樣的事情。另一種方法在下一段介紹:
 

將數(shù)據(jù)分離開，可能使數(shù)據(jù)管理更加復(fù)雜，因為分離的存儲系統(tǒng)更容易脫離同步或變得不一致，外鍵也可能被意外更改。這時你就需要增加工具來執(zhí)行主數(shù)據(jù)管理（MDM）:后臺檢測然后修復(fù)數(shù)據(jù)不一致性。例如，它可以檢測每個數(shù)據(jù)庫的用戶id，來驗證所有數(shù)據(jù)庫中的id是否一致（任何數(shù)據(jù)庫中沒有重復(fù)或多余的id）。你可以自己寫工具或者買一個。許多商業(yè)版的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）會執(zhí)行這些類型檢查，但是它們耦合性很高導(dǎo)致無法伸縮（ 出處）。

上面這段可能令很多經(jīng)驗豐富的數(shù)據(jù)檢測工程師失望（譯者注：因為商業(yè)檢測服務(wù)不支持伸縮，言下之意是要自己開發(fā)）。 正是由于數(shù)據(jù)檢測的開銷，我鼓勵小型組織，在決定使用完全獨立的數(shù)據(jù)存儲或個人存儲之前，要評估約定數(shù)據(jù)庫共享的方法。決定最終使用何種數(shù)據(jù)存儲服務(wù)是可以根據(jù)需要來推遲的。

這一版本的微服務(wù)架構(gòu)在擴(kuò)展CRUD應(yīng)用方面令人期待，因為這種架構(gòu)允許你分塊重寫代碼。你可以重寫整個系統(tǒng)，或者簡單地修改對縮放最敏感的部分。你需要主動參與到涉及到分布式系統(tǒng)復(fù)雜性相關(guān)問題上，仔細(xì)思索數(shù)據(jù)和基于數(shù)據(jù)的事務(wù)?？赡苣悴恍枰罅康臄?shù)據(jù)管道，就知道哪里的數(shù)據(jù)需要修改。

我一定要用微服務(wù)來擴(kuò)展這些嗎？答案很可能是no，但是并不意味著使用微服務(wù)來擴(kuò)展系統(tǒng)是一個壞的作法。但是使用極端的微服務(wù)模型可能是一個壞主意，因為你很可能不想以分布式事務(wù)的方式來切分你的數(shù)據(jù)。

基于數(shù)據(jù)處理流的微服務(wù)

現(xiàn)在我們討論一個非常不同的使用案例。這個例子不是你們熟悉的CRUD應(yīng)用，也不包含臃腫的企業(yè)規(guī)則和事務(wù)更新。相反，這個案例包含大量的數(shù)據(jù)流。它從不同的數(shù)據(jù)源接入許多小數(shù)據(jù)，小數(shù)據(jù)又匯聚成大量數(shù)據(jù)。不僅有大量的數(shù)據(jù)，還有大量的服務(wù)來消費、修改數(shù)據(jù)，或者存儲起來以便進(jìn)一步使用。

主要關(guān)注點是接收大量不斷變化的數(shù)據(jù)，以各種方式處理它，并以合適的視圖展示給客戶。而這些在CRUD應(yīng)用中是次要的。

我們以一個聚合度量（Metrics）信息的SaaS應(yīng)用為例。這款應(yīng)用的客戶遍及世界，各種應(yīng)用、服務(wù)、機(jī)器都將度量信息發(fā)送到聚合器。這些客戶只需要查看他們的數(shù)據(jù)，雖然任何一個客戶的數(shù)據(jù)總數(shù)可能非常大。我們的聚合器需要處理這些度量信息，并將它們發(fā)送到負(fù)責(zé)顯示給客戶的程序。面向客戶的應(yīng)用能夠操作實時輸入的數(shù)據(jù)以及來自緩存或者后端存儲系統(tǒng)的歷史數(shù)據(jù)。數(shù)據(jù)的最大價值在于數(shù)據(jù)在移動窗口內(nèi)現(xiàn)在/最近都發(fā)生了什么。

這種架構(gòu)從一開始就要考慮數(shù)據(jù)容量問題，而這在CRUD世界里可能很長時間都不用考慮。另外，數(shù)據(jù)本身是隨著時間不斷更新的?！坝袪顟B(tài)”的數(shù)據(jù)在事務(wù)上最小化更新，最有用的數(shù)據(jù)是時間序列或者事件日志。事務(wù)性的數(shù)據(jù)，比如存儲用戶視圖、配置等，它們類似CRUD中的“元數(shù)據(jù)”，與流數(shù)據(jù)相比很少改變。開發(fā)者的時間大部分用于管理輸入流、提供新的輸入類型、對輸入流進(jìn)行計算或者改變計算方式，而不是處理事務(wù)性數(shù)據(jù)的變更（CRUD）。

本例中，你可以假設(shè)一個服務(wù)，想要通過對數(shù)據(jù)流上的特定元素執(zhí)行不同的計算來進(jìn)行實驗。不修改現(xiàn)有的代碼，實驗性服務(wù)選擇一個時間點開始監(jiān)聽數(shù)據(jù)流，執(zhí)行新的計算得到新的結(jié)果，然后將結(jié)果推送回數(shù)據(jù)流的不同信道上。某一時刻，實驗程序從實驗客戶那提取數(shù)據(jù)，然后將實驗計算結(jié)果而不是標(biāo)準(zhǔn)結(jié)果返回給客戶。你需要記錄所有步驟，用于實驗完整與調(diào)試分析，不要求記錄非常詳細(xì)或者是系統(tǒng)事件甚至用戶相關(guān)的事務(wù)性信息。

本例中，為了更快運行實驗程序，編寫新的代碼可能比更改原有的服務(wù)代碼更簡單。特別是新開發(fā)的服務(wù)不需要擔(dān)心調(diào)整數(shù)據(jù)消耗或者與現(xiàn)存服務(wù)的計算結(jié)果沖突。這就是我所說的“以數(shù)據(jù)流為中心的微服務(wù)”。
 

如果管理實時數(shù)據(jù)流給你的企業(yè)帶來巨大的價值，并且你有非常多的開發(fā)者，要創(chuàng)建新的服務(wù)來消耗數(shù)據(jù)流、檢測數(shù)據(jù)和產(chǎn)生結(jié)果，你肯定愿意投資開發(fā)新工具來盡可能簡化服務(wù)創(chuàng)建和生產(chǎn)環(huán)境部署。你會慢慢把工具應(yīng)用到所有服務(wù)上。但是你也要清晰地認(rèn)識到，擁有可獨立操作和實驗的動態(tài)數(shù)據(jù)是微服務(wù)化的關(guān)鍵。

Cron job作為微服務(wù)

如果沒有提到這一點將是我的疏忽。當(dāng)一切微服務(wù)化非常容易時，自然也包括傳統(tǒng)的cron job微服務(wù)化。

cron job是很好的概念，它沒有把一切都視作“服務(wù)”。你可以用AWS的CloudWatch Events或者是調(diào)度Lambda函數(shù)實現(xiàn)這個目的（將cron job微服務(wù)化）。也可以使用Gearman調(diào)度cron job，它是一個支持隊列和異步作業(yè)的運行程序。注意你的cron job必須冪等（同一個輸入運行兩次結(jié)果不變）。如果你有更簡單的方法運行服務(wù)或者是基礎(chǔ)的cron job，那沒問題（你不需要微服務(wù)化）。

到此，相信大家對“微服務(wù)的基礎(chǔ)知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！