之前寫過關(guān)于微服務(wù)架構(gòu)的文章，發(fā)現(xiàn)挺受歡迎的，所以今天打算再聊聊云原生和微服務(wù)架構(gòu)。

[[438314]]

圖片來自 包圖網(wǎng)

本篇分享主要圍繞以下 4 個主題進行：

• 什么是云原生?
• 為什么要用云原生架構(gòu)?
• 微服務(wù)的概念
• 微服務(wù)的技術(shù)選型

什么是云原生?

①云計算和云原生

云計算不同于傳統(tǒng)的自建機房，云計算就是將計算的抽象為基礎(chǔ)設(shè)施然后通過網(wǎng)絡(luò)分發(fā)。

得益于云計算的無限擴展能力，使得“云計算”就像自來水廠一樣，我們可以隨時接水，并且不限量，按照自己家的用水量，付費給自來水廠就可以。

以下云計算的五個基本特征：

以下是一些目前比較主流的公有云廠商：

云原生顧名思義，就是基于云計算特性所設(shè)計的應(yīng)用服務(wù)，得益于云計算快速發(fā)展，基于云計算特性所設(shè)計的云原生應(yīng)用相比傳統(tǒng)的單體應(yīng)用在安全性，擴展性，快速迭代，運維等各方便都有巨大的領(lǐng)先優(yōu)勢。

云原生并不是指某一種技術(shù)，它是一種架構(gòu)設(shè)計理念，只要符合這種架構(gòu)設(shè)計理念的應(yīng)用，都可以稱為云原生應(yīng)用。

看看 CNCF 官方對于云原生的定義：

②容器云技術(shù)的發(fā)展

虛擬化技術(shù)的發(fā)展歷史

云原生是依賴容器作為技術(shù)技術(shù)來實現(xiàn)的，但是容器并不是什么新潮技術(shù)，以下是容器云技術(shù)的發(fā)展歷史，其中有幾個關(guān)鍵的歷史節(jié)點：

早在 2006 年的時候 Amazon 基于容器技術(shù)構(gòu)建的 IaaS 平臺 AWS，成為所有云計算廠商的鼻祖，由于技術(shù)領(lǐng)先的優(yōu)勢 AWS 現(xiàn)在依然也是云計算行業(yè)老大。

2013 年 Docker 的誕生進一步簡化容器技術(shù)的使用門檻，Docker 公司自以為掌握云時代的核心技術(shù)，開始野心勃勃的有意挑戰(zhàn)傳統(tǒng)的云計算大廠，例如 RedHat，Google 的江湖地位，公司股價也是一騎絕塵，卻不料被 RedHat 聯(lián)合 Google 發(fā)布的 Kubernetes 擊潰，Kubernetes 的成功讓大家以為容器技術(shù)并非云時代的核心技術(shù)，容器編排才是核心技術(shù)。(備注：2020 年 K8S 官方宣布只要滿足 K8S CRI 接口的容器均可以被 K8S 進行編排，Docker 被時代拋棄)

2015 年借助 Kubernetes 的成功，Google 宣布成立 CNCF 基金會，這是云原生時代的代表性的組織。致力于完善云時代的基礎(chǔ)設(shè)施，幫助開發(fā)者構(gòu)建更出色的產(chǎn)品

下圖是 CNCF 的全景圖：

為什么用云原生架構(gòu)?

主要從 4 個方面來聊聊：

• 自動恢復(fù)
• 服務(wù)安全
• 彈性擴展
• 快速發(fā)布

①自動恢復(fù)

早期剛參加工作的時候接手過一個年久失修的遺留系統(tǒng)，這個系統(tǒng)有一個很神奇的 Bug 每天晚上會自動宕機，誰也不知道什么原因。

只要重啟就能恢復(fù)正常，當(dāng)時為了保證業(yè)務(wù)系統(tǒng)的正常使用，我總是在半夜爬起來重啟服務(wù)器，我當(dāng)時就在想：要是有一種工具可以檢測到系統(tǒng)宕機后，就自動重啟恢復(fù)就好了，這樣我就可以睡一個好覺了。

這就是云原生架構(gòu)想要解決的第一個問題：應(yīng)用系統(tǒng)掛掉后，無需人工的介入，可以自動在最短的時間恢復(fù)來保證系統(tǒng)的健壯性。

當(dāng)然除了未知的 Bug，還有詭異的異常會導(dǎo)致服務(wù)崩潰了，例如：

• 代碼沒寫好，系統(tǒng)發(fā)生 OOM
• 服務(wù)器本身的資源不足
• 死鎖，磁盤，網(wǎng)絡(luò)等問題
• 等等……

Kubernetes Pod 應(yīng)用自動恢復(fù)的三種策略：

• Always：當(dāng)容器終止退出后，總是重啟容器，默認策略。
• OnFailure：當(dāng)容器異常退出(退出狀態(tài)碼非 0)時，才重啟容器。
• Never：當(dāng)容器終止退出，從不重啟容器。

spec:  
  restartPolicy: Always # 當(dāng)容器終止退出后，總是重啟容器，默認策略 
  containers:  
  - image: nginx 
    name: web  

②安全性

在微服務(wù)架構(gòu)的大型分布式系統(tǒng)，服務(wù)和服務(wù)之間是通過熔斷建立安全的保護隔離機制。

云原生架構(gòu)保障系統(tǒng)的安全性主要體現(xiàn) 2 個方面：

• 服務(wù)隔離
• 資源隔離

服務(wù)隔離：先來看看服務(wù)調(diào)用的安全隔離，如圖：

假如服務(wù) A 和服務(wù) B 之間存在依賴的調(diào)用關(guān)系，它的處理邏輯如下：

• 如果服務(wù) B 宕機或者異常下線，注冊中心會發(fā)送服務(wù) B 的狀態(tài)給服務(wù) A，服務(wù) A 就會啟動熔斷保護機制。
• 服務(wù) A 采用降級策略或者不再發(fā)送向服務(wù) B 發(fā)送請求，避免產(chǎn)生調(diào)用鏈雪崩，同時也保護服務(wù) A 的可用性。
• 服務(wù) B 再次被拉起的時候，服務(wù) A 收到注冊中心對服務(wù) B 的健康檢查，恢復(fù)對服務(wù) B 的調(diào)用或者移除降級策略。

資源隔離：云原生架構(gòu)對于服務(wù)的保護機制也體現(xiàn)在對資源的使用上，以前多套系統(tǒng)共享一臺主機的資源，總是容易出現(xiàn)木桶的短板效應(yīng)。

就是只要有一個系統(tǒng)把主機資源占滿，那么其他的系統(tǒng)都會因為資源不足受到影響。進而產(chǎn)生連鎖反應(yīng)，同主機上的所有系統(tǒng)都會崩潰。

現(xiàn)在基于容器部署的微服務(wù)系統(tǒng)，你的系統(tǒng)在生產(chǎn)環(huán)境的真實部署情況就像被關(guān)進一個個小房間里面，預(yù)先安排的資源設(shè)置就是這個服務(wù)房間的大小。

它只能在指定的大小范圍內(nèi)活動，就算程序內(nèi)部異常導(dǎo)致把資源全部占用，也不會影響其他房間的小伙伴的正?；顒?，從而保證整個系統(tǒng)的可用性。

通過 Kubernetes 指定內(nèi)存請求和限制的 Pod 配置文件：

spec: 
  containers: 
  - name: memory-demo-ctr 
    image: polinux/stress 
    resources: 
      limits: 
        memory: "200Mi"  # 內(nèi)存會被限制在 200 MiB 以內(nèi) 
      requests: 
        memory: "100Mi"  # 容器將會請求 100 MiB 內(nèi)存 

通過服務(wù)隔離，資源隔離的方式為云原生系統(tǒng)提供安全和可用性，這里僅僅做一個入門的介紹，如果展開來講的話，內(nèi)容還有很多，有興趣的同學(xué)可以自行去研究和探索。

