分佈式系統發展史--轉

http://www.infoq.com/cn/articles/the-evolution-of-distributed-systems

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

圖片來源：https://dzone.com/articles/building-integration-solutions-a-rethink

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

圖片來源：https://www.akuaroworld.com/telecom-oss-new-network-architecture/soa-model/

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

圖片來源：http://ibmwebsphereenterpriseservicebus.blogspot.com/2015/09/enterprise-requirements-for-esb.html

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

圖片來源：https://www.infoq.com/presentations/api-management-architecture

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

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

圖片來源：https://techglimpse.com/docker-installation-tutorial-centos/

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

圖片來源：https://martinfowler.com/articles/microservices.html

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

• 在大型集羣中運行容器
• 將數據中心視爲一臺計算機
• 控制服務之間的通訊（在容器上運行）
• 動態伸縮與爲多個服務進行負載均衡

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

圖片來源：https://redmondmag.com/articles/2017/08/01/container-orchestration-with-kubernetes.aspx

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

查看英文原文：https://medium.com/@chanakaudaya/the-evolution-of-distributed-systems-fec4d35beffd