老樹發新芽：微服務 | Linux 中國

如果我告訴你有這樣一種軟體架構，一個應用程式的元件透過基於網路的通訊協議為其它元件提供服務，我估計你可能會說它是 …

是的，它和你程式設計的年限有關。如果你從上世紀九十年代就開始了你的程式設計生涯，那麼你肯定會說它是 面向服務的架構Service-Oriented Architecture[1]（SOA）。但是，如果你是個年青人，並且在雲上獲得初步的經驗，那麼，你將會說：“哦，你說的是 微服務Microservices[2]。”

你們都沒錯。如果想真正地瞭解它們的差別，你需要深入地研究這兩種架構。

在 SOA 中，服務是一個功能，它是定義好的、自包含的、並且是不依賴背景關係和其它服務的狀態的功能。總共有兩種服務。一種是消費者服務，它從另外型別的服務 —— 提供者服務 —— 中請求一個服務。一個 SOA 服務可以同時扮演這兩種角色。

SOA 服務可以與其它服務交換資料。兩個或多個服務也可以彼此之間相互協調。這些服務執行基本的任務，比如建立一個使用者帳戶、提供登入功能、或驗證支付。

與其說 SOA 是模組化一個應用程式，還不如說它是把分散式的、獨立維護和部署的元件，組合成一個應用程式。然後在伺服器上執行這些元件。

早期版本的 SOA 使用面向物件的協議進行元件間通訊。例如，微軟的 分散式元件物件模型Distributed Component Object Model[3]（DCOM） 和使用 通用物件請求代理架構Common Object Request Broker Architecture[4]（CORBA） 規範的 物件請求代理Object Request Broker[5]（ORB）。

用於訊息服務的最新的版本，有 Java 訊息服務Java Message Service[6]（JMS）或者 高階訊息佇列協議Advanced Message Queuing Protocol[7]（AMQP）。這些服務透過企業服務匯流排Enterprise Service Bus（ESB） 進行連線。基於這些匯流排，來傳遞和接收可擴充套件標記語言（XML）格式的資料。

微服務[2] 是一個架構樣式，其中的應用程式以鬆散耦合的服務或模組組成。它適用於開發大型的、複雜的應用程式的持續整合Continuous Integration/持續部署Continuous Deployment（CI/CD）模型。一個應用程式就是一堆模組的彙總。

每個微服務提供一個應用程式程式設計介面（API）端點。它們透過輕量級協議連線，比如，表述性狀態轉移REpresentational State Transfer[8]（REST），或 gRPC[9]。資料傾向於使用 JavaScript 物件標記JavaScript Object Notation[10]（JSON）或 Protobuf[11] 來表示。

這兩種架構都可以用於去替代以前老的整體式架構，整體式架構的應用程式被構建為單個的、自治的單元。例如，在一個客戶機 —— 伺服器樣式中，一個典型的 Linux、Apache、MySQL、PHP/Python/Perl (LAMP) 伺服器端應用程式將去處理 HTTP 請求、執行子程式、以及從底層的 MySQL 資料庫中檢索/更新資料。所有這些應用程式“綁”在一起提供服務。當你改變了任何一個東西，你都必須去構建和部署一個新版本。

使用 SOA，你可以只改變需要的幾個元件，而不是整個應用程式。使用微服務，你可以做到一次只改變一個服務。使用微服務，你才能真正做到一個解耦架構。

微服務也比 SOA 更輕量級。不過 SOA 服務是部署到伺服器和虛擬機器上，而微服務是部署在容器中。協議也更輕量級。這使得微服務比 SOA 更靈活。因此，它更適合於要求敏捷性的電商網站。

說了這麼多，到底意味著什麼呢？微服務就是 SOA 在容器和雲端計算上的變種。

老式的 SOA 並沒有離我們遠去，而因為我們不斷地將應用程式搬遷到容器中，所以微服務架構將越來越流行。

via: https://blogs.dxc.technology/2018/05/08/everything-old-is-new-again-microservices/

作者：Cloudy Weather[13] 選題：lujun9972 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出