③彈性擴展

傳統(tǒng)的單體的應(yīng)用，往往部署在機房的服務(wù)器主機內(nèi)，那么自購的服務(wù)器難以應(yīng)對業(yè)務(wù)快速增長，存在以下問題：

• 時間成本：采購服務(wù)器需要事先填好配置清單，走各種流程，等物流，等機器送到接上電源，估計 1~2 周都過去了。
• 空間成本：要騰出很大的空間來放置這些大家伙。
• 其他成本：24 小時開空調(diào)，專人輪班值守，機器的維護，服務(wù)下線后服務(wù)器容易閑置，閑魚不好出手等等。

在基于云計算的基本特征所設(shè)計的云原生系統(tǒng)，則不存在以上這些問題，在主流的公有云廠商提供 ECS 主機基本可以任意擴展和伸縮配置，在資源使用上也提供按量付費的運行模式，有效避免對于計算資源的限制和浪費。

如下圖：

④快速發(fā)布

隨著類似 Kubernetes 等云原生基礎(chǔ)設(shè)置的完善，現(xiàn)代應(yīng)用的部署方式也跟以前大不相同。

相比傳統(tǒng)低效的停機發(fā)布，云原生服務(wù)提供的 Rolling Update 滾動升級幫我們實現(xiàn)不停機升級系統(tǒng)的目標(biāo)，對于需要快速響應(yīng)市場需求的企業(yè)，快速迭代的業(yè)務(wù)系統(tǒng)的功能對于企業(yè)取得市場競爭力顯得來說尤為重要。

KubernetesRollingUpdate 策略用于解決不停機發(fā)布的問題：

另外，我們可以通過 kubectl rollout undo 將 deployment 回滾到指定的版本，來解決微服務(wù)的快速回滾的問題。

以上就是云原生架構(gòu)相比傳統(tǒng)系統(tǒng)所帶來的巨大優(yōu)勢，我們目前也是處于云時代架構(gòu)演進的早期。

我個人認為，我們程序員作為知識工作者非常值得投入時間去學(xué)習(xí)下一代的主流架構(gòu)設(shè)計。這將為我們帶來巨大的技術(shù)優(yōu)勢和技術(shù)領(lǐng)先。

微服務(wù)的概念

①微服務(wù)的理論基礎(chǔ)

微服務(wù)并不特指某一種具體的技術(shù)，它是一個抽象的概念，只要滿足它的所有規(guī)范，那么就可以理解為你的系統(tǒng)實現(xiàn)了微服務(wù)。

②何時用微服務(wù)?

關(guān)于你的項目何時應(yīng)該引入微服務(wù)架構(gòu)，行業(yè)一直有兩種聲音：

• 方案 A 單體優(yōu)先：隨著架構(gòu)的演進逐漸替換為微服務(wù)架構(gòu)
• 方案 B 微服務(wù)優(yōu)先：避免后期的大范圍架構(gòu)重構(gòu)

其實，早在 2015 年技術(shù)大牛 Martin Fowler 在博客文章 MicroservicePremium 中就給出了具備參考性答案：

早期(2015 年左右)微服務(wù)使用成本和上手門檻很高，生產(chǎn)效率不如單體應(yīng)用。

但是伴隨系統(tǒng)的業(yè)務(wù)復(fù)雜度逐漸上升，單體應(yīng)用的生產(chǎn)效率逐漸降低，在到達臨界點的時候微服務(wù)的優(yōu)勢逐漸出現(xiàn)，微服務(wù)的生產(chǎn)效率開始超過單體應(yīng)用。

所以在 2015 年的時候結(jié)合成本和收益的權(quán)衡，大多數(shù)人會選擇單體優(yōu)先的架構(gòu)方案，后續(xù)再逐步演化成為微服務(wù)。

③Netflix OSS 的誕生

早在 2015 年的 CNCF 基金會剛誕生，社區(qū)的微服務(wù)基礎(chǔ)設(shè)置非常不完善，Netflix+Pivotal 公司作為微服務(wù)的實踐的探索者，通過應(yīng)用層面提供許多微服務(wù)的基礎(chǔ)組件來實現(xiàn)微服務(wù)架構(gòu)。

關(guān)于 Netflix 提供的微服務(wù)全家桶解決方案稱作 Netflix OSS(Open Source Software Center)。

Netflix OSS 全景圖如下：

④微服務(wù)優(yōu)先

Martin Fowler 在 2015 年提出的觀點，顯然已經(jīng)不再適用 2021 的現(xiàn)代系統(tǒng)架構(gòu)。

這幾年隨著 CNCF 的快速發(fā)展，云原生的基礎(chǔ)設(shè)施逐漸的完善和成熟，微服務(wù)的使用成本逐年降低，微服務(wù)的實現(xiàn)成本已經(jīng)趨向于單體，甚至未來會優(yōu)于單體。

我的個人看法是，微服務(wù)如果能夠解決使用和學(xué)習(xí)成本的問題，那么未來微服務(wù)也將完全取代單體應(yīng)用。

從長期主義來說，任何新項目都應(yīng)該優(yōu)先選擇微服務(wù)架構(gòu)，不僅可以保證業(yè)務(wù)系統(tǒng)的生產(chǎn)效率、擴展性，還可以避免未來產(chǎn)生大規(guī)模的重構(gòu)。

微服務(wù)的技術(shù)選型

①微服務(wù)框架選擇

市面上微服務(wù)框架很多，目前行業(yè)的大公司基本都會有自己的微服務(wù)框架。

我們只看幾款主流并且具備代表性微服務(wù)框架：

• Dubbo(阿里巴巴)
• Spring Cloud(Netflix)
• Kubernetes(Google)

我們通過功能對比，看看都是如何根據(jù)自己的理解實現(xiàn)微服務(wù)的基本理論概念。

我們將主流框架從微服務(wù)的基礎(chǔ)關(guān)注點，運維架構(gòu)，產(chǎn)品背景進行三方面維度的比較：

通過橫向?qū)Ρ?，我們可以看到不論?Dubbo 還是 Spring Cloud 對比 Kubernetes 都有諸多缺點。

相比阿里巴巴的 Dubbo、Netflix 的 Spring Cloud，Google 提供的 Kubernetes 才是具備完整的一站式的微服務(wù)解決方案的技術(shù)方案。

如下圖：

如果使用住房來比喻的話，前者就像毛坯房，還要自己裝修，Kubernetes 則是精裝修的商品房，幫你解決所有問題，拎包入駐即可。

另外，自建 Kubernetes 集群成本比較高，推薦使用公有云廠商提供的 Kubernetes 服務(wù)。

②微服務(wù)和網(wǎng)關(guān)

如果把分布式的微服務(wù)系統(tǒng)比喻成一家公司的話，那么網(wǎng)關(guān)就是該公司的前臺，當(dāng)有用戶要訪問公司必須在前臺登記確認身份，疫情期間可能還需要量一下體溫什么的。

這一步驟就叫網(wǎng)關(guān)鑒權(quán)，根據(jù)用戶描述的任務(wù)和身上攜帶的證明，網(wǎng)關(guān)用戶的業(yè)務(wù)類型將用戶帶到所屬業(yè)務(wù)范圍內(nèi)辦公室，這一步驟就叫做網(wǎng)關(guān)路由。

如果用戶太多一個前臺處理不過來，就會多開設(shè)幾個窗口來分流，這一步驟就叫做 網(wǎng)關(guān)層面的負載均衡。網(wǎng)關(guān)是微服務(wù)的大門，對于微服務(wù)至關(guān)重要。

以下是網(wǎng)關(guān)常見的工作方式：

除了上述的鑒權(quán)，動態(tài)路由，負載均衡，通過網(wǎng)關(guān)還可以實現(xiàn)以下高級特性：

• 網(wǎng)關(guān)限流(人太多，把門關(guān)起來，或者在門口排隊)
• 金絲雀發(fā)布(將小部分用戶帶到還未開放的新辦公場地去體驗一下)
• 彈性伸縮

網(wǎng)關(guān)是微服務(wù)的大門，因為網(wǎng)關(guān)對于對微服務(wù)來說至關(guān)重要，是微服務(wù)彈性伸縮的能力來源。

并且網(wǎng)關(guān)的開發(fā)成本其實并不高，所以市場面有很多單獨的網(wǎng)關(guān)產(chǎn)品，我們可以簡單看看，如圖：

③微服務(wù)和安全認證

早期分布式單體應(yīng)用的會話管理：早期的單體應(yīng)用用戶會話方案都是通過服務(wù)端存儲 sessionid+cookid+filter 來保存和管理用戶狀態(tài)會話。

但是這種有狀態(tài)服務(wù)有很多弊端，例如服務(wù)重啟用戶狀態(tài)丟失，難以橫向擴展等等，后單體應(yīng)用時代大家開始把用戶會話狀態(tài)放在類似 Redis 等存儲中間件中，來解決系統(tǒng)的橫向擴展和重啟后會話不丟失的問題。

架構(gòu)如圖：

微服務(wù)中基于 Auth 的認證方案：在的微服務(wù)體系中，身份認證模塊將被統(tǒng)一抽取出來交給單獨的服務(wù)處理，該服務(wù)通常稱為 Auth Service。

訪問令牌通常由 Auth 頒發(fā)，由網(wǎng)關(guān)統(tǒng)一鑒權(quán)，AuthService 身份認證職責(zé)的分離，可以讓微服務(wù)本身更加關(guān)注業(yè)務(wù)。

基于 Auth Service 的工作邏輯如圖：

不過這種基于 Auth 認證服務(wù)的方案會將所有請求發(fā)往 Auth 進行驗證，認證服務(wù)承受的壓力大，架構(gòu)方案重，造成不必要的性能損失。其實大部分的應(yīng)用系統(tǒng)都不需要這么嚴(yán)格的安全認證等級。

那么有沒有一種輕量級的技術(shù)是可以由認證服務(wù)頒發(fā)令牌后，不在需要依賴 Auth 鑒權(quán)，由服務(wù)自行驗證令牌的有效性，這樣就可以大大減少對 Auth 的鑒權(quán)請求。答案是有的。它就是目前非常流行的 JWT 鑒權(quán)方案。

JWT 結(jié)合 RBAC 角色權(quán)限模型是目前非常主流的輕量級認證方案。它的工作流程如下：

JWT 備受推崇，廣泛使用的原因，是因為它在由 Auth 服務(wù)頒發(fā)令牌后，在網(wǎng)關(guān)即可驗證令牌合法性，無需再請求認證服務(wù)，請求少，性能好。

令牌本身還可以自包含少量的用戶信息，JWT 大概是一串這樣的編碼，它由三個部分組成，你可以通過 JWT IO 這個網(wǎng)站對 JWT 進行解碼，從而獲取 JWT 中的信息：

JWT 的詳細生成和解碼過程就這里不在贅述了，JWT 并非沒有缺點，我們看看它的優(yōu)缺點：

總結(jié)：RBAC 角色模型+JWT 鑒權(quán)方案是目前微服務(wù)主流的安全認證體系，也能應(yīng)對大多數(shù)系統(tǒng)對于安全認證的需求，也是目前市面上大部分的企業(yè)應(yīng)用生產(chǎn)中的最佳實踐。

④微服務(wù)的運維監(jiān)控

生產(chǎn)就緒系統(tǒng) Production Ready：說完了開發(fā)環(huán)節(jié)，最后來說說微服務(wù)是怎么運維的。

我們知道僅僅只是完成功能(Feature-Complete) 只是軟件開發(fā)流程中很少的一部分，那么從完成編碼到生產(chǎn)就緒(Production Ready)，還需要經(jīng)歷哪些環(huán)節(jié)?

我們可以參考上圖：

