老樹發新芽：微服務

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

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

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

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

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

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

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

用於消息服務的最新的版本，有 Java 消息服務 Java Message Service （JMS）或者 高級消息隊列協議 Advanced Message Queuing Protocol （AMQP）。這些服務通過 企業服務匯流排 Enterprise Service Bus （ESB） 進行連接。基於這些匯流排，來傳遞和接收可擴展標記語言（XML）格式的數據。

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

每個微服務提供一個應用程序編程介面（API）端點。它們通過輕量級協議連接，比如， 表述性狀態轉移 REpresentational State Transfer （REST），或 gRPC。數據傾向於使用 JavaScript 對象標記 JavaScript Object Notation （JSON）或 Protobuf 來表示。

這兩種架構都可以用於去替代以前老的整體式架構，整體式架構的應用程序被構建為單個的、自治的單元。例如，在一個客戶機 —— 伺服器模式中，一個典型的 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 選題：lujun9972 譯者：qhwdw 校對：wxy

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

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive