作者：lixuefeng

轉載鏈接：zhuanlan.zhihu.com/p/74

著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

-------------------------------------------------------------------------------------------

IT軟體技術架構進入雲化時代後，新概念、新技術大量湧現。從幾年前熱火的Openstack、計算存儲網路三大虛擬化技術、Iaas平台，到近幾年更火熱的容器和雲原生的相關技術，在雲計算這一領域新技術可謂是層出不窮。

我們經常會聽到的這些概念，比如容器、docker、kubernetes、微服務架構、Paas平台、服務中台、Devops、雲原生等等。這些技術和概念彼此之間感覺是獨立的，我們很容易從其中某一個角度學習入手並應用；但是，很多時候，我們會發現這些技術彼此之間又有密切的關聯，從文章也好、技術落地應用的場景也好，它們往往又出現在同一個地方。它們之間究竟有什麼聯繫，彼此之間有什麼依賴，讓人十分的困惑。

在本文中，從這些技術彼此之間的依賴和關係入手，講述它們在當今軟體雲化和微服務化時代中的作用，希望讀者從這些總結對比入手，對微服務相關的技術體系建立全局性的視野和理解。

1. Docker容器：

docker大部分人都熟悉或者至少是聽過。Docker技術在很多技術資料和書籍上，往往會跟虛擬化技術做對比，它們的對比如下：

  • KVM等虛擬化技術是在操作系統級別上進行虛擬和隔離，每一個虛機都是獨立的OS。
  • 而docker是在同一個操作系統中，實現了輕量級的虛擬化。「輕量級的虛擬化」怎麼理解呢？看起來docker容器是獨立的操作系統，本質上是同一個操作系統中的進程隔離。所以它是輕量級的；從而，docker比KVM更省資源、資源利用率更高。

Docker的設計理念很偉大、作用也很偉大。但是docker的偉大性遠不只是體現在「輕量的虛擬化」；docker的偉大性體現在：它實現了：同一個軟體發布，在不同的平台上運行。

這個好處是不是很熟悉？這其實就是Java最初流行起來的原因。Python語言為了實現這一點，弄出了VirtualEnv，把依賴包都隨著程序發布，才解決了多平台運行的問題。Docker的設計很優雅，一個應用都打包成一個image格式，image採用分層技術等等，這部分不是本文的重點，大家希望更深入了解的話，可以參考其他資料。

2. Kubernetes

docker鏡像運行起來是一個一個的程序，多個程序合起來做成一個大的分散式應用怎麼做呢？

答案很簡單，一樣的，程序之間互相調用就行。就好比傳統的分散式應用，多弄幾台伺服器，一個伺服器上裝一個程序，程序之間通過socket或其他協議通信。基於docker的分散式應用也是如此，區別只是網路虛擬化了、CPU和內存資源也虛擬化了。

但是永遠不要低估分散式應用的複雜性，舉兩個例子，想像我們搭建了一套分散式集群，運行了一套分散式應用：

  • 這個集群中的某個機器出故障了（斷電了、硬碟壞了等等），怎麼去排查故障、怎麼去修復？
  • 這個集群中某一部分業務由於訪問量增加，需要擴充支撐能力，怎麼擴充？

針對這兩個問題，我們很容易想到答案，那就是人過去檢查機器、修復或者重裝，負載過大了，就改應用的架構，上面套上負載均衡性，採用可擴展的架構。這些都是傳統的辦法，這些解決辦法不好的地方也很明顯，就是修復太慢，太費人力、成本高、對業務影響大，想像一個網站，等擴展架構都弄好了，用戶也就都流失了。

Kubernetes是容器編排系統，它首要的目的就是為了解決上面這個例子里的兩個問題：

  • 分散式容器應用的可靠性，在伺服器或容器應用出現問題的情況下，自動感知，自動將容器應用在集群內的其他機器里重新運行起來
  • 分散式容器應用的可擴展性，通過啟動相同的容器應用，自動的提升應用的負載支撐能力。

Google為了壓制AWS，把自己的容器運行平台開源出來，成為了現在的Kubernetes，這段歷史大家可以搜索了解一下。

3. Paas

雲計算的經典理論上講三大層：Iaas、Paas、Saas，分布是Infrastructure、Platform、Software as a service。其中的Infrastructure指的是硬體資源虛擬化；Platform指的是軟體平台，是應用軟體運行的基礎平台。

為什麼經典理論要把Paas這一層單獨拿出來？