• 集成測試：用戶功能的準(zhǔn)確性，性能和壓力測試。
• 日志管理：日志要規(guī)范，要區(qū)分：Info，Wrong，Error 等不同的等級，日志格式統(tǒng)一，方便日志收集，監(jiān)控和排查。
• 監(jiān)控預(yù)警：包含業(yè)務(wù)指標(biāo)監(jiān)控，應(yīng)用指標(biāo)監(jiān)控，CPU，內(nèi)存，磁盤網(wǎng)絡(luò) IO 監(jiān)控等等，設(shè)定合理的預(yù)警信息。
• 調(diào)用鏈監(jiān)控：呈現(xiàn)分布式系統(tǒng)的調(diào)用關(guān)系，調(diào)用性能，找到性能瓶頸，快速定位問題。
• 高可用考量：雙機備份，主從備份，異地多活，容災(zāi)策略，應(yīng)用彈性機制等。

當(dāng)我們確保應(yīng)用滿足生產(chǎn)就緒(Production Ready)的要求，我們就可以發(fā)布到生產(chǎn)，交付價值了。

基于 EFK 的日志采集方案：基于容器部署的微服務(wù)架構(gòu)不可能像傳統(tǒng)應(yīng)用那樣通過 SSH 登錄服務(wù)器上扒日志信息，所以只能采取統(tǒng)一的收集機制。

Kubernetes 中推薦使用 EFK (Elasticsearch+Fluentd+Kibana)采集日志。

它的工作流程如上圖：

• Fluentd 會將采集的日志直接發(fā)到 ElasticSearch，中間也可以增加 kafka 作為緩存層。
• ElasticSearch 通過 Log Parser 初步解析日志，可以過濾垃圾日志。
• 通過 Kibana Dashboard 查詢 ElasticSearch 顯示日志。

分布式系統(tǒng)的服務(wù)監(jiān)控方案：目前主流的微服務(wù)監(jiān)控體系是通過 Kubernetes + Prometheus 來搭建。

如上圖：

• 通過 Prometheus 發(fā)現(xiàn) Kubernetes 服務(wù)
• 通過 Alert Manager 監(jiān)控和報警 Email，SMS
• 通過 Grafana 展現(xiàn)和監(jiān)控服務(wù)的運行各項指標(biāo)

基于 Skywalking 分布式鏈路跟蹤監(jiān)控：Skywalking 是無侵入分布式鏈路跟蹤框架，可以在不添加一行代碼的前提下完成對微服務(wù)分布式系統(tǒng)的鏈路跟蹤，是目前主流的分布式鏈路跟蹤的解決方案。

2019 年 SkyWalking 成為 Apache 頂級項目，SkyWalking 的作者吳晟也因此當(dāng)選為 Apache 軟件基金會首位華人董事，這里就不展開講了。

SkyWalking 工作大致工作原理如下：

SkyWalking 對分布式調(diào)用鏈的展示：

總結(jié)

本文從云原生的發(fā)展歷史，講述了我們程序員為什么要擁抱選擇云原生。講解了基于云計算的基礎(chǔ)底座所衍生出來的云原生系統(tǒng)對傳統(tǒng)單體應(yīng)用所帶來的顛覆性改變，然后講述一些微服務(wù)的工作原理，架構(gòu)布局和運維方案。

但是在真正生產(chǎn)級云原生應(yīng)用中，遠遠不止要要考慮以上的內(nèi)容，還有更多需要考慮的因素。

例如：

• HTTPS
• 編碼規(guī)范，測試覆蓋率，E2E 測試
• 監(jiān)控：Log/Trace/Metrics，業(yè)務(wù)指標(biāo)監(jiān)控
• 持續(xù)集成：CI/CD 流水線
• 完善的 README 幫助文檔

更多細節(jié)就不展開講了，期待跟大家共同學(xué)習(xí)和交流，謝謝大家。

作者：肖斌2

編輯：陶家龍

來源：轉(zhuǎn)載自公眾號小二十七(ID：drak-phoenix)