如今，關(guān)于微服務(wù)依然存在許多誤解，企業(yè)盲目追求這種炫酷技術(shù)并不可取。同時(shí)，這種盲目行為對于希望用微服務(wù)來有效解決問題的公司很不利。不是說任何特定的技術(shù)都是缺乏實(shí)際價(jià)值的，如微服務(wù)、Kubernetes、Lambda函數(shù)之類的新技術(shù)是否被企業(yè)采納，也許都取決于錯(cuò)誤的理由。很多時(shí)候，企業(yè)可能只因?yàn)樗容^流行就使用這些術(shù)語，卻沒有真正讓它的技術(shù)優(yōu)勢在棘手的問題上發(fā)揮作用，或者提供切實(shí)可行的解決方案。從某種程度上說，它夸大了技術(shù)的實(shí)際作用，還給架構(gòu)的合理選擇和使用制造了障礙，這對于其他技術(shù)來說也很不公平。因此，虹科想通過這篇文章來為大家一一澄清對于微服務(wù)所流傳的五大誤解。

微服務(wù)簡介

微服務(wù)作為基礎(chǔ)設(shè)施構(gòu)建塊提供了諸如服務(wù)解耦、數(shù)據(jù)存儲自治、小型化開發(fā)和測試設(shè)置，縮短應(yīng)用程序上線時(shí)間的優(yōu)勢。容器及其編排工具的可用性也提高了微服務(wù)的采用。每個(gè)微服務(wù)都是圍繞一個(gè)特定的業(yè)務(wù)上下文——一個(gè)目標(biāo)、焦點(diǎn)或問題領(lǐng)域。這些模塊化的服務(wù)通過 API 進(jìn)行通信，以便在應(yīng)用程序中執(zhí)行它們自己的功能。微服務(wù)應(yīng)用程序的敏捷性、孤立性和專注性帶來了顯著的優(yōu)勢。包括：?

• 團(tuán)隊(duì)授權(quán)：小型獨(dú)立團(tuán)隊(duì)可以快速部署代碼，以非常敏捷的速度適應(yīng)不斷變化的要求；

• 靈活性：每個(gè)服務(wù)都可以使用最適合其獨(dú)特需求的技術(shù)來構(gòu)建；

• 可重用性：簡單和模塊化的代碼是可重用的，可以應(yīng)用于多種目的，以實(shí)現(xiàn)更快的開發(fā)；?

• 隔離：隔離確保應(yīng)用程序組件可單獨(dú)操作和可擴(kuò)展，并提供故障隔離，以防止微服務(wù)的故障相互影響。?

誤解一：微服務(wù)可以解決所有問題

老話常說："當(dāng)企業(yè)只有一把錘子的時(shí)候，一切看起來都像釘子"。如果微服務(wù)能幫企業(yè)解決實(shí)際難題，那自然好。但許多企業(yè)可能認(rèn)為：

1.只要有應(yīng)用場景，那么微服務(wù)就是解決方案。Redis企業(yè)版數(shù)據(jù)庫的合作伙伴解決方案架構(gòu)師Lars Rosenquist建議：“首先，企業(yè)要搞清什么是微服務(wù)；然后，企業(yè)需要了解自己的應(yīng)用架構(gòu)出了什么問題；最后，才對兩者進(jìn)行匹配進(jìn)行方案制定。但是很少人愿意真的這么做?！?/p>

2.多數(shù)技術(shù)只能解決特定企業(yè)規(guī)模的具體問題。Lars Rosenquist解釋說："如果是像Netflix這樣的大公司，企業(yè)的應(yīng)用消耗了三分之一的互聯(lián)網(wǎng)流量，那就必須進(jìn)行架構(gòu)，才能使技術(shù)發(fā)揮作用。但如果企業(yè)是一家運(yùn)營規(guī)模較小的公司，比如一家本地銀行，那就不需要了。人們經(jīng)常是在為他們想要解決的而不一定是真正存在的問題進(jìn)行優(yōu)化。”

3.大多數(shù)用例都不需要微服務(wù)。編程專家建議：要盡量避免 "龐大的單體架構(gòu)不好，龐大的單體架構(gòu)是舊的解決方案"的心態(tài)，反之，企業(yè)在采用微服務(wù)方法之前，就應(yīng)摒棄這樣的錯(cuò)誤認(rèn)知。

誤解二：微服務(wù)降低了復(fù)雜性

其實(shí)，微服務(wù)架構(gòu)幾乎都會增加復(fù)雜性。若不加以控制，它甚至還會變成一個(gè)分布式系統(tǒng)，使得架構(gòu)更加混亂。因?yàn)椋?/p>

1.微服務(wù)并不能解決系統(tǒng)設(shè)計(jì)問題。iDIA計(jì)算公司的軟件開發(fā)顧問George Dinwiddie說：“如果企業(yè)不能創(chuàng)建一個(gè)具有高內(nèi)聚低耦合的單體設(shè)計(jì)，那它很難把微服務(wù)做好?！?/p>

正如康威定律所言，先從一個(gè)單體開始，然后企業(yè)在增添開發(fā)人員時(shí)再去提取服務(wù)。Rosenquist認(rèn)為："對于一個(gè)單體應(yīng)用程序，它包含了所有的邏輯、通信和復(fù)雜性。通過微服務(wù)，企業(yè)卻能打破這一常規(guī)。因?yàn)橄裢ㄐ拍Ｊ街惖默F(xiàn)在都屬于企業(yè)基礎(chǔ)設(shè)施的一部分?！?/p>

2.微服務(wù)不能消除復(fù)雜性。微服務(wù)只是把復(fù)雜性移到了不同的抽象層，并沒有真正讓它消失。比方說，企業(yè)如果使兩個(gè)應(yīng)用程序組件處于同一個(gè)應(yīng)用程序、同一個(gè)進(jìn)程，甚至在同一個(gè)CPU中相互通信，那這個(gè)應(yīng)用程序的速度一定是非?？斓?。但是對于微服務(wù)，這些應(yīng)用組件被放在了不同機(jī)器上，它們之間相隔了一個(gè)網(wǎng)絡(luò)，一整套基礎(chǔ)設(shè)施，甚至可能是在不同的云中。這對于通信、故障模式及性能評估方面都會是非常大的挑戰(zhàn)?！?/p>

使用虹科Redis企業(yè)版數(shù)據(jù)庫，可以讓管理復(fù)雜性變得更容易!但不要忽視復(fù)雜性是仍然存在的。

3.架構(gòu)的復(fù)雜導(dǎo)致調(diào)試應(yīng)用程序更加困難。為了更好地管理這種復(fù)雜性，還需要確保企業(yè)的監(jiān)控和可觀察性工作做到位。盡管微服務(wù)方法可使企業(yè)的代碼不再那么復(fù)雜，但 Rosenquist指出：“當(dāng)要部署或管理它時(shí)，也許不再那么容易，企業(yè)現(xiàn)在并非只有一個(gè)而是有多個(gè)應(yīng)用程序需要調(diào)試。這些應(yīng)用程序在多個(gè)實(shí)例上運(yùn)行，而這些實(shí)例也在整個(gè)架構(gòu)中實(shí)現(xiàn)負(fù)載均衡。所有的這些通常都比使用單一的應(yīng)用程序更為復(fù)雜。因此，要想實(shí)現(xiàn)成功部署，則需加強(qiáng)類似于日志聚合和可觀察性之類事件的關(guān)注?！?/p>

4.不太復(fù)雜的代碼并不一定能轉(zhuǎn)化為不太復(fù)雜的系統(tǒng)。Redis的開發(fā)領(lǐng)導(dǎo)者William Johnston指出"從代碼的角度來看，單個(gè)服務(wù)可能更好理解，但企業(yè)用微服務(wù)創(chuàng)建的系統(tǒng)的復(fù)雜性會比單體復(fù)雜得多。"特別是在已經(jīng)超負(fù)荷工作的小團(tuán)隊(duì)中，這也許意味著需要花費(fèi)更多的開發(fā)時(shí)間。雖然能促使開發(fā)人員去學(xué)習(xí)應(yīng)用領(lǐng)域和整個(gè)系統(tǒng)，但對于時(shí)間期限緊迫或缺乏技術(shù)經(jīng)驗(yàn)的團(tuán)隊(duì)來說，微服務(wù)不可能“慢慢來”！因?yàn)槲⒎?wù)作為一種相當(dāng)不同的操作方式，技術(shù)要求十分高。從長遠(yuǎn)看，整個(gè)系統(tǒng)的耦合度降低可以讓重構(gòu)更容易，但這也需付出很高的代價(jià)，并且開發(fā)人員的生產(chǎn)力可能會大幅下降，還可能影響對質(zhì)量的保證?；诖?，一個(gè)微服務(wù)依賴于這么多關(guān)系，它的測試難上加難。

