1.1 架構演進

1.1.1 服務端架構發展

由于人們首先想到的是讓兩臺或多臺計算機相互通信，因此構思出了，如圖1-1所示的簡易通信模型。

互相通信的兩個服務可以滿足最終用戶的一些需求。但這個示意圖顯然過于簡單，缺少包括通過代碼操作的字節轉換和在線路上收發的電信號轉換在內的多個層。雖然一定程度上的抽象對于討論是必需的，但仍需添加網絡協議棧（組件）以增加細節內容，如圖1-2所示。

上述這個修改過的模型自20世紀50年代一直使用至今。一開始，計算機很稀少，也很昂貴，所以兩個節點之間的每個環節都被精心制作和維護。隨著計算機變得越來越便宜，連接的數量和數據量大幅增加。人們越來越依賴網絡系統，工程師需要保證他們構建的軟件能夠達到用戶所要求的服務質量。

當然，還有許多問題急需解決以達到用戶要求的服務質量。人們需要找到解決方案讓機器互相發現，通過同一條線路同時處理多個連接，允許機器在非直連的情況下互相通信，通過網絡對數據包進行路由、流量加密等。

其中，有一種機制稱為流量控制，下面以此為例。流量控制是一種防止一臺服務器發送的數據包超過下游服務器可以承受上限的機制。這是必要的，因為在一個聯網的系統中，至少有兩臺不同的、獨立的計算機，彼此之間互不了解。計算機A以給定的速率向計算機B發送字節，但不能保證B可以連續地、以足夠快的速度來處理接收到的字節。例如，B可能正在忙于并行運行其他任務，或者數據包可能無序到達，并且B可能被阻塞以等待本應該第一個到達的數據包。這意味著A不僅不知道B的預期性能，還可能讓事情變得更糟，導致B過載，B現在必須對所有這些傳入的數據包進行排隊處理。

一段時間以來，大家寄希望于建立網絡服務和應用程序的開發者能夠通過編寫代碼來解決上面提出的挑戰。在這個流程控制示例中，應用程序本身必須包含某種邏輯來確保服務不會因為數據包的原因而過載。這種重聯網的邏輯與業務邏輯一樣重要。抽象示意圖如圖1-3所示。

隨著像TCP/IP這樣的標準橫空出世，流量控制和許多其他問題的解決方案被融入網絡協議棧本身。這意味著這些流量控制代碼仍然存在，但已經從應用程序轉移到了操作系統提供的底層網絡層，如圖1-4所示。

這個模型相當成功。幾乎任何一個組織都能夠使用商業操作系統附帶的TCP/IP協議棧來驅動他們的業務，即使有高性能和高可靠性的要求。

1.1.2 微服務架構

隨著節點和穩定連接的數量越來越多，行業中出現了各種各樣的網絡系統：從細粒度的分布式代理和對象，到由較大但重分布式組件組成的面向服務的架構。這樣的分布式系統帶來了幾個難題，有一些是新出現的，也有原有難題的“升級版”。

20世紀90年代，Peter Deutsch和他在Sun公司的同事撰寫了《分布式計算的八大錯誤》一文，文中列出了人們在使用分布式系統時通常會做出的一些假設。Peter認為，這些假設在更原始的網絡架構或理論模型中可能是真實存在的，但在現代世界中是不成立的：

? 網絡是可靠的；

? 延遲為零；

? 帶寬是無限的；

? 網絡是安全的；

? 拓撲是不變的；

? 管理員實時監控維護；

? 傳輸成本為零；

? 網絡是同構的。

因此，工程師們必須處理這些問題。

為了處理更復雜的問題，需要轉向更加分散的系統（我們通常所說的微服務架構），這在可操作性方面提出了新的要求。下面則列出了必須要處理的問題：

? 計算資源的快速提供；

? 基本的監控；

? 快速部署；

? 易于擴展的存儲；

? 可輕松訪問邊緣；

? 認證與授權；

? 標準化的RPC;

因此，盡管數十年前開發的TCP/IP協議棧和通用網絡模型仍然是計算機之間相互通信的有力工具，但更復雜的架構引入了其他層面的問題。此時業界出現了微服務思想，以期解決上述問題。例如，微服務用服務發現與斷路器技術來解決上面列出的幾個彈性擴展和分布式問題，如圖1-5所示。

微服務架構風格是一種將一個單一應用程序開發為一組小型服務的方法，每個服務運行在自己的進程中，服務間通信采用輕量級通信機制（通常用HTTP資源API）。這些服務圍繞業務能力構建并且可通過全自動部署機制獨立部署。這些服務共用一個最小型的集中式的管理，服務可用不同的語言開發，使用不同的數據存儲技術。

我們為了將系統構建為微服務架構，除了服務是可獨立部署、可獨立擴展的之外，每個服務都提供一個固定的模塊邊界，甚至允許不同的服務用不同的語言開發，由不同的團隊管理。圖1-6展示了單體應用到微服務的簡易圖解。

然而歷史往往會重演，第一批基于微服務構建的系統遵循了與前幾代聯網計算機類似的策略。這意味著落實上述需求的責任落在了編寫服務的工程師身上。我們以服務發現和斷路器來說明。

服務發現是在滿足給定查詢條件的情況下自動查找服務實例的過程，例如，一個名叫Teams的服務需要找到一個名為Players的服務實例，其中該實例的environment屬性設置為production。當用戶調用一些提供提供服務發現的組件，它們會返回一個滿足條件的服務列表。對于中心化的架構而言，這是一個非常簡單的任務，通常可以使用DNS、負載均衡器和一些端口號的約定（例如，所有服務將HTTP服務器綁定到8080端口）來實現。而在更分散的環境中，任務開始變得越來越復雜，對于以前可以通過盲目信任DNS來查找依賴關系的服務，現在必須處理諸如客戶端負載均衡、多種不同環境、地理位置上分散的服務器等問題。如果之前只需要一行代碼來解析主機名，那么現在的服務則需要很多行代碼來處理由分布式引入的各種問題。

斷路器是由Michael Nygard在其編寫的《Release It》一書中引入的模式，書中對該模式的一些總結：

封面

隨著分布式水平的提高，它們也會變得越來越復雜。系統發生錯誤的概率隨著分布式水平的提高呈指數級增長，比如一個組件中的一個故障可能會在許多客戶端和客戶端的客戶端上產生連鎖反應，從而觸發數千個電路同時跳閘。而且，以前可能只需幾行代碼就能處理某個問題，現在需要編寫大量的代碼才能處理。

因此微服務反對之聲也很強烈，認為微服務增加了系統維護、部署的難度，導致一些功能模塊或代碼無法復用，增加系統集成與測試的難度，而且隨著系統規模增長，會導致系統越來越復雜。那么有沒有一種框架或開發平臺可以盡可能便捷、一站式解決上述問題呢？有！那便是Spring Cloud。