分佈式系統發展史

分佈式系統從最先的數據共享需求，發展到如今的 serverless 架構。它伴隨着技術的發展與公司實際需求變化而演進。如今的雲服務提供商簡化了分佈式系統開發的複雜性，讓應用開發者只需關注開發，而把基礎設施管理交給大型的雲服務提供商。回顧分佈式系統發展的歷史，瞭解容器技術革新的原動力。

分佈式系統（確切地說應該是分佈式計算機系統）從它誕生到如今已通過去了很長的時間。在好久之前，一臺電腦一次只能完成一項特定的任務。若是咱們須要同時完成多項任務，則須要多臺計算機並行運行。可是，並行運行並不足以構建真正的分佈式系統，由於它須要一種機制來在不一樣計算機或者那些運行在計算機上的程序之間進行通訊。這種在多臺計算機之間交換 / 共享數據的需求催生了面向消息通訊的想法，即兩臺計算機使用包含了數據的消息來共享數據。文件共享、數據庫共享等其餘機制當時尚未出現。

接着，咱們進入了多任務操做系統和我的電腦的時代。利用 Windows、Unix、Linux 等操做系統，咱們能夠在同一臺計算機上運行多個任務。這使得分佈式系統開發人員可以在一臺或者幾臺經過消息傳遞鏈接的計算機內構建和運行整個分佈式系統。這催生了面向服務的架構（SOA），其中每一個分佈式系統能夠經過一組集成在一臺計算機或多臺計算機上運行的服務來構建。咱們經過 WSDL（用於 SOAP 協議）或 WADL（用於 REST 協議）等語言適當地定義服務接口。接着，服務的使用者將利用這些接口來進行客戶端的實現。

隨着計算能力和存儲價格的下降，世界各地的組織都開始使用分佈式系統和基於 SOA 的企業 IT 系統。可是，一旦服務或系統的數量增長，這些服務之間的點到點鏈接就再也不是可擴展和可維護的了。這催生了集中式「服務總線」概念的產生。服務總線經過相似集線器的架構將全部系統鏈接在一塊兒。這個組件被稱爲 ESB（企業服務總線）。它做爲一個「語言」翻譯者，就像一箇中間人在幫助一羣使用不一樣「語言」但但願相互通訊的人進行溝通。在企業應用中，「語言」表明着在通訊時不一樣系統的消息傳遞協議和消息格式。

這種模式工做得很好，即便在今天也能正常工做。隨着萬維網的普及和模型的簡化，基於 REST 的通訊比基於 SOAP 的通訊模型變得更加流行。這促進了基於應用程序編程接口（API）的 REST 模型通訊的發展。因爲 REST 模型的簡潔特性，咱們須要在標準 REST API 實現之上實現安全（身份驗證和受權）、緩存、流控和監控等各類類型的功能。但咱們並不想獨立地在每一個 API 上實現這些功能，而是須要一個公共組件將這些功能應用於這些 API 之上。這樣的需求催生了 API 管理平臺的發展。如今，它已經成爲了任何分佈式系統的核心功能之一。

隨後，咱們見證了分佈式系統大爆炸的時代。Facebook、Google、Amazon、Netflix、LinkedIn、Twitter 等互聯網公司變得異常龐大。他們開始想要構建跨越多個地理區域和多個數據中心的分佈式系統。這樣的需求使他們的技術焦點轉向了一切開始的地方。工程師們開始思考單臺計算機和單個程序的概念。他們再也不把一臺計算機看成一臺計算機來看，而在同一臺計算機內建立多臺虛擬計算機。這催生了關於虛擬機的想法，即同一臺計算機能夠充當多臺計算機而且所有並行運行。儘管這是一個還不錯的主意，但在宿主計算機的資源利用方面，這並非最好的選擇。運行多個操做系統須要更多的資源，但在同一個操做系統裏運行多個程序並不須要這些資源。

這些問題最終催生了關於容器技術的想法。容器只使用一個宿主操做系統（Linux）的內核，就能夠運行多個程序並分別依賴於相互獨立的運行時。這個概念在 Linux 操做系統上已經有一段時間了。隨着基於容器技術的應用程序部署的普及，它變得更加流行而且有了不少改進和提高。容器能夠像虛擬機同樣工做，卻不須要多一個操做系統的開銷。您能夠將應用程序和全部相關的依賴項放入容器鏡像中。它即可以被放在任何能夠運行容器的宿主操做系統中運行。Docker 和 Rocket 是兩個熱門的容器構建平臺。

容器技術爲 Netflix、LinkedIn 和 Twitter 等組織提供了底層框架，用於構建他們要求苛刻的永遠在線的多區域、多數據中心應用平臺。但這並不意味着利用容器技術沒有任何難點。基於容器的部署帶來的輕量特性讓跨多個容器的平臺維護和編排變得很是複雜。隨着微服務架構（MSA）的出現，單體式應用程序被分紅更小塊的微服務。這些微服務可以完成整個服務裏的某一個特定功能並部署在容器中（在大多數狀況下均可以）。這給分佈式系統生態系統帶來了一系列新的需求。要讓系統最終保持一致，而且彼此之間沒有太多複雜的通訊。

替換高清大圖

這些新的需求最終幫助工程師們構建了一個容器編排系統。該系統可用於維護更大規模的容器部署的一致性。毋庸置疑的是，這個領域的頂尖技術來自 Google。由於它們的規模很是大。他們構建了名爲「Kubernetes」（又名 k8s）的容器編排平臺，併成爲大規模容器編排需求的事實標準。k8s 讓工程師能夠：

在大型集羣中運行容器

將數據中心視爲一臺計算機

控制服務之間的通訊（在容器上運行）

動態伸縮與爲多個服務進行負載均衡

Kubernetes 和 Docker 讓應用程序員的生活更加輕鬆。他們不用再考慮他們的應用在不一樣的環境（操做系統、開發環境、測試環境、生產環境等）下的不一樣表現。他構建的容器鏡像在全部環境中運行表現幾乎徹底相同，由於全部依賴項都被打包到鏡像中了。

可是，儘管咱們有了容器和編排框架，咱們仍然須要一個管理這些服務器的團隊。這意味着數據中心須要使用像 Docker 和 Kubernetes 這樣的技術進行管理，以確保它對於應用程序來講就像一個單臺計算機同樣。若是不是你本身來作這些事情，而是別人來爲你管理這部分工做，這正是 serverless 架構所帶來的便利。您的服務器將由第三方雲提供商（如 Amazon（Lambda），Microsoft（Azure Functions）或 Google（Cloud Functions））進行管理。如今，分佈式系統將由應用程序員進行編程，而基礎設施管理將由雲提供商完成。這是分佈式系統發展的最新狀態，而且會不斷地發展下去。

想要了解更多分佈式知識點的，能夠關注我一下，我後續也會整理更多關於分佈式架構這一塊的知識點分享出來，另外順便給你們推薦一個交流學習羣：650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多，如下的課程體系圖也是在羣裏獲取。

---

此文系轉載，此文介紹了分佈式系統的簡單發展史。從雜亂的分佈式調用到如今應用最多的k8s＋docker。可是沒有介紹如今可能的方向：service mesh。

轉自：https://blog.csdn.net/albenxie/article/details/80342171