備注：康威定律是馬爾文康威1967提出的：“設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)?！蓖ㄋ椎膩碇v：產(chǎn)品必然是其（人員）組織溝通結(jié)構(gòu)的縮影。

誤解三：一種架構(gòu)可以適用于一切

一種架構(gòu)難以應(yīng)用于企業(yè)的所有場景：

1.企業(yè)的舊應(yīng)用程序可能不支持這些架構(gòu)類型的模式。企業(yè)也不應(yīng)該認(rèn)為自己可以立即開始重構(gòu)舊的應(yīng)用程序，要區(qū)分單體、微服務(wù)和函數(shù)。一個(gè)函數(shù)只做一件事，它們屬于事件驅(qū)動型，是為特定的架構(gòu)服務(wù)的。但在企業(yè)流程方面，如果企業(yè)分解掉所有的系統(tǒng)，最終會有一千個(gè)組件，企業(yè)也就不再具有優(yōu)勢。

2.最好的方法取決于具體的使用情況。舉個(gè)例子，一家銀行很可能有相當(dāng)多的單體系統(tǒng)。但為企業(yè)移動銀行應(yīng)用提供動力的微服務(wù)應(yīng)用大約占到了50%-60%，其余的才是函數(shù)。因此，一家企業(yè)在架構(gòu)方面應(yīng)用場景是多樣化的。

無論企業(yè)使用的是什么軟件架構(gòu)或模式，一個(gè)優(yōu)秀的工程團(tuán)隊(duì)都要學(xué)會找到最有效的方法。

誤解四：微服務(wù)主要是一種技術(shù)

1.實(shí)際上微服務(wù)解決的是一個(gè)業(yè)務(wù)或組織的可擴(kuò)展性問題。Johnston指出："微服務(wù)解決的是一個(gè)技術(shù)問題，如果未達(dá)到這個(gè)目標(biāo)，那就是浪費(fèi)時(shí)間。很多人甚至是部分大型企業(yè)啟動一個(gè)新的應(yīng)用程序時(shí)，都認(rèn)為他們需要從分離領(lǐng)域的方式及微服務(wù)開始，但如果企業(yè)對業(yè)務(wù)領(lǐng)域沒有一個(gè)明確的定義，就不該從微服務(wù)開始。”

再一次引用康威定律，企業(yè)軟件環(huán)境中和組織整體中的通信模式是相似的。 Rosenquist認(rèn)為："假設(shè)企業(yè)想從一個(gè)單體架構(gòu)轉(zhuǎn)換到一個(gè)微服務(wù)架構(gòu)，應(yīng)先建立在本身的組織架構(gòu)上。比如，將團(tuán)隊(duì)分開，確保每個(gè)微服務(wù)屬于其中一個(gè)團(tuán)隊(duì)，這其實(shí)是一個(gè)管理問題，而非一個(gè)技術(shù)挑戰(zhàn)。”

2.應(yīng)當(dāng)確保每個(gè)人都理解微服務(wù)的含義，以及該技術(shù)解決業(yè)務(wù)問題的方式。不同部門對微服務(wù)的本質(zhì)往往有不同的看法。采用微服務(wù)架構(gòu)是否能獲得優(yōu)勢取決于這個(gè)問題的大小以及采用該技術(shù)的團(tuán)隊(duì)本身。

誤解五：微服務(wù)允許團(tuán)隊(duì)使用他們喜歡的技術(shù)

這其實(shí)并不完全是一個(gè)誤解，因?yàn)閷F(tuán)隊(duì)來說，使用不同的平臺并不總是一個(gè)好主意。

