本文分享自百度開發者中心微服務、容器、雲原生、Kubernetes、SOA、PaaS平臺、Devops 之間的關係html
IT軟件技術架構進入雲化時代後，新概念、新技術大量涌現。從幾年前熱火的Openstack、計算存儲網絡三大虛擬化技術、Iaas平臺，到近幾年更火熱的容器和雲原生的相關技術，在雲計算這一領域新技術可謂是層出不窮。java
咱們常常會聽到的這些概念，好比容器、docker、kubernetes、微服務架構、PaaS平臺、服務中臺、Devops、雲原生等等。這些技術和概念彼此之間感受是獨立的，咱們很容易從其中某一個角度學習入手並應用；可是，不少時候，咱們會發現這些技術彼此之間又有密切的關聯，從文章也好、技術落地應用的場景也好，它們每每又出如今同一個地方。它們之間究竟有什麼聯繫，彼此之間有什麼依賴，讓人十分的困惑。docker
在本文中，從這些技術彼此之間的依賴和關係入手，講述它們在當今軟件雲化和微服務化時代中的做用，但願讀者從這些總結對比入手，對微服務相關的技術體系創建全局性的視野和理解。數據庫
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。
有時候會聽到「中臺」這個概念，有數據層（叫作數據中臺）、技術組件層（叫作技術中臺）和業務層（業務中臺）。
中臺的概念出自於阿里巴巴。隨着企業規模的擴大，集團中造成了大的BU或部門，每一個部門負責各自的業務體。這些業務體中有不少通用型的業務模塊，把這些通用的業務模塊拿出來，造成一個基礎的業務層，這個業務層由在組織結構上相對獨立的部門來負責，這個部門負責的東西就是中臺。這即是中臺的起源。
業務層中臺這個概念泛化後，又演化出了數據中臺和技術中臺。如今（2020年）可能各個大型政企集團都在推動其各自的「中臺戰略」，猜測其背後的一個很重要的緣由多是：這是一次組織結構和權力分配變革的機遇，有機遇天然會有人去推動。
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很大程度上依賴於基於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 之間相互促進、相互依賴、相互關聯，它們之間的關係以下：