當我們學習一項新技術或工具時，我們經常會依賴於我們以往的專案中經驗。然而，當我們學習最近很熱門的微服務時，我們以往的經驗可能卻都不管用了。

在本文中，我們將討論專業開發人員在學習微服務主題時最容易犯的五個主要錯誤。

錯誤#01 -將SOA和微服務混淆。

儘管SOA和微服務都是系統架構的一種，但這兩個有很多不同之處：

SOA

它的一般是通過一種方式（單例項，ESB等）來連線現有的應用程式。

必須通過ESB在端點之間的連線和訊息

ESB中公開的服務應該使用特定的語言編寫，並且主要遵循SOAP協議(無論是否使用WS* stack)或REST，使用HTTP協議。

由於需要編碼和解碼，在高負載的情況下交換資訊代價高昂。

垂直進行擴充套件(擴大)

ESB作為單個故障點

由於應用程式EndPoint和ESB中介本身的依賴關係，很難將其部署到MSA(微服務樣式體系結構)

服務是在其他服務執行和使用其合同之前進行註冊的。

Microservices

它的方法是建立一個單獨的應用程式，自部署，它可以在一個獨立的環境中執行，並且有自己的資料庫。

服務之間的連線是精心設計的-通過這種方式，微服務可以對所接收的特定事件作出響應。

可以用任何可用於建立服務的程式語言編寫微服務Java. Python, JavaScript, .NET。

只需要遵循REST介面即可，可以使用谷歌Protobuf、Twitter Finagle等二進位制協議。

對應於我們單體應用系統的功能特徵

容錯

水平擴充套件(擴充套件)

易於部署，CD/CI

微服務在稱為API閘道器的實體中註冊，並被其他微服務自動發現。

錯誤#02 -“如果我使用REST方法，我已經有了微服務”

在微服務中，REST方法只是MSA的主要屬性之一。對於要標記為微服務解決方案的應用程式，應該具有12因素方法學描述的所有特徵。

程式碼庫：一個版本程式碼，多次分發

依賴關係：顯式宣告和隔離依賴項

配置：在環境中儲存配置。

支援服務將支援服務視為附加資源

構建、釋出、執行：嚴格分開構建和執行階段。

流程：將應用程式作為一個或多個無狀態程序執行

埠繫結：通過埠繫結匯出服務

併發性：通過流程模型擴充套件

可處理：快速啟動和快速關閉，使健壯性最大化

x Dev /刺激平價

Dev/prod parity：開發，部署和生產儘可能保持一致

日誌：將日誌處理為事件流

管理流程：將管理和管理的任務作為一次性的過程

錯誤#03 -微服務可以在同一個容器上執行。沒問題,對吧?

理論上是的。不幸的是,這正是一個問題。

Microservices應該:

在其環境中完全獨立執行，並擁有所有所需的資源(鬆散耦合)

能夠獨立伸縮。

能夠獨立地部署。

能夠被追蹤到

能夠被其他微服務自動發現

這些都是保持正確的可伸縮性、容錯和TTM(上市時間)的必要條件。

錯誤#04 -所有的微服務都應該用相同的程式語言編寫

一旦微服務在不同的容器上執行並公開了抽象其底層技術，就不需要用一種特定的程式語言實現所有的微服務。

考慮到這一點，您可以擁有更小的團隊，每個團隊都具有業務funci向性和程式語言的專門知識，從而可以獨立地簡化業務解決方案的演變。

錯誤#05 -微服務顧名思義，應該是小的

微服務中的微服務表示目前存在於單塊應用程式中的業務功能，稱為“所有解決方案”，這些解決方案具有多個功能問題，需要解決一個巨大的業務問題。

然後將這個業務問題分割成更小的部分(微服務本身)，以便輕鬆組合並有效地響應所有業務事務中可能出現的所有請求和業務需求。

訂閱我們公眾號參與討論：程式你好