Saas層是直接面向業務用戶的，Iaas層是應用運行的底層物理資源，中間的Paas是應用運行的標準平台，它包括基礎資料庫服務、基礎中間件服務、基礎開發框架和開發套件、應用部署、管理和運維服務。通過Paas平台這一層，Saas層更專註於自身的業務實現，運行平台和運行中間件由Paas層提供。

因為前述的Kubernetes的成熟程度以及無可比擬的優勢，Paas層的基礎架構基本上都是採用Kubernetes。

有時候會聽到「中台」這個概念，中台這個」中「字意思是」上對Saas、下對Iaas「，中間的就是中台。中台這個概念本質上是把paas層再細分，分為底層基礎平台（kubernetes和docker這一層）、數據層（叫做數據中台）、業務層（業務中台）等。

Paas中台

4. 微服務

引述Sam Newman在Building Mircroservices一書中關於微服務的定義：

Microservices are small, autonomous services that work together.

引用前網飛雲架構負責人Adrian Cockcroft的定義：

Loosely coupled service-oriented architecture with bounded contexts.

我們這裡定義為：微服務是可以獨立部署的、小的、自治的業務組件，業務組件彼此之間通過消息進行交互。微服務的組件可以按需獨立伸縮，具備容錯和故障恢復能力。

由於微服務架構有下面這幾個優勢，已經成為雲計算時代應用的標準架構：

  • 支持快速上線。由於業務組件的自治性和獨立性，新的功能和應用能夠迅速的發布上線，而不用擔心對系統其他功能帶來大範圍的影響和波及。可以通過服務組件重用重組，快速的形成和發布新的應用。
  • 支持獨立擴容和恢復。針對性的對應用中的某些服務進行擴容，解決性能的瓶頸。可以獨立替換或恢復微服務中的某個組件。

快速上線-意味著速度和效率；獨立擴容和恢復-意味著系統的安全、穩定、可擴展。採用微服務架構體系的應用在開發效率、穩定性、可擴展性上具備了無可比擬的優勢，使其成為雲化應用的標準架構。

由於微服務本身就是獨立發布、獨立部署、自治的、微小的服務，而docker容器也是跨平台、獨立運行、小的執行單元。所以容器是微服務架構的良好運行載體。

微服務架構中的核心功能組件包括網關、微服務治理、服務註冊、配置管理、限流和熔斷、負載均衡、自動擴容、自動故障隔離、自動業務恢復、監控和日誌組件等。

微服務架構本質上與容器及K8S技術無關，在Java體系的Spring Cloud就提供了諸如網關Zuul組件、Ribbon負載均衡組件、Eureka服務註冊組件、LCM擴容組件、Hystrix業務恢復組件。利用Spring Cloud的能力可以實現一套完善的微服務架構。Spring Cloud有大量的java開發人員所擁護，這是它的優勢。但是Spring Cloud的劣勢很突出，那就是限制編程語言和編程技術。

Kubernetes提供了服務註冊、配置管理、負載均衡、故障隔離、業務恢復、自動擴容等能力。基於Kubernetes的Paas平台又提供了諸如基礎數據服務、網關服務、微服務治理服務等基礎服務能力。此外，Kubernetes不限制編程語言，社區活躍、功能穩定。所以可以講，kubernetes和Paas平台是微服務技術的運行平台。

微服務架構對應用運行平台的依賴性很強，一個好的、功能全面、易用、穩定的Paas平台才能發揮出微服務架構的優勢。反之，如果沒有一個好的Paas平台，應用開發團隊的大部分精力耗費在平台的搭建、利用，以及微服務架構的設計和應用維護上。那樣的話，不僅沒有得到利用微服務架構的好處，反而沉陷於利用微服務架構所帶來的技術挑戰和劣勢當中。

總的來說，微服務架構是一個「重平台、輕應用」的架構，從應用軟體整體來看，相比較傳統架構，平台的研發投入比重占的很大。利用成熟穩定的商業化Paas平台是成本最優的方案。

5. SOA

SOA（Service-Oriented-Architecture）面向服務的架構，是把服務拼裝形成應用整體的架構。SOA中的服務是指「可重用的業務模塊」。

微服務架構與SOA很像，同樣都是將整個應用拆分，形成獨立的業務模塊的思路。但在許多關鍵點上，微服務架構與SOA不同。

SOA架構與微服務架構對比
  • SOA很大程度上依賴於基於XML的消息格式和基於SOAP的通信協議，微服務架構大量的依賴於REST和JSON。
  • SOA架構中有ESB（服務匯流排）的概念，ESB負責服務之間的通信轉發和介面適配，在SOA實現中，ESB處於核心地位，有很多專業的ESB廠商提供ESB中間件，例如WebSphere ESB、Oracle ESB、Dubbo等。
  • ESB本身是非常「重」的技術，在雲化軟體體系和微服務架構中，強調更輕量級、更迅速、去中心化的技術，所以在微服務架構中，不需要ESB，而通過API網關這樣的技術來負責服務介面轉發。（由於軟體全面雲化是一個過程、需要適配、調整來全面完成轉變，所以在一段時間內，面對大量的遺留系統，ESB仍然會充當微服務改造過程中用來適配老系統的一個重要組件。）
  • SOA的設計思路是把一些組件和服務，通過服務匯流排組裝，形成更大的應用系統（從小到大）；而微服務的設計思路是把應用拆分成獨立自治的小的服務（從大到小）。
  • SOA設計架構強調分層，通常會分為展現層、業務層、匯流排層和數據層。微服務架構中的服務更鬆散。
  • SOA中的服務不強調業務領域的自治性，微服務架構強調基於領域的服務自治性。

從上述的對比來看，二者的區別基本上都在實現方式上。微服務與SOA本質上是同一種設計思想在不同時代的不同實現。過去在容器、K8S技術沒有出現的年代，造就了SOA的實現方式。

6. 雲原生

著名的CNCF（Cloud-Native Compute Foundation，雲原生計算基金會）成立於2015年，由Google等大公司牽頭，目前有100多家企業成員，其目的是在容器、微服務及devops領域里、通過一系列的規範和標準幫助企業和組織、在現代的雲化環境中構建架構一致的應用。

CNCF的Landscape定義了關於Provisioning、Runtime、容器編排、Paas平台、微服務治理等多個容器和微服務相關子領域的開源組件和技術標準。

簡單直白的講，基於CNCF雲原生技術開發的應用，能夠在業界各個平台里暢行無阻，部署在私有雲、公有雲里都是一樣的技術體系和架構。

從CNCF的Landscope上來看，進入CNCF的Landscope的組件，在功能、穩定性、活躍程度上大體都是業界領先的。

CNCF定義的雲原生三大特徵：

  • 容器化封裝：以容器為基礎，提高整體開發水平，形成代碼和組件重用，並作為應用程序部署的獨立單元。
  • 動態和自動化管理：通過集中式的編排調度系統來動態的管理和調度。即K8S。
  • 面向微服務：明確服務間的依賴，互相解耦。

總結來說，雲原生的三大特徵是：docker、kubernetes和微服務。此外，雲原生強調自動化以提升能夠開發效率和運維效率。

7. Devops

DevOps是Development和Operations的組合，重視軟體開發人員和運維人員的溝通合作，通過自動化流程來使得軟體構建、測試、發布更加迅速和可靠。

Devops與上述的雲原生、微服務、容器等技術應用沒有直接的關係，可以講，沒有微服務和容器等技術，一樣的可以朝著自動化的構建、測試和發布流程上行進。但是，長久以來，devops只是在文化上和流程指導上給出了方向，至於落地的方法論和工具鏈上，並沒有很成功，只是在CI/CD流程的個別環節上獨立發展出一些比較成功的產品，例如jenkins及一些自動化測試工具。究其原因，還是在軟體應用基礎架構上，沒有完善的技術支撐和技術體系，軟體的運行環境千差萬別、軟體的部署和維護流程千差萬別、軟體的形態和架構千差萬別，Devops落地需要大量定製化，工具鏈落地難度很大。

基於容器和Kubernetes的平台提供了雲原生應用的標準發布和運行環境；基於容器的微服務架構定義了雲原生應用的標準架構。通過這些技術，為軟體應用在架構、支撐服務和支持組件、基準平台上進行了標準化；同時通過這些技術，解決了升級、擴容、穩定性、私有雲/公有雲/混合雲統一基礎架構等問題。

微服務架構的重要目標就是：快速發布，那麼就需要在敏捷文化、自動化工具鏈上對流程提出了高要求。

在這個基礎上，利用devops的自動化文化、協作文化、敏捷文化，在軟體的開發、測試、部署、運維流程上，提升了開發效率、降低了溝通成本、提升了部署和上線速度。Devops是雲原生應用在開發、測試和發布流程上的必要手段，基於容器的Paas平台和微服務架構，為devops的流行提供了土壤。

總括：

微服務、容器、雲原生、Kubernetes、SOA、Paas平台、Devops 之間相互促進、相互依賴、相互關聯，它們之間的關係如下：

容器和微服務相關技術之間的關係

推薦閱讀：
相关文章