作者：lixuefeng
轉(zhuǎn)載鏈接：https://zhuanlan.zhihu.com/p/74483850
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

IT軟件技術(shù)架構(gòu)進(jìn)入云化時(shí)代后，新概念、新技術(shù)大量涌現(xiàn)。從幾年前熱火的Openstack、計(jì)算存儲(chǔ)網(wǎng)絡(luò)三大虛擬化技術(shù)、Iaas平臺(tái)，到近幾年更火熱的容器和云原生的相關(guān)技術(shù)，在云計(jì)算這一領(lǐng)域新技術(shù)可謂是層出不窮。

我們經(jīng)常會(huì)聽到的這些概念，比如容器、docker、kubernetes、微服務(wù)架構(gòu)、PaaS平臺(tái)、服務(wù)中臺(tái)、Devops、云原生等等。這些技術(shù)和概念彼此之間感覺是獨(dú)立的，我們很容易從其中某一個(gè)角度學(xué)習(xí)入手并應(yīng)用；但是，很多時(shí)候，我們會(huì)發(fā)現(xiàn)這些技術(shù)彼此之間又有密切的關(guān)聯(lián)，從文章也好、技術(shù)落地應(yīng)用的場(chǎng)景也好，它們往往又出現(xiàn)在同一個(gè)地方。它們之間究竟有什么聯(lián)系，彼此之間有什么依賴，讓人十分的困惑。

在本文中，從這些技術(shù)彼此之間的依賴和關(guān)系入手，講述它們?cè)诋?dāng)今軟件云化和微服務(wù)化時(shí)代中的作用，希望讀者從這些總結(jié)對(duì)比入手，對(duì)微服務(wù)相關(guān)的技術(shù)體系建立全局性的視野和理解。

1. Docker容器：

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

• KVM等虛擬化技術(shù)是在操作系統(tǒng)級(jí)別上進(jìn)行虛擬和隔離，每一個(gè)虛機(jī)都是獨(dú)立的OS。
• 而docker是在同一個(gè)操作系統(tǒng)中，實(shí)現(xiàn)了輕量級(jí)的虛擬化?！拜p量級(jí)的虛擬化”怎么理解呢？看起來(lái)docker容器是獨(dú)立的操作系統(tǒng)，本質(zhì)上是同一個(gè)操作系統(tǒng)中的進(jìn)程隔離。所以它是輕量級(jí)的；從而，docker比KVM更省資源、資源利用率更高。

Docker的設(shè)計(jì)理念很偉大、作用也很偉大。但是docker的偉大性遠(yuǎn)不只是體現(xiàn)在“輕量的虛擬化”；docker的偉大性體現(xiàn)在：它實(shí)現(xiàn)了：同一個(gè)軟件發(fā)布，在不同的平臺(tái)上運(yùn)行。

這個(gè)好處是不是很熟悉？這其實(shí)就是Java最初流行起來(lái)的原因。Python語(yǔ)言為了實(shí)現(xiàn)這一點(diǎn)，弄出了VirtualEnv，把依賴包都隨著程序發(fā)布，才解決了多平臺(tái)運(yùn)行的問(wèn)題。Docker的設(shè)計(jì)很優(yōu)雅，一個(gè)應(yīng)用都打包成一個(gè)image格式，image采用分層技術(shù)等等，這部分不是本文的重點(diǎn)，大家希望更深入了解的話，可以參考其他資料。

2. Kubernetes

docker鏡像運(yùn)行起來(lái)是一個(gè)一個(gè)的程序，多個(gè)程序合起來(lái)做成一個(gè)大的分布式應(yīng)用怎么做呢？

答案很簡(jiǎn)單，一樣的，程序之間互相調(diào)用就行。就好比傳統(tǒng)的分布式應(yīng)用，多弄幾臺(tái)服務(wù)器，一個(gè)服務(wù)器上裝一個(gè)程序，程序之間通過(guò)socket或其他協(xié)議通信?；赿ocker的分布式應(yīng)用也是如此，區(qū)別只是網(wǎng)絡(luò)虛擬化了、CPU和內(nèi)存資源也虛擬化了。

但是永遠(yuǎn)不要低估分布式應(yīng)用的復(fù)雜性，舉兩個(gè)例子，想象我們搭建了一套分布式集群，運(yùn)行了一套分布式應(yīng)用：

• 這個(gè)集群中的某個(gè)機(jī)器出故障了（斷電了、硬盤壞了等等），怎么去排查故障、怎么去修復(fù)？
• 這個(gè)集群中某一部分業(yè)務(wù)由于訪問(wèn)量增加，需要擴(kuò)充支撐能力，怎么擴(kuò)充？

針對(duì)這兩個(gè)問(wèn)題，我們很容易想到答案，那就是人過(guò)去檢查機(jī)器、修復(fù)或者重裝，負(fù)載過(guò)大了，就改應(yīng)用的架構(gòu)，上面套上負(fù)載均衡性，采用可擴(kuò)展的架構(gòu)。這些都是傳統(tǒng)的辦法，這些解決辦法不好的地方也很明顯，就是修復(fù)太慢，太費(fèi)人力、成本高、對(duì)業(yè)務(wù)影響大，想象一個(gè)網(wǎng)站，等擴(kuò)展架構(gòu)都弄好了，用戶也就都流失了。

Kubernetes是容器編排系統(tǒng)，它首要的目的就是為了解決上面這個(gè)例子里的兩個(gè)問(wèn)題：

• 分布式容器應(yīng)用的可靠性，在服務(wù)器或容器應(yīng)用出現(xiàn)問(wèn)題的情況下，自動(dòng)感知，自動(dòng)將容器應(yīng)用在集群內(nèi)的其他機(jī)器里重新運(yùn)行起來(lái)
• 分布式容器應(yīng)用的可擴(kuò)展性，通過(guò)啟動(dòng)相同的容器應(yīng)用，自動(dòng)的提升應(yīng)用的負(fù)載支撐能力。

Google為了壓制AWS，把自己的容器運(yùn)行平臺(tái)開源出來(lái)，成為了現(xiàn)在的Kubernetes，這段歷史大家可以搜索了解一下。

3. PaaS

云計(jì)算的經(jīng)典理論上講三大層：IaaS、PaaS、SaaS，分布是Infrastructure、Platform、Software as a service。其中的Infrastructure指的是硬件資源虛擬化；Platform指的是軟件平臺(tái)，是應(yīng)用軟件運(yùn)行的基礎(chǔ)平臺(tái)。

為什么經(jīng)典理論要把PaaS這一層單獨(dú)拿出來(lái)？

SaaS層是直接面向業(yè)務(wù)用戶的，Iaas層是應(yīng)用運(yùn)行的底層物理資源，中間的PaaS是應(yīng)用運(yùn)行的標(biāo)準(zhǔn)平臺(tái)，它包括基礎(chǔ)數(shù)據(jù)庫(kù)服務(wù)、基礎(chǔ)中間件服務(wù)、基礎(chǔ)開發(fā)框架和開發(fā)套件、應(yīng)用部署、管理和運(yùn)維服務(wù)。通過(guò)PaaS平臺(tái)這一層，SaaS層更專注于自身的業(yè)務(wù)實(shí)現(xiàn)，運(yùn)行平臺(tái)和運(yùn)行中間件由PaaS層提供。

因?yàn)榍笆龅腒ubernetes的成熟程度以及無(wú)可比擬的優(yōu)勢(shì)，PaaS層的基礎(chǔ)架構(gòu)基本上都是采用Kubernetes。

有時(shí)候會(huì)聽到“中臺(tái)”這個(gè)概念，有數(shù)據(jù)層（叫做數(shù)據(jù)中臺(tái)）、技術(shù)組件層（叫做技術(shù)中臺(tái)）和業(yè)務(wù)層（業(yè)務(wù)中臺(tái)）。

中臺(tái)的概念出自于阿里巴巴。隨著企業(yè)規(guī)模的擴(kuò)大，集團(tuán)中形成了大的BU或部門，每個(gè)部門負(fù)責(zé)各自的業(yè)務(wù)體。這些業(yè)務(wù)體中有很多通用型的業(yè)務(wù)模塊，把這些通用的業(yè)務(wù)模塊拿出來(lái)，形成一個(gè)基礎(chǔ)的業(yè)務(wù)層，這個(gè)業(yè)務(wù)層由在組織結(jié)構(gòu)上相對(duì)獨(dú)立的部門來(lái)負(fù)責(zé)，這個(gè)部門負(fù)責(zé)的東西就是中臺(tái)。這便是中臺(tái)的起源。

業(yè)務(wù)層中臺(tái)這個(gè)概念泛化后，又演化出了數(shù)據(jù)中臺(tái)和技術(shù)中臺(tái)?，F(xiàn)在（2021年）可能各個(gè)大型政企集團(tuán)都在推進(jìn)其各自的“中臺(tái)戰(zhàn)略”，猜想其背后的一個(gè)很重要的原因可能是：這是一次組織結(jié)構(gòu)和權(quán)力分配變革的機(jī)遇，有機(jī)遇自然會(huì)有人去推進(jìn)。

image

PaaS中臺(tái)

4. 微服務(wù)

引述Sam Newman在Building Mircroservices一書中關(guān)于微服務(wù)的定義：

Microservices are small, autonomous services that work together.

引用前網(wǎng)飛云架構(gòu)負(fù)責(zé)人Adrian Cockcroft的定義：

Loosely coupled service-oriented architecture with bounded contexts.

我們這里定義為：微服務(wù)是可以獨(dú)立部署的、小的、自治的業(yè)務(wù)組件，業(yè)務(wù)組件彼此之間通過(guò)消息進(jìn)行交互。微服務(wù)的組件可以按需獨(dú)立伸縮，具備容錯(cuò)和故障恢復(fù)能力。

由于微服務(wù)架構(gòu)有下面這幾個(gè)優(yōu)勢(shì)，已經(jīng)成為云計(jì)算時(shí)代應(yīng)用的標(biāo)準(zhǔn)架構(gòu)：

• 支持快速上線。由于業(yè)務(wù)組件的自治性和獨(dú)立性，新的功能和應(yīng)用能夠迅速的發(fā)布上線，而不用擔(dān)心對(duì)系統(tǒng)其他功能帶來(lái)大范圍的影響和波及?？梢酝ㄟ^(guò)服務(wù)組件重用重組，快速的形成和發(fā)布新的應(yīng)用。
• 支持獨(dú)立擴(kuò)容和恢復(fù)。針對(duì)性的對(duì)應(yīng)用中的某些服務(wù)進(jìn)行擴(kuò)容，解決性能的瓶頸?？梢元?dú)立替換或恢復(fù)微服務(wù)中的某個(gè)組件。

快速上線-意味著速度和效率；獨(dú)立擴(kuò)容和恢復(fù)-意味著系統(tǒng)的安全、穩(wěn)定、可擴(kuò)展。采用微服務(wù)架構(gòu)體系的應(yīng)用在開發(fā)效率、穩(wěn)定性、可擴(kuò)展性上具備了無(wú)可比擬的優(yōu)勢(shì)，使其成為云化應(yīng)用的標(biāo)準(zhǔn)架構(gòu)。

由于微服務(wù)本身就是獨(dú)立發(fā)布、獨(dú)立部署、自治的、微小的服務(wù)，而docker容器也是跨平臺(tái)、獨(dú)立運(yùn)行、小的執(zhí)行單元。所以容器是微服務(wù)架構(gòu)的良好運(yùn)行載體。

微服務(wù)架構(gòu)中的核心功能組件包括網(wǎng)關(guān)、微服務(wù)治理、服務(wù)注冊(cè)、配置管理、限流和熔斷、負(fù)載均衡、自動(dòng)擴(kuò)容、自動(dòng)故障隔離、自動(dòng)業(yè)務(wù)恢復(fù)、監(jiān)控和日志組件等。

微服務(wù)架構(gòu)本質(zhì)上與容器及K8S技術(shù)無(wú)關(guān)，在Java體系的Spring Cloud就提供了諸如網(wǎng)關(guān)Zuul組件、Ribbon負(fù)載均衡組件、Eureka服務(wù)注冊(cè)組件、LCM擴(kuò)容組件、Hystrix業(yè)務(wù)恢復(fù)組件。利用Spring Cloud的能力可以實(shí)現(xiàn)一套完善的微服務(wù)架構(gòu)。Spring Cloud有大量的java開發(fā)人員所擁護(hù)，這是它的優(yōu)勢(shì)。但是Spring Cloud的劣勢(shì)很突出，那就是限制編程語(yǔ)言和編程技術(shù)。

Kubernetes提供了服務(wù)注冊(cè)、配置管理、負(fù)載均衡、故障隔離、業(yè)務(wù)恢復(fù)、自動(dòng)擴(kuò)容等能力。基于Kubernetes的Paas平臺(tái)又提供了諸如基礎(chǔ)數(shù)據(jù)服務(wù)、網(wǎng)關(guān)服務(wù)、微服務(wù)治理服務(wù)等基礎(chǔ)服務(wù)能力。此外，Kubernetes不限制編程語(yǔ)言，社區(qū)活躍、功能穩(wěn)定。所以可以講，kubernetes和Paas平臺(tái)是微服務(wù)技術(shù)的運(yùn)行平臺(tái)。

微服務(wù)架構(gòu)對(duì)應(yīng)用運(yùn)行平臺(tái)的依賴性很強(qiáng)，一個(gè)好的、功能全面、易用、穩(wěn)定的Paas平臺(tái)才能發(fā)揮出微服務(wù)架構(gòu)的優(yōu)勢(shì)。反之，如果沒有一個(gè)好的Paas平臺(tái)，應(yīng)用開發(fā)團(tuán)隊(duì)的大部分精力耗費(fèi)在平臺(tái)的搭建、利用，以及微服務(wù)架構(gòu)的設(shè)計(jì)和應(yīng)用維護(hù)上。那樣的話，不僅沒有得到利用微服務(wù)架構(gòu)的好處，反而沉陷于利用微服務(wù)架構(gòu)所帶來(lái)的技術(shù)挑戰(zhàn)和劣勢(shì)當(dāng)中。

總的來(lái)說(shuō)，微服務(wù)架構(gòu)是一個(gè)“重平臺(tái)、輕應(yīng)用”的架構(gòu)，從應(yīng)用軟件整體來(lái)看，相比較傳統(tǒng)架構(gòu)，平臺(tái)的研發(fā)投入比重占的很大。利用成熟穩(wěn)定的商業(yè)化Paas平臺(tái)是成本最優(yōu)的方案。

5. SOA

SOA（Service-Oriented-Architecture）面向服務(wù)的架構(gòu)，是把服務(wù)拼裝形成應(yīng)用整體的架構(gòu)。SOA中的服務(wù)是指“可重用的業(yè)務(wù)模塊”。

微服務(wù)架構(gòu)與SOA很像，同樣都是將整個(gè)應(yīng)用拆分，形成獨(dú)立的業(yè)務(wù)模塊的思路。但在許多關(guān)鍵點(diǎn)上，微服務(wù)架構(gòu)與SOA不同。

image

SOA架構(gòu)與微服務(wù)架構(gòu)對(duì)比

• SOA很大程度上依賴于基于XML的消息格式和基于SOAP的通信協(xié)議，微服務(wù)架構(gòu)大量的依賴于REST和JSON。
• SOA架構(gòu)中有ESB（服務(wù)總線）的概念，ESB負(fù)責(zé)服務(wù)之間的通信轉(zhuǎn)發(fā)和接口適配，在SOA實(shí)現(xiàn)中，ESB處于核心地位，有很多專業(yè)的ESB廠商提供ESB中間件，例如WebSphere ESB、Oracle ESB、Dubbo等。
• ESB本身是非?！爸亍钡募夹g(shù)，在云化軟件體系和微服務(wù)架構(gòu)中，強(qiáng)調(diào)更輕量級(jí)、更迅速、去中心化的技術(shù)，所以在微服務(wù)架構(gòu)中，不需要ESB，而通過(guò)API網(wǎng)關(guān)這樣的技術(shù)來(lái)負(fù)責(zé)服務(wù)接口轉(zhuǎn)發(fā)。（由于軟件全面云化是一個(gè)過(guò)程、需要適配、調(diào)整來(lái)全面完成轉(zhuǎn)變，所以在一段時(shí)間內(nèi)，面對(duì)大量的遺留系統(tǒng)，ESB仍然會(huì)充當(dāng)微服務(wù)改造過(guò)程中用來(lái)適配老系統(tǒng)的一個(gè)重要組件。）
• SOA的設(shè)計(jì)思路是把一些組件和服務(wù)，通過(guò)服務(wù)總線組裝，形成更大的應(yīng)用系統(tǒng)（從小到大）；而微服務(wù)的設(shè)計(jì)思路是把應(yīng)用拆分成獨(dú)立自治的小的服務(wù)（從大到小）。
• SOA設(shè)計(jì)架構(gòu)強(qiáng)調(diào)分層，通常會(huì)分為展現(xiàn)層、業(yè)務(wù)層、總線層和數(shù)據(jù)層。微服務(wù)架構(gòu)中的服務(wù)更松散。
• SOA中的服務(wù)不強(qiáng)調(diào)業(yè)務(wù)領(lǐng)域的自治性，微服務(wù)架構(gòu)強(qiáng)調(diào)基于領(lǐng)域的服務(wù)自治性。

從上述的對(duì)比來(lái)看，二者的區(qū)別基本上都在實(shí)現(xiàn)方式上。微服務(wù)與SOA本質(zhì)上是同一種設(shè)計(jì)思想在不同時(shí)代的不同實(shí)現(xiàn)。過(guò)去在容器、K8S技術(shù)沒有出現(xiàn)的年代，造就了SOA的實(shí)現(xiàn)方式。

6. 云原生

著名的CNCF（Cloud-Native Compute Foundation，云原生計(jì)算基金會(huì)）成立于2015年，由Google等大公司牽頭，目前有100多家企業(yè)成員，其目的是在容器、微服務(wù)及devops領(lǐng)域里、通過(guò)一系列的規(guī)范和標(biāo)準(zhǔn)幫助企業(yè)和組織、在現(xiàn)代的云化環(huán)境中構(gòu)建架構(gòu)一致的應(yīng)用。

CNCF的Landscape定義了關(guān)于Provisioning、Runtime、容器編排、Paas平臺(tái)、微服務(wù)治理等多個(gè)容器和微服務(wù)相關(guān)子領(lǐng)域的開源組件和技術(shù)標(biāo)準(zhǔn)。

簡(jiǎn)單直白的講，基于CNCF云原生技術(shù)開發(fā)的應(yīng)用，能夠在業(yè)界各個(gè)平臺(tái)里暢行無(wú)阻，部署在私有云、公有云里都是一樣的技術(shù)體系和架構(gòu)。

從CNCF的Landscope上來(lái)看，進(jìn)入CNCF的Landscope的組件，在功能、穩(wěn)定性、活躍程度上大體都是業(yè)界領(lǐng)先的。

CNCF定義的云原生三大特征：

• 容器化封裝：以容器為基礎(chǔ)，提高整體開發(fā)水平，形成代碼和組件重用，并作為應(yīng)用程序部署的獨(dú)立單元。
• 動(dòng)態(tài)和自動(dòng)化管理：通過(guò)集中式的編排調(diào)度系統(tǒng)來(lái)動(dòng)態(tài)的管理和調(diào)度。即K8S。
• 面向微服務(wù)：明確服務(wù)間的依賴，互相解耦。

總結(jié)來(lái)說(shuō)，云原生的三大特征是：docker、kubernetes和微服務(wù)。此外，云原生強(qiáng)調(diào)自動(dòng)化以提升能夠開發(fā)效率和運(yùn)維效率。

7. Devops

DevOps是Development和Operations的組合，重視軟件開發(fā)人員和運(yùn)維人員的溝通合作，通過(guò)自動(dòng)化流程來(lái)使得軟件構(gòu)建、測(cè)試、發(fā)布更加迅速和可靠。

Devops與上述的云原生、微服務(wù)、容器等技術(shù)應(yīng)用沒有直接的關(guān)系，可以講，沒有微服務(wù)和容器等技術(shù)，一樣的可以朝著自動(dòng)化的構(gòu)建、測(cè)試和發(fā)布流程上行進(jìn)。但是，長(zhǎng)久以來(lái)，devops只是在文化上和流程指導(dǎo)上給出了方向，至于落地的方法論和工具鏈上，并沒有很成功，只是在CI/CD流程的個(gè)別環(huán)節(jié)上獨(dú)立發(fā)展出一些比較成功的產(chǎn)品，例如jenkins及一些自動(dòng)化測(cè)試工具。究其原因，還是在軟件應(yīng)用基礎(chǔ)架構(gòu)上，沒有完善的技術(shù)支撐和技術(shù)體系，軟件的運(yùn)行環(huán)境千差萬(wàn)別、軟件的部署和維護(hù)流程千差萬(wàn)別、軟件的形態(tài)和架構(gòu)千差萬(wàn)別，Devops落地需要大量定制化，工具鏈落地難度很大。

基于容器和Kubernetes的平臺(tái)提供了云原生應(yīng)用的標(biāo)準(zhǔn)發(fā)布和運(yùn)行環(huán)境；基于容器的微服務(wù)架構(gòu)定義了云原生應(yīng)用的標(biāo)準(zhǔn)架構(gòu)。通過(guò)這些技術(shù)，為軟件應(yīng)用在架構(gòu)、支撐服務(wù)和支持組件、基準(zhǔn)平臺(tái)上進(jìn)行了標(biāo)準(zhǔn)化；同時(shí)通過(guò)這些技術(shù)，解決了升級(jí)、擴(kuò)容、穩(wěn)定性、私有云/公有云/混合云統(tǒng)一基礎(chǔ)架構(gòu)等問(wèn)題。

微服務(wù)架構(gòu)的重要目標(biāo)就是：快速發(fā)布，那么就需要在敏捷文化、自動(dòng)化工具鏈上對(duì)流程提出了高要求。

在這個(gè)基礎(chǔ)上，利用devops的自動(dòng)化文化、協(xié)作文化、敏捷文化，在軟件的開發(fā)、測(cè)試、部署、運(yùn)維流程上，提升了開發(fā)效率、降低了溝通成本、提升了部署和上線速度。Devops是云原生應(yīng)用在開發(fā)、測(cè)試和發(fā)布流程上的必要手段，基于容器的Paas平臺(tái)和微服務(wù)架構(gòu)，為devops的流行提供了土壤。

總括：

微服務(wù)、容器、云原生、Kubernetes、SOA、Paas平臺(tái)、Devops 之間相互促進(jìn)、相互依賴、相互關(guān)聯(lián)，它們之間的關(guān)系如下：

image

容器和微服務(wù)相關(guān)技術(shù)之間的關(guān)系

延伸閱讀 云原生 （Cloud Native） = 微服務(wù) + DevOps + 持續(xù)交付 + 容器化 ？
https://blog.csdn.net/universsky2015/article/details/102764899?utm_medium=distribute.pc_relevant.none-task-blog-2_defaultbaidujs_baidulandingword~default-0.essearch_pc_relevant&spm=1001.2101.3001.4242.1