如今，關於微服務依然存在許多誤解，企業盲目追求這種炫酷技術並不可取。同時，這種盲目行為對於希望用微服務來有效解決問題的公司很不利。不是說任何特定的技術都是缺乏實際價值的，如微服務、Kubernetes、Lambda函式之類的新技術是否被企業採納，也許都取決於錯誤的理由。很多時候，企業可能只因為它比較流行就使用這些術語，卻沒有真正讓它的技術優勢在棘手的問題上發揮作用，或者提供切實可行的解決方案。從某種程度上說，它誇大了技術的實際作用，還給架構的合理選擇和使用製造了障礙，這對於其他技術來說也很不公平。因此，虹科想透過這篇文章來為大家一一澄清對於微服務所流傳的五大誤解。

微服務簡介

微服務作為基礎設施構建塊提供了諸如服務解耦、資料儲存自治、小型化開發和測試設定，縮短應用程式上線時間的優勢。容器及其編排工具的可用性也提高了微服務的採用。每個微服務都是圍繞一個特定的業務上下文——一個目標、焦點或問題領域。這些模組化的服務透過 API 進行通訊，以便在應用程式中執行它們自己的功能。微服務應用程式的敏捷性、孤立性和專注性帶來了顯著的優勢。包括：

• 團隊授權：小型獨立團隊可以快速部署程式碼，以非常敏捷的速度適應不斷變化的要求;

• 靈活性：每個服務都可以使用最適合其獨特需求的技術來構建;

• 可重用性：簡單和模組化的程式碼是可重用的，可以應用於多種目的，以實現更快的開發;

• 隔離：隔離確保應用程式元件可單獨操作和可擴充套件，並提供故障隔離，以防止微服務的故障相互影響。

誤解一：微服務可以解決所有問題

老話常說："當企業只有一把錘子的時候，一切看起來都像釘子"。如果微服務能幫企業解決實際難題，那自然好。但許多企業可能認為：

1.只要有應用場景，那麼微服務就是解決方案。Redis企業版資料庫的合作伙伴解決方案架構師Lars Rosenquist建議：“首先，企業要搞清什麼是微服務;然後，企業需要了解自己的應用架構出了什麼問題;最後，才對兩者進行匹配進行方案制定。但是很少人願意真的這麼做。”

2.多數技術只能解決特定企業規模的具體問題。Lars Rosenquist解釋說："如果是像Netflix這樣的大公司，企業的應用消耗了三分之一的網際網路流量，那就必須進行架構，才能使技術發揮作用。但如果企業是一家運營規模較小的公司，比如一家本地銀行，那就不需要了。人們經常是在為他們想要解決的而不一定是真正存在的問題進行最佳化。”

3.大多數用例都不需要微服務。程式設計專家建議：要儘量避免 "龐大的單體架構不好，龐大的單體架構是舊的解決方案"的心態，反之，企業在採用微服務方法之前，就應摒棄這樣的錯誤認知。

誤解二：微服務降低了複雜性

其實，微服務架構幾乎都會增加複雜性。若不加以控制，它甚至還會變成一個分散式系統，使得架構更加混亂。因為：

1.微服務並不能解決系統設計問題。iDIA計算公司的軟體開發顧問George Dinwiddie說：“如果企業不能建立一個具有高內聚低耦合的單體設計，那它很難把微服務做好。”

正如康威定律所言，先從一個單體開始，然後企業在增添開發人員時再去提取服務。Rosenquist認為："對於一個單體應用程式，它包含了所有的邏輯、通訊和複雜性。透過微服務，企業卻能打破這一常規。因為像通訊模式之類的現在都屬於企業基礎設施的一部分。”

2.微服務不能消除複雜性。微服務只是把複雜性移到了不同的抽象層，並沒有真正讓它消失。比方說，企業如果使兩個應用程式元件處於同一個應用程式、同一個程式，甚至在同一個CPU中相互通訊，那這個應用程式的速度一定是非常快的。但是對於微服務，這些應用元件被放在了不同機器上，它們之間相隔了一個網路，一整套基礎設施，甚至可能是在不同的雲中。這對於通訊、故障模式及效能評估方面都會是非常大的挑戰。”

使用虹科Redis企業版資料庫，可以讓管理複雜性變得更容易!但不要忽視複雜性是仍然存在的。

3.架構的複雜導致除錯應用程式更加困難。為了更好地管理這種複雜性，還需要確保企業的監控和可觀察性工作做到位。儘管微服務方法可使企業的程式碼不再那麼複雜，但 Rosenquist指出：“當要部署或管理它時，也許不再那麼容易，企業現在並非只有一個而是有多個應用程式需要除錯。這些應用程式在多個例項上執行，而這些例項也在整個架構中實現負載均衡。所有的這些通常都比使用單一的應用程式更為複雜。因此，要想實現成功部署，則需加強類似於日誌聚合和可觀察性之類事件的關注。”

4.不太複雜的程式碼並不一定能轉化為不太複雜的系統。Redis的開發者之一William Johnston指出"從程式碼的角度來看，單個服務可能更好理解，但企業用微服務建立的系統的複雜性會比單體複雜得多。"特別是在已經超負荷工作的小團隊中，這也許意味著需要花費更多的開發時間。雖然能促使開發人員去學習應用領域和整個系統，但對於時間期限緊迫或缺乏技術經驗的團隊來說，微服務不可能“慢慢來”!因為微服務作為一種相當不同的操作方式，技術要求十分高。從長遠看，整個系統的耦合度降低可以讓重構更容易，但這也需付出很高的代價，並且開發人員的生產力可能會大幅下降，還可能影響對質量的保證。基於此，一個微服務依賴於這麼多關係，它的測試難上加難。

Redis企業版資料庫微服務可透過快速和靈活的資料模型降低複雜性

備註：康威定律是馬爾文康威1967提出的：“設計系統的架構受制於產生這些設計的組織的溝通結構。”通俗的來講：產品必然是其(人員)組織溝通結構的縮影。

誤解三：一種架構可以適用於一切

一種架構難以應用於企業的所有場景：

1.企業的舊應用程式可能不支援這些架構型別的模式。企業也不應該認為自己可以立即開始重構舊的應用程式，要區分單體、微服務和函式。一個函式只做一件事，它們屬於事件驅動型，是為特定的架構服務的。但在企業流程方面，如果企業分解掉所有的系統，最終會有一千個元件，企業也就不再具有優勢。

2.最好的方法取決於具體的使用情況。舉個例子，一家銀行很可能有相當多的單體系統。但為企業移動銀行應用提供動力的微服務應用大約佔到了50%-60%，其餘的才是函式。因此，一家企業在架構方面應用場景是多樣化的。

無論企業使用的是什麼軟體架構或模式，一個優秀的工程團隊都要學會找到最有效的方法。

誤解四：微服務主要是一種技術

1.實際上微服務解決的是一個業務或組織的可擴充套件性問題。Johnston指出："微服務解決的是一個技術問題，如果未達到這個目標，那就是浪費時間。很多人甚至是部分大型企業啟動一個新的應用程式時，都認為他們需要從分離領域的方式及微服務開始，但如果企業對業務領域沒有一個明確的定義，就不該從微服務開始。”

再一次引用康威定律，企業軟體環境中和組織整體中的通訊模式是相似的。 Rosenquist認為："假設企業想從一個單體架構轉換到一個微服務架構，應先建立在本身的組織架構上。比如，將團隊分開，確保每個微服務屬於其中一個團隊，這其實是一個管理問題，而非一個技術挑戰。”

2. 應當確保每個人都理解微服務的含義，以及該技術解決業務問題的方式。不同部門對微服務的本質往往有不同的看法。採用微服務架構是否能獲得優勢取決於這個問題的大小以及採用該技術的團隊本身。

誤解五：微服務允許團隊使用他們喜歡的技術

這其實並不完全是一個誤解，因為對團隊來說，使用不同的平臺並不總是一個好主意。

Johnston認為：“人們普遍認為可以使用他們喜歡的語言、工具和平臺，這是微服務的一個優勢。但如果企業團隊很大，甚至有分佈在世界各地，比如，一些團隊可能擅長.NET，而另一些則擅長Java。那麼對於他們特定服務的業務領域，使用某種特定技術可能對他們有利。”然而，Johnston提醒說：“對額外環境的開發是以增加系統的複雜性為代價的，企業架構師也需要了解系統的複雜性。" Rosenquist建議："企業可以為每個微服務選擇不同的技術，但如果企業有500個微服務，僅使用5種技術會更好而不是500種不同的技術。”當然，這些都是例子，沒有一個放之四海而皆準的方法，企業應當在管理和加大開發複雜性之間找到平衡點。

關於微服務的誤解眾多

以上是我們分享給大家的關於微服務流傳較廣的誤解，但並不僅限於此。虹科雲科技在這裡也為大家整理了一些其他關於微服務的誤解：

1.微服務能加速業務。Johnston建議："由於網路跳轉的增加，微服務會引發速度下降。企業必須接受最終的一致性，但在其他型別的應用程式中企業可以不需要這麼做。”

2.微服務實際上是很小的。技術諮詢公司Archium的聯合創始人Graham Le提到：“不要被微服務中的【微】所迷惑。微服務應該比單體小，但最理想的是，一個服務能覆蓋一箇中等規模的領域。小隻是一個相對的術語;但重點不是讓他們變得非常小。”

3.每種客戶端都需要對應一個微服務。諮詢公司Blue Herring的DevOps架構師Mark W. Schumann表示"這種想法是錯誤的，但他們一直在這樣認為!與之相反，應該考慮每個資源對應一個微服務"。

Redis企業版可以解決的微服務問題

作為一個多租戶解決方案，Redis Enterprise 企業版資料庫在微服務之間隔離資料。最重要的是，它允許使用者對資料庫進行調優，以在效能和資料一致性/永續性之間保持權衡。Redis企業版資料庫還可用於將實時效能擴充套件到快取之外的一些微服務用例，如;服務內通訊和事件源，也通常被用作支援單個微服務的輕量級資料庫。Redis企業版資料庫在微服務方面主要具有以下優勢，為客戶提供最全面的解決方案：

虹科Redis企業版軟體(Redis Enterprise)是企業級的資料庫軟體，也是一款實時資料平臺，為全球超過8500家知名企業提供實時資料服務。具有線性可擴充套件性、高可用性、永續性、備份和恢復、地理分佈、分層記憶體訪問、多租戶、安全性等8大核心功能、擁有RediSearch、RedisJSON等7大【Redis企業版特有模組】，可以任何規模在雲、本地和混合部署中執行現代應用程式，提供無伺服器、多模型的資料庫解決方案。Redis企業版的核心優勢是採用Redis on flash分層儲存技術即【記憶體+快閃記憶體+磁碟】的儲存方式，其Active-Active地理分散式架構允許跨地理位置同時進行資料讀寫操作、擁有亞毫秒延遲和極高吞吐量。

1. 降低系統複雜性

每個Redis 企業版資料庫快取的各個方面都可以為每個微服務定製，提供簡化的管理，以減少微服務架構帶來的操作複雜性。

2. 提供實時速度更快的微服務

所有的網路延遲都會降低應用程式的效能。Redis企業版資料庫提供了一種方法來收回服務

間通訊損失的大部分時間，具有資料查詢和訊息傳遞的亞毫秒效能，讓微服務應用速度更快。

3. 多租戶支援

多租戶違背了微服務完全隔離單個應用元件的做法，因此，系統經常遇到爭奪資源的挑戰，個別服務可能過度消耗其他微服務共享的資源。使用者可以在Redis企業版資料庫安裝上為所有微服務部署多個資料庫例項，而且資料在資料庫之間保持隔離。Redis企業版資料庫的內建機制透過觸發重新分片或跨節點移動來平衡吞吐量/延遲，從而保護例項不受影響。

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

Redis企業版資料庫的架構提供了自動故障檢測和零停機時間擴充套件，對使用它的微服務完全透明。故障檢測和故障轉移可以在幾秒鐘內完成，並且不會丟失資料，高度可靠、隨時可用。

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

使用者可以在 Kubernetes 環境中把 Redis企業版資料庫容器作為雲原生資料庫服務進行協調。

二者整合可以實現多種功能。

6.支援多種部署模式

無論使用者的微服務是在私有云環境、企業內部還是在雲中執行，Redis企業版資料庫的靈活

部署選項都能讓微服務儘可能地接近資料，並使使用者可以完全控制它的資料。

下載 【白皮書-《Redis Enterprise 如何用於微服務快取》】 或瞭解更多 【Redis資料庫解決方案】 ，歡迎評論或者前往虹科雲科技官網！