Johnston認(rèn)為：“人們普遍認(rèn)為可以使用他們喜歡的語言、工具和平臺，這是微服務(wù)的一個(gè)優(yōu)勢。但如果企業(yè)團(tuán)隊(duì)很大，甚至有分布在世界各地，比如，一些團(tuán)隊(duì)可能擅長.NET，而另一些則擅長Java。那么對于他們特定服務(wù)的業(yè)務(wù)領(lǐng)域，使用某種特定技術(shù)可能對他們有利?！比欢?，Johnston提醒說：“對額外環(huán)境的開發(fā)是以增加系統(tǒng)的復(fù)雜性為代價(jià)的，企業(yè)架構(gòu)師也需要了解系統(tǒng)的復(fù)雜性。"? Rosenquist建議："企業(yè)可以為每個(gè)微服務(wù)選擇不同的技術(shù)，但如果企業(yè)有500個(gè)微服務(wù)，僅使用5種技術(shù)會更好而不是500種不同的技術(shù)?！碑?dāng)然，這些都是例子，沒有一個(gè)放之四海而皆準(zhǔn)的方法，企業(yè)應(yīng)當(dāng)在管理和加大開發(fā)復(fù)雜性之間找到平衡點(diǎn)。

關(guān)于微服務(wù)的誤解眾多

以上是我們分享給大家的關(guān)于微服務(wù)流傳較廣的誤解，但并不僅限于此。虹科云科技在這里也為大家整理了一些其他關(guān)于微服務(wù)的誤解：

1.微服務(wù)能加速業(yè)務(wù)。Johnston建議："由于網(wǎng)絡(luò)跳轉(zhuǎn)的增加，微服務(wù)會引發(fā)速度下降。企業(yè)必須接受最終的一致性，但在其他類型的應(yīng)用程序中企業(yè)可以不需要這么做?！?/p>

2.微服務(wù)實(shí)際上是很小的。技術(shù)咨詢公司Archium的聯(lián)合創(chuàng)始人Graham Le提到：“不要被微服務(wù)中的【微】所迷惑。微服務(wù)應(yīng)該比單體小，但最理想的是，一個(gè)服務(wù)能覆蓋一個(gè)中等規(guī)模的領(lǐng)域。小只是一個(gè)相對的術(shù)語；但重點(diǎn)不是讓他們變得非常小?！?/p>

3.每種客戶端都需要對應(yīng)一個(gè)微服務(wù)。咨詢公司Blue Herring的DevOps架構(gòu)師Mark W. Schumann表示"這種想法是錯(cuò)誤的，但他們一直在這樣認(rèn)為！與之相反，應(yīng)該考慮每個(gè)資源對應(yīng)一個(gè)微服務(wù)"。

Redis企業(yè)版可以解決的微服務(wù)問題

作為一個(gè)多租戶解決方案，Redis Enterprise 企業(yè)版數(shù)據(jù)庫在微服務(wù)之間隔離數(shù)據(jù)。最重要的是，它允許用戶對數(shù)據(jù)庫進(jìn)行調(diào)優(yōu)，以在性能和數(shù)據(jù)一致性/持久性之間保持權(quán)衡。Redis企業(yè)版數(shù)據(jù)庫還可用于將實(shí)時(shí)性能擴(kuò)展到緩存之外的一些微服務(wù)用例，如；服務(wù)內(nèi)通信和事件源，也通常被用作支持單個(gè)微服務(wù)的輕量級數(shù)據(jù)庫。Redis企業(yè)版數(shù)據(jù)庫在微服務(wù)方面主要具有以下優(yōu)勢，為客戶提供最全面的解決方案：

虹科Redis企業(yè)版軟件（Redis Enterprise）是企業(yè)級的數(shù)據(jù)庫軟件，也是一款實(shí)時(shí)數(shù)據(jù)平臺，為全球超過8500家知名企業(yè)提供實(shí)時(shí)數(shù)據(jù)服務(wù)。具有線性可擴(kuò)展性、高可用性、持久性、備份和恢復(fù)、地理分布、分層內(nèi)存訪問、多租戶、安全性等8大核心功能、擁有RediSearch、RedisJSON等7大【Redis企業(yè)版特有模塊】，可以任何規(guī)模在云、本地和混合部署中運(yùn)行現(xiàn)代應(yīng)用程序，提供無服務(wù)器、多模型的數(shù)據(jù)庫解決方案。Redis企業(yè)版的核心優(yōu)勢是采用Redis on flash分層存儲技術(shù)即【內(nèi)存+閃存+磁盤】的存儲方式，其Active-Active地理分布式架構(gòu)允許跨地理位置同時(shí)進(jìn)行數(shù)據(jù)讀寫操作、擁有亞毫秒延遲和極高吞吐量。

1.降低系統(tǒng)復(fù)雜性

每個(gè)Redis 企業(yè)版數(shù)據(jù)庫緩存的各個(gè)方面都可以為每個(gè)微服務(wù)定制，提供簡化的管理，以減少微服務(wù)架構(gòu)帶來的操作復(fù)雜性。

2.提供實(shí)時(shí)速度更快的微服務(wù)

所有的網(wǎng)絡(luò)延遲都會降低應(yīng)用程序的性能。Redis企業(yè)版數(shù)據(jù)庫提供了一種方法來收回服務(wù)?

間通信損失的大部分時(shí)間，具有數(shù)據(jù)查詢和消息傳遞的亞毫秒性能，讓微服務(wù)應(yīng)用速度更快。

3.多租戶支持?

多租戶違背了微服務(wù)完全隔離單個(gè)應(yīng)用組件的做法，因此，系統(tǒng)經(jīng)常遇到爭奪資源的挑戰(zhàn)，個(gè)別服務(wù)可能過度消耗其他微服務(wù)共享的資源。用戶可以在Redis企業(yè)版數(shù)據(jù)庫安裝上為所有微服務(wù)部署多個(gè)數(shù)據(jù)庫實(shí)例，而且數(shù)據(jù)在數(shù)據(jù)庫之間保持隔離。Redis企業(yè)版數(shù)據(jù)庫的內(nèi)置機(jī)制通過觸發(fā)重新分片或跨節(jié)點(diǎn)移動來平衡吞吐量/延遲，從而保護(hù)實(shí)例不受影響。

4.高可用性與自動故障檢測

Redis企業(yè)版數(shù)據(jù)庫的架構(gòu)提供了自動故障檢測和零停機(jī)時(shí)間擴(kuò)展，對使用它的微服務(wù)完全透明。故障檢測和故障轉(zhuǎn)移可以在幾秒鐘內(nèi)完成，并且不會丟失數(shù)據(jù)，高度可靠、隨時(shí)可用。

5.原生 Kubernetes 容器編排和管理

用戶可以在 Kubernetes 環(huán)境中把 Redis企業(yè)版數(shù)據(jù)庫容器作為云原生數(shù)據(jù)庫服務(wù)進(jìn)行協(xié)調(diào)。

二者集成可以實(shí)現(xiàn)多種功能。

6.支持多種部署模式

無論用戶的微服務(wù)是在私有云環(huán)境、企業(yè)內(nèi)部還是在云中運(yùn)行，Redis企業(yè)版數(shù)據(jù)庫的靈活?

部署選項(xiàng)都能讓微服務(wù)盡可能地接近數(shù)據(jù)，并使用戶可以完全控制它的數(shù)據(jù)。

下載【白皮書-《Redis Enterprise 如何用于微服務(wù)緩存》】或了解更多【Redis數(shù)據(jù)庫解決方案】，歡迎評論或者前往虹科云科技官網(wǎng)！

關(guān)于虹科云科技

虹科云科技，企業(yè)級云解決方案的引領(lǐng)者！主要分享云計(jì)算、數(shù)據(jù)庫、商業(yè)智能、數(shù)據(jù)可視化、高性能計(jì)算等相關(guān)知識、產(chǎn)品信息、應(yīng)用案例及行業(yè)信息，為學(xué)習(xí)者傳輸前沿知識、為技術(shù)工程師解答專業(yè)問題、為企業(yè)找到最適合的云解決方案！

掃描下方二維碼，第一時(shí)間獲取企業(yè)級云解決方案！