目錄
前言
原始分布式
單體架構(gòu)
煙囪式架構(gòu)
微內(nèi)核架構(gòu)
基于事件的架構(gòu)
SOA架構(gòu)
微服務(wù)
云原生
背景
如何做
虛擬化
容器編排
隨著軟硬件技術(shù)、行業(yè)規(guī)模、商業(yè)模式等的不斷發(fā)展，時(shí)刻對(duì)軟件提出新的要求，這就是架構(gòu)進(jìn)化的源動(dòng)力。
原始分布式背景
在很久以前，計(jì)算機(jī)剛經(jīng)歷了從大型機(jī)向以微型機(jī)的蛻變，逐漸開始面向商業(yè)企業(yè)中的生產(chǎn)設(shè)備、家庭、個(gè)人娛樂設(shè)備。此時(shí)的微型計(jì)算機(jī)系統(tǒng)通常具有 16 位寄存器、不足 5MHz 時(shí)鐘頻率的處理器，不超過(guò)1MB的大內(nèi)存和64KB單段偏移地址。
計(jì)算機(jī)硬件性能很差，已直接妨礙到了在單臺(tái)計(jì)算機(jī)上軟件能夠達(dá)到的大規(guī)模。為突破硬件算力限制，人們尋找使用多臺(tái)計(jì)算機(jī)共同協(xié)作來(lái)支撐同一套軟件系統(tǒng)運(yùn)行的可行方案。
如果你不能想象當(dāng)時(shí)的場(chǎng)景，不妨對(duì)比一下51單片機(jī)的性能：8位的cpu、12MHz時(shí)鐘頻率、KB級(jí)別內(nèi)存大小。
結(jié)果
受限于當(dāng)時(shí)的條件，以失敗而告終
成果
背景
20 世紀(jì) 80 年代，摩爾定律開始穩(wěn)定發(fā)揮作用，微型計(jì)算機(jī)的性能以每?jī)赡昙丛鲩L(zhǎng)一倍的驚人速度提升，硬件算力束縛軟件規(guī)模的鏈條很快變得松動(dòng)，進(jìn)入了以單臺(tái)或少量幾臺(tái)計(jì)算機(jī)即可作為服務(wù)器來(lái)支撐大型軟件運(yùn)作的單體時(shí)代。
實(shí)現(xiàn)
會(huì)把代碼分為三層，即通常提到的MVC，每層各司其職，層與層之間通過(guò)接口耦合，對(duì)某一層的改動(dòng)不會(huì)影響其它層。在每一層中，還會(huì)根據(jù)模塊不同而劃分出不同的目錄。
優(yōu)點(diǎn)
缺點(diǎn)
關(guān)鍵缺點(diǎn)：?jiǎn)误w架構(gòu)下所有組件運(yùn)行在同一個(gè)進(jìn)程下，隔離性差（性能隔離、故障隔離）。在以往的工作中曾發(fā)生多次事故，都與隔離性息息相關(guān)，比如：
反思
認(rèn)識(shí)到系統(tǒng)會(huì)出問題，且不可避免。需要通過(guò)拆分服務(wù)到不同機(jī)器上以獲取隔離性、自治性。
在拆分服務(wù)這條路上，人們經(jīng)過(guò)了多次嘗試，產(chǎn)生了多種架構(gòu)，今天成熟的微服務(wù)架構(gòu)不是一蹴而就的。
煙囪式架構(gòu)只是簡(jiǎn)單地將單體系統(tǒng)拆開，兩個(gè)系統(tǒng)之間不要通信，不要共享數(shù)據(jù)。然而事實(shí)上一個(gè)公司內(nèi)的系統(tǒng)之間確實(shí)需要通信，需要共享數(shù)據(jù)，需要建設(shè)公共平臺(tái)。如果強(qiáng)行煙囪，會(huì)造成數(shù)據(jù)孤島、重復(fù)建設(shè)等問題。
微內(nèi)核架構(gòu)既然在煙囪式架構(gòu)中，沒有業(yè)務(wù)往來(lái)關(guān)系的系統(tǒng)也可能需要共享人員、組織、權(quán)限等一些的公共的主數(shù)據(jù)，那不妨就將這些主數(shù)據(jù)，連同其他可能被各子系統(tǒng)使用到的公共服務(wù)、數(shù)據(jù)、資源集中到一塊，稱為微內(nèi)核。其它子系統(tǒng)/邏輯視為插件集成到微內(nèi)核中?；谶@種思想，決定了插件只能與微內(nèi)核通信，插件之間的通信沒有得到很好的滿足。常見的使用場(chǎng)景有IDE、web功能、用于研究目的的OS內(nèi)核。
優(yōu)缺點(diǎn)
| 評(píng)級(jí) | 分析 | ||
|---|---|---|---|
| 1 | 整體靈活性? | ? | 整體靈活性是指能夠快速適應(yīng)不斷變化的環(huán)境的能?。通過(guò)插件模塊的松耦合實(shí)現(xiàn)，可以將變化隔離起來(lái)，并且快速滿?需求。通常，微內(nèi)核架構(gòu)的核?系統(tǒng)很快趨于穩(wěn)定，這樣系統(tǒng)就變得很健壯，隨著時(shí)間的推移它也不會(huì)發(fā)?多?改變 |
| 2 | 易于部署 | ? | 根據(jù)實(shí)現(xiàn)?式，插件模塊能夠在運(yùn)?時(shí)被動(dòng)態(tài)地添加到核?系統(tǒng)中 （ ?如，熱部署 ）,把停機(jī)時(shí)間減到最? |
| 3 | 可測(cè)試性 | ? | 插件模塊能夠被獨(dú)?的測(cè)試，能夠?常簡(jiǎn)單地被核?系統(tǒng)模擬出來(lái)進(jìn)?演?，或者在對(duì)核?系統(tǒng)很?影響甚?沒有影響的情況下對(duì)?個(gè)特定的特性進(jìn)?原型展? |
| 4 | 性能 | ? | 使?微內(nèi)核架構(gòu)不會(huì)?然?然地使你的應(yīng)?變得?性能。通常，很多使?微內(nèi)核架構(gòu)的應(yīng)?運(yùn)?得很好，因?yàn)槟隳芏ㄖ坪秃?jiǎn)化應(yīng)?程序，使它只包含那些你需要的功能模塊。JBoss應(yīng)?服務(wù)器就是這??的優(yōu)秀?例: 依賴于它的插件化架構(gòu)，你可以只加載你需要的功能模塊，移除那些消耗資源但沒有使?的功能特性，?如遠(yuǎn)程訪問，消息傳遞，消耗內(nèi)存、CPU的緩存，以及線程，從?減?應(yīng)?服務(wù)器的資源消耗 |
| 5 | 伸縮性 | 低 | 因?yàn)槲?nèi)核架構(gòu)的實(shí)現(xiàn)是基于產(chǎn)品的，它通常都?較?。它們以獨(dú)?單元的形式實(shí)現(xiàn)，因此沒有太?的伸縮性。此時(shí)，伸縮性就取決于你的插件模塊，有時(shí)你可以在插件級(jí)別上提供可伸縮性，但是總的來(lái)說(shuō)這個(gè)架構(gòu)并不是以構(gòu)建?度伸縮性的應(yīng)??著稱的 |
| 6 | 易于開發(fā) | 低 | 微內(nèi)核架構(gòu)需要考慮設(shè)計(jì)和規(guī)約管理，使它不會(huì)很難實(shí)現(xiàn)。規(guī)約的版本控制，內(nèi)部的插件注冊(cè)，插件粒度，豐富的插件連接的?式等是涉及到這個(gè)架構(gòu)模式實(shí)現(xiàn)復(fù)雜度的重要因素 |
為了讓子系統(tǒng)之間方便通信，人們提出了基于事件的架構(gòu)。具體就是在系統(tǒng)之間架設(shè)一個(gè)公共的事件總線，每個(gè)系統(tǒng)都可以向其中發(fā)布事件，其他系統(tǒng)可以獲取并處理這個(gè)事件。MQ、內(nèi)存隊(duì)列都可以作為總線的實(shí)現(xiàn)方式，常見的框架有Spring Integration，RocketMQ...以及一些EventBus實(shí)現(xiàn)。
每個(gè)系統(tǒng)之間是高度解耦的，平等的，甚至可以起到削峰填谷的作用。但是過(guò)多地使用總線，會(huì)導(dǎo)致系統(tǒng)之間的邏輯關(guān)系變得隱晦。而且在某些對(duì)性能有高要求的場(chǎng)景中（例如OS內(nèi)核），這種架構(gòu)是不能滿足的。
服務(wù)拆分已經(jīng)發(fā)展到相對(duì)成熟的地步。于是有多個(gè)大廠參與，擁有專門的組織管理，針對(duì)分布式服務(wù)提出完整解決方案的SOA架構(gòu)就誕生了。它對(duì)分布式服務(wù)做了方方面面的規(guī)定，比如以下：
正因?yàn)镾OA對(duì)分布式服務(wù)做了方方面面的規(guī)定，想要解決所有問題，導(dǎo)致了它過(guò)于復(fù)雜。沒有程序員愿意使用如此復(fù)雜的技術(shù)。
微服務(wù)
背景
微服務(wù)作為SOA過(guò)于復(fù)雜的一個(gè)補(bǔ)救措施被提出，將微服務(wù)當(dāng)做SOA的一種擴(kuò)展。經(jīng)過(guò)多年發(fā)展，已經(jīng)形成一種獨(dú)立的架構(gòu)風(fēng)格。2014年是微服務(wù)崛起的一年，列出了微服務(wù)的核心特征：
至于微服務(wù)如何實(shí)現(xiàn)、包含哪些組件、優(yōu)缺點(diǎn)，這些在網(wǎng)上一搜一大把，這里就不再贅述了。
特點(diǎn)
與SOA對(duì)比，強(qiáng)約束 VS 軟指導(dǎo)、強(qiáng)一致 VS 自由、規(guī)范標(biāo)準(zhǔn) VS實(shí)踐標(biāo)準(zhǔn) ，頗有一點(diǎn)約定大于配置的意思。微服務(wù)提出了新的思想，更加自由，但是沒有帶來(lái)具體的東西（規(guī)范、協(xié)議、指導(dǎo)...）。那么SOA已經(jīng)解決的分布式問題又重新涌現(xiàn)了出來(lái)，以注冊(cè)中心為例，每個(gè)人都能說(shuō)出兩個(gè)，但如何選擇呢？
服務(wù)發(fā)現(xiàn)：Eureka、Consul、ZooKeeper、Etcd
遠(yuǎn)程調(diào)用：RMI、Dubbo、gRPC、brpc、JSON-RPC、rest
網(wǎng)關(guān)：zuul、gateway
如果要我們從頭搭建一個(gè)微服務(wù)架構(gòu)，恐怕我們需要對(duì)大多數(shù)框架都要了解，測(cè)試它們之間的兼容性，并編寫很多膠水代碼。幸運(yùn)的是，有SpringCloud這種保姆式框架，幫我們做了幾乎所有工作，而中大型公司則有專門的團(tuán)隊(duì)來(lái)維護(hù)這一套東西。
盡管微服務(wù)已經(jīng)成功地流行開來(lái)，但它卻是有史以來(lái)最復(fù)雜的架構(gòu)，遠(yuǎn)程通信、一致性、服務(wù)發(fā)現(xiàn)、熔斷降級(jí)、可觀測(cè)性......每一個(gè)都是需要深入了解原理，并在實(shí)戰(zhàn)中反復(fù)磨煉的，否則搭建出來(lái)的微服務(wù)非常脆弱，流量稍微大一點(diǎn)就車毀人亡了。架構(gòu)的進(jìn)化不會(huì)停止，而以后的進(jìn)化將會(huì)盡可能消除這些不穩(wěn)定因素。
云原生云原生三個(gè)字比較抽象，通常是媒體用來(lái)對(duì)外宣傳的用詞。要了解云原生，就要先了解背景。在這種背景下，出現(xiàn)了什么問題，采用了什么辦法解決。
背景在以上背景下，一種新的開發(fā)模式（軟件開發(fā)方式）開始流行，特征如下
微服務(wù)架構(gòu)能夠滿足‘新的開發(fā)模式’嗎，當(dāng)然不能！但我們要搞清楚為什么不能。微服務(wù)帶來(lái)了史無(wú)前例的復(fù)雜性，程序員不僅要關(guān)注業(yè)務(wù)邏輯，還要分心思在各種熔斷配置、服務(wù)注冊(cè)這種事情上，如何能做到快速迭代、更快的上線速度、快速定位解決問題？代碼直接部署在物理機(jī)上，與環(huán)境緊密地耦合在一起，發(fā)生問題時(shí)不僅要排查代碼，還要排查環(huán)境，如何做到故障快速回滾、快速水平擴(kuò)容？
以上問題正是云原生要解答的。首先了解以下關(guān)鍵技術(shù)：
虛擬化在一個(gè)物理機(jī)上運(yùn)行多個(gè)虛擬機(jī)（操作系統(tǒng)），每個(gè)虛擬機(jī)之間相互隔離
有以下兩個(gè)主要部分
以上是一個(gè)最基本的原理圖，看下有哪些工業(yè)實(shí)現(xiàn)
（1）完全虛擬化
VMM充當(dāng)中間層，其上運(yùn)行的VM感受不到VMM和其它OS，缺點(diǎn)是性能損耗較大。代表軟件有Xen
（2）半虛擬化
需要改造操作系統(tǒng)（下圖中淡黃色部分），使其能夠與VMM和其它OS通信，互相協(xié)作，這樣就減輕VMM模擬的負(fù)擔(dān)，性能更高。代表軟件有Xen
（3）操作系統(tǒng)層虛擬化
操作系統(tǒng)充當(dāng)VMM層，內(nèi)核中包含虛擬化技術(shù)模塊，模塊利用操作系統(tǒng)內(nèi)核的其他組件做大量工作。?代表軟件有KVM、virtualbox
（4）容器
容器技術(shù)其實(shí)屬于操作系統(tǒng)層虛擬化，但這里拿出來(lái)單獨(dú)講，因?yàn)樗窃圃囊粋€(gè)重要組成部分。容器，一種輕量級(jí)的虛擬化，提供單機(jī)上的隔離。最初作為隔離環(huán)境使用，現(xiàn)在作為軟件分發(fā)的載體。代表軟件有docker。
容器的實(shí)現(xiàn)依賴linux提供的以下功能
（a）隔離目錄：最開始使用unix系統(tǒng)提供的chroot命令，進(jìn)程只能訪問指定目錄
（b）隔離訪問：nameSpace
（c）隔離資源：cpu時(shí)間、內(nèi)存大小、磁盤速度
虛擬化總結(jié)
這里講的只是計(jì)算資源的虛擬化，廣義上虛擬化還包括存儲(chǔ)虛擬化、網(wǎng)絡(luò)虛擬化......
我們關(guān)注的是虛擬出來(lái)的OS，而不是物理機(jī)。虛擬機(jī)已經(jīng)是單純的軟件了，但從業(yè)務(wù)上看，它仍屬于硬件（基礎(chǔ)設(shè)施）的范疇。優(yōu)點(diǎn)如下：
需要重點(diǎn)關(guān)注容器，容器是操作系統(tǒng)層面虛擬化，它提供單機(jī)級(jí)別的環(huán)境隔離，而且非常輕量級(jí)，啟動(dòng)/停止速度快，占用資源少。我們的應(yīng)用以及依賴環(huán)境運(yùn)行在容器中，換句話說(shuō)，使用容器封裝了應(yīng)用和環(huán)境，這樣不僅讓我們對(duì)具體的環(huán)境解耦，而且對(duì)上層提供了統(tǒng)一接口，為接下來(lái)k8s登場(chǎng)提供了基礎(chǔ)。
容器編排上面已經(jīng)使用容器封裝了單個(gè)進(jìn)程，但是一個(gè)分布式應(yīng)用需要多個(gè)容器協(xié)作，通過(guò)集群的方式對(duì)外服務(wù)，實(shí)現(xiàn)這個(gè)目標(biāo)的過(guò)程就是容器編排。目前k8s在編排框架中占據(jù)主導(dǎo)地位。
k8s設(shè)計(jì)思想
（a）隔離與協(xié)作
容器封裝代表了隔離，但是兩個(gè)容器之間存在交互的需求。針對(duì)交互的頻繁或者依賴的多少，劃分為普通非親密、親密協(xié)作、超親密協(xié)作
上面提到了pod這里解釋一下，它相當(dāng)于組的概念，是虛擬的，不對(duì)應(yīng)任何實(shí)物。一個(gè)pod下可以有多個(gè)容器，調(diào)度時(shí)以pod為基本單位（pod下所有容器一定會(huì)被調(diào)度在同一個(gè)機(jī)器上）
可以看到上面有pod、node...層層嵌套
（b）韌性與彈性
我們希望得到一個(gè)健壯的系統(tǒng)，能夠抵御意外與風(fēng)險(xiǎn)：pod以外終止、流量突增、軟件崩潰。k8s能夠幫助程序員以最小的代價(jià)實(shí)現(xiàn)容錯(cuò)。
假設(shè)有一個(gè)由數(shù)十個(gè) Node、數(shù)百個(gè) Pod、近千個(gè) Container 所組成的分布式系統(tǒng)，要避免系統(tǒng)因?yàn)橥獠苛髁繅毫?、代碼缺陷、軟件更新、硬件升級(jí)、資源分配等各種原因而出現(xiàn)中斷，作為管理員，你希望編排系統(tǒng)能為你提供何種支持？
k8s將工業(yè)中控制回路的思想遷移到軟件中，如下圖所示
將container、pod、node等都視為資源，為資源附加兩個(gè)屬性：期望狀態(tài)、實(shí)際狀態(tài)。程序員描述清楚資源的期望狀態(tài)，由k8s中對(duì)應(yīng)監(jiān)視這些資源的控制器來(lái)驅(qū)動(dòng)資源的實(shí)際狀態(tài)逐漸向期望狀態(tài)靠攏，以此來(lái)達(dá)成目的。這種交互風(fēng)格被稱為是k8s的聲明式 API。
k8s如何使用資源、控制器。舉個(gè)例子，k8s支持下面三種情況
（1）Pod 出現(xiàn)故障時(shí)，能夠自動(dòng)恢復(fù)，不中斷服務(wù)
引入副本集（ReplicaSet）、副本集控制器（ReplicaSet Controller）概念，副本集也是一種資源，它下面包含多個(gè)pod，并且由副本集來(lái)創(chuàng)建pod。在副本集資源中描述我們期望的數(shù)量，那么副本集控制器就會(huì)持續(xù)監(jiān)視。如果有pod退出則新啟一個(gè)，如果有多余則回收。
（2）Pod 更新程序時(shí)，能夠滾動(dòng)更新，不中斷服務(wù)
引入部署（Deployment）與部署控制器概念，’部署‘也是一種資源，由’部署‘來(lái)創(chuàng)建副本集，副本集創(chuàng)建pod。在’部署‘中描述我們要的狀態(tài)，部署控制器就會(huì)持續(xù)監(jiān)視，并執(zhí)行以下步驟：自動(dòng)創(chuàng)建新副本集，同時(shí)逐漸縮減舊副本集，直至升級(jí)完成后徹底刪除掉舊副本集。
（3）Pod 遇到壓力時(shí)，能夠水平擴(kuò)展，不中斷服務(wù)
引入Autoscaling和自動(dòng)擴(kuò)縮控制器概念，Autoscaling也是一種資源，能夠根據(jù)一些指標(biāo)（內(nèi)存、cpu、自定義...）自動(dòng)設(shè)置’部署‘資源的描述期望值。當(dāng)壓力來(lái)臨時(shí)，按照Autoscaling→Deployment→ReplicaSet→Pod順序縮擴(kuò)容。
k8s除了提供以上特性，還提供了多樣的基礎(chǔ)設(shè)施。什么是基礎(chǔ)設(shè)施呢？是指支持應(yīng)用程序的所有軟件和硬件，包括操作系統(tǒng)、部署流水線、配置管理，以及支持應(yīng)用程序生命周期所需的任何系統(tǒng)或軟件。這些東西越下沉，越透明，對(duì)程序員越不可見，開發(fā)效率就會(huì)越高。聯(lián)想一下，在springCloud中，負(fù)載均衡、網(wǎng)關(guān)、注冊(cè)中心、鏈路追蹤這些東西是不是需要我們自己來(lái)處理，但是在k8s中，它提供了對(duì)應(yīng)的組件，只需配置即可使用，如下圖所示
而在基礎(chǔ)設(shè)施前面加上‘不可變’這個(gè)形容詞，說(shuō)的是基礎(chǔ)設(shè)施最好無(wú)狀態(tài)，才方便我們隨時(shí)橫向擴(kuò)展。
隨著k8s不斷發(fā)展，還出現(xiàn)了最近幾年大火的ServiceMesh（服務(wù)網(wǎng)格），它是在pod中注入一個(gè)sidecar，由它來(lái)挾持我們應(yīng)用的網(wǎng)絡(luò)，從而進(jìn)行管理（熔斷、連接數(shù)），最終使我們的應(yīng)用做到透明化的網(wǎng)絡(luò)調(diào)用。
k8s總結(jié)
微服務(wù)架構(gòu)帶來(lái)了巨大的復(fù)雜性，而云原生則努力將其下沉隱藏，并提供靈活性和擴(kuò)展性。k8s提供的故障恢復(fù)、滾動(dòng)更新、自動(dòng)擴(kuò)縮等能力，在云原生中常被概括成服務(wù)的彈性、可擴(kuò)展...能夠看出k8s的重要程度，所以某些資料甚至說(shuō)云原生是圍繞著k8s來(lái)建設(shè)的/k8s是云原生時(shí)代的操作系統(tǒng)?？聪孪旅婀俜綄?duì)云原生的定義，覺得抽象嗎？很多名詞已經(jīng)解釋過(guò)了。
云原生計(jì)算基金會(huì)（CNCF）2018：
云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。
這些技術(shù)能夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動(dòng)化手段，云原生技術(shù)使工程師能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測(cè)的重大變更------------------------------------------------------------------------------------------
首次提出云原生的Pivotal公司2017更早：
在我理解，云原生其實(shí)是一套解題思路，針對(duì)最開始提到的背景問題，給出了具體的可操作方法。如果你不能理解k8s所做工作的重要性，可能是工作年限稍短。以后的文章中將詳細(xì)講解底層技術(shù)的復(fù)雜性，如果把它們赤裸裸暴露給開發(fā)者， 將會(huì)是巨大的負(fù)擔(dān)。
后續(xù)章節(jié)：見該專欄的下篇文章
搭建k8s集群???????
你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級(jí)服務(wù)器適合批量采購(gòu)，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧
重慶分公司
重慶分公司
