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

為澠池等地區(qū)用戶(hù)提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及澠池網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為做網(wǎng)站、網(wǎng)站設(shè)計(jì)、澠池網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專(zhuān)業(yè)、用心的態(tài)度為用戶(hù)提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶(hù)的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

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

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

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

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

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

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

微服務(wù)的要點(diǎn)看起來(lái)像這樣：

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

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

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

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

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

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

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

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

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

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

這種架構(gòu)在遷移過(guò)程中是相對(duì)簡(jiǎn)單的：

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

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

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

這些服務(wù)不是典型的SOA，也不是很小的微服務(wù)。擁有數(shù)據(jù)的服務(wù)會(huì)更復(fù)雜。你可能不想要太多服務(wù)，因?yàn)槟阆Ｍ跐M(mǎn)足用戶(hù)請(qǐng)求的同時(shí)，不需要太多的網(wǎng)絡(luò)跳轉(zhuǎn)，甚至不需要分布式事務(wù)（理想情況）。

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

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

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

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

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

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

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

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

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

我一定要用微服務(wù)來(lái)擴(kuò)展這些嗎？答案很可能是no，但是并不意味著使用微服務(wù)來(lái)擴(kuò)展系統(tǒng)是一個(gè)壞的作法。但是使用極端的微服務(wù)模型可能是一個(gè)壞主意，因?yàn)槟愫芸赡懿幌胍苑植际绞聞?wù)的方式來(lái)切分你的數(shù)據(jù)。

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

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

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

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

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

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

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

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

Cron job作為微服務(wù)

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

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

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

本文名稱(chēng)：微服務(wù)的基礎(chǔ)知識(shí)點(diǎn)有哪些
當(dāng)前URL：http://www.chinadenli.net/article46/iiipeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊(cè)、品牌網(wǎng)站制作、品牌網(wǎng)站設(shè)計(jì)、商城網(wǎng)站、網(wǎng)站導(dǎo)航、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)