分布式系統發展史


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

分布式系統(確切地說應該是分布式計算機系統)從它誕生到現在已經過去了很長的時間。在很久以前,一台電腦一次只能完成一項特定的任務。如果我們需要同時完成多項任務,則需要多台計算機並行運行。但是,並行運行並不足以構建真正的分布式系統,因為它需要一種機制來在不同計算機或者那些運行在計算機上的程序之間進行通信。這種在多台計算機之間交換 / 共享數據的需求催生了面向消息通信的想法,即兩台計算機使用包含了數據的消息來共享數據。文件共享、數據庫共享等其他機制當時還沒有出現。

img

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

img

隨着計算能力和存儲價格的降低,世界各地的組織都開始使用分布式系統和基於 SOA 的企業 IT 系統。但是,一旦服務或系統的數量增加,這些服務之間的點到點連接就不再是可擴展和可維護的了。這催生了集中式“服務總線”概念的產生。服務總線通過類似集線器的架構將所有系統連接在一起。這個組件被稱為 ESB(企業服務總線)。它作為一個“語言”翻譯者,就像一個中間人在幫助一群使用不同“語言”但希望相互通信的人進行溝通。在企業應用中,“語言”代表着在通信時不同系統的消息傳遞協議和消息格式。

img

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

img

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

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

img

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

img替換高清大圖

這些新的需求最終幫助工程師們構建了一個容器編排系統。該系統可用於維護更大規模的容器部署的一致性。毋庸置疑的是,這個領域的頂尖技術來自 Google。因為它們的規模非常大。他們構建了名為“Kubernetes”(又名 k8s)的容器編排平台,並成為大規模容器編排需求的事實標准。k8s 讓工程師可以:

在大型集群中運行容器

將數據中心視為一台計算機

控制服務之間的通信(在容器上運行)

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

Kubernetes 和 Docker 讓應用程序員的生活更加輕松。他們不用再考慮他們的應用在不同的環境(操作系統、開發環境、測試環境、生產環境等)下的不同表現。他構建的容器鏡像在所有環境中運行表現幾乎完全相同,因為所有依賴項都被打包到鏡像中了。

img

但是,盡管我們有了容器和編排框架,我們仍然需要一個管理這些服務器的團隊。這意味着數據中心需要使用像 Docker 和 Kubernetes 這樣的技術進行管理,以確保它對於應用程序來說就像一個單台計算機一樣。如果不是你自己來做這些事情,而是別人來為你管理這部分工作,這正是 serverless 架構所帶來的便利。您的服務器將由第三方雲提供商(如 Amazon(Lambda),Microsoft(Azure Functions)或 Google(Cloud Functions))進行管理。現在,分布式系統將由應用程序員進行編程,而基礎設施管理將由雲提供商完成。這是分布式系統發展的最新狀態,並且會不斷地發展下去。

想要了解更多分布式知識點的,可以關注我一下,我后續也會整理更多關於分布式架構這一塊的知識點分享出來,另外順便給大家推薦一個交流學習群:650385180,里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高並發、高性能、分布式、微服務架構的原理,JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良多,以下的課程體系圖也是在群里獲取。

img


此文系轉載,此文介紹了分布式系統的簡單發展史。從雜亂的分布式調用到現在應用最多的k8s+docker。但是沒有介紹現在可能的方向:service mesh。

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM