共計(jì) 1832 個(gè)字符，預(yù)計(jì)需要花費(fèi) 5 分鐘才能閱讀完成。

本篇文章給大家分享的是有關(guān) Serverless 架構(gòu)的演進(jìn)示例分析，丸趣 TV 小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。

傳統(tǒng)單體應(yīng)用架構(gòu) Serverless 降低了維護(hù)應(yīng)用程序的總成本，能夠更快地構(gòu)建更多邏輯。它是一個(gè)命令行工具，提供腳手架、工作流自動(dòng)化和開發(fā)部署無服務(wù)器架構(gòu)的最佳實(shí)踐。它也可以通過插件完全擴(kuò)展。

十多年前主流的應(yīng)用架構(gòu)都是單體應(yīng)用，部署形式就是一臺(tái)服務(wù)器加一個(gè)數(shù)據(jù)庫(kù)，在這種架構(gòu)下，運(yùn)維人員會(huì)小心翼翼地維護(hù)這臺(tái)服務(wù)器，以保證服務(wù)的可用性。

單體應(yīng)用架構(gòu)面臨的問題

隨著業(yè)務(wù)的增長(zhǎng)，這種最簡(jiǎn)單的單體應(yīng)用架構(gòu)很快就面臨兩個(gè)問題。首先，這里只有一臺(tái)服務(wù)器，如果這臺(tái)服務(wù)器出現(xiàn)故障，例如硬件損壞，那么整個(gè)服務(wù)就會(huì)不可用；其次，業(yè)務(wù)量變大之后，一臺(tái)服務(wù)器的資源很快會(huì)無法承載所有流量。

解決這兩個(gè)問題最直接的方法就是在流量入口加一個(gè)負(fù)載均衡器，使單體應(yīng)用同時(shí)部署到多臺(tái)服務(wù)器上，這樣服務(wù)器的單點(diǎn)問題就解決了，與此同時(shí)，這個(gè)單體應(yīng)用也具備了水平伸縮的能力。

微服務(wù)架構(gòu)

1. 微服務(wù)架構(gòu)演進(jìn)出通用服務(wù)

隨著業(yè)務(wù)的進(jìn)一步增長(zhǎng)，更多的研發(fā)人員加入到團(tuán)隊(duì)中，共同在單體應(yīng)用上開發(fā)特性。由于單體應(yīng)用內(nèi)的代碼沒有明確的物理邊界，大家很快就會(huì)遇到各種沖突，需要人工協(xié)調(diào)，以及大量的 conflict merge 操作，研發(fā)效率直線下降。

因此大家開始把單體應(yīng)用拆分成一個(gè)個(gè)可以獨(dú)立開發(fā)、獨(dú)立測(cè)試、獨(dú)立部署的微服務(wù)應(yīng)用，服務(wù)和服務(wù)之間通過 API 通訊，如 HTTP、GRPC 或者 DUBBO。基于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中 Bounded Context 拆分的微服務(wù)架構(gòu)能夠大幅提升中大型團(tuán)隊(duì)的研發(fā)效率。

2. 微服務(wù)架構(gòu)給運(yùn)維帶來挑戰(zhàn)

應(yīng)用從單體架構(gòu)演進(jìn)到微服務(wù)架構(gòu)，從物理的角度看，分布式就成了默認(rèn)選項(xiàng)，這時(shí)應(yīng)用架構(gòu)師就不得不面對(duì)分布式帶來的新挑戰(zhàn)。在這個(gè)過程中，大家都會(huì)開始使用一些分布式服務(wù)和框架，例如緩存服務(wù) Redis，配置服務(wù) ACM，狀態(tài)協(xié)調(diào)服務(wù) ZooKeeper，消息服務(wù) Kafka，還有通訊框架如 GRPC 或者 DUBBO，以及分布式追蹤系統(tǒng)等。

除分布式環(huán)境帶來的挑戰(zhàn)之外，微服務(wù)架構(gòu)給運(yùn)維也帶來新挑戰(zhàn)。研發(fā)人員原來只需要運(yùn)維一個(gè)應(yīng)用，現(xiàn)在可能需要運(yùn)維十個(gè)甚至更多的應(yīng)用，這意味著安全 patch 升級(jí)、容量評(píng)估、故障診斷等事務(wù)的工作量呈現(xiàn)成倍增長(zhǎng)，這時(shí)，應(yīng)用分發(fā)標(biāo)準(zhǔn)、生命周期標(biāo)準(zhǔn)、觀測(cè)標(biāo)準(zhǔn)、自動(dòng)化彈性等能力的重要性也更加凸顯。

云原生

1. 基于云產(chǎn)品架構(gòu)

一個(gè)架構(gòu)是否是云原生，就看這個(gè)架構(gòu)是否是長(zhǎng)在云上的，這是對(duì)“云原生”的簡(jiǎn)單理解。這個(gè)“長(zhǎng)在云上”不是簡(jiǎn)單地說用云的 IaaS 層服務(wù)，比如簡(jiǎn)單的 ECS、OSS 這些基本的計(jì)算存儲(chǔ)；而是應(yīng)該理解成有沒有使用云上的分布式服務(wù)，比如 Redis、Kafka 等，這些才是直接影響到業(yè)務(wù)架構(gòu)的服務(wù)。微服務(wù)架構(gòu)下，分布式服務(wù)是必要的，原來大家都是自己研發(fā)這樣的服務(wù)，或者基于開源版本自己運(yùn)維這樣的服務(wù)。而到了云原生時(shí)代，業(yè)務(wù)則可以直接使用云服務(wù)。

另外兩個(gè)不得不提的技術(shù)就是 Docker 和 Kubenetes，其中，前者標(biāo)準(zhǔn)化了應(yīng)用分發(fā)的標(biāo)準(zhǔn)，不論是 Spring Boot 寫的應(yīng)用，還是 NodeJS 寫的應(yīng)用，都以鏡像的方式分發(fā)；而后者在前者的技術(shù)上又定義了應(yīng)用生命周期的標(biāo)準(zhǔn)，一個(gè)應(yīng)用從啟動(dòng)到上線，到健康檢查，再到下線，都有了統(tǒng)一的標(biāo)準(zhǔn)。

2. 應(yīng)用生命周期托管

有了應(yīng)用分發(fā)的標(biāo)準(zhǔn)和生命周期的標(biāo)準(zhǔn)，云就能提供標(biāo)準(zhǔn)化的應(yīng)用托管服務(wù)。包括應(yīng)用的版本管理、發(fā)布、上線后的觀測(cè)、自愈等。例如對(duì)于無狀態(tài)的應(yīng)用來說，一個(gè)底層物理節(jié)點(diǎn)的故障根本不會(huì)影響到研發(fā)，因?yàn)閼?yīng)用托管服務(wù)基于標(biāo)準(zhǔn)化應(yīng)用生命周期可以自動(dòng)完成騰挪工作，在故障物理節(jié)點(diǎn)上將應(yīng)用的容器下線，在新的物理節(jié)點(diǎn)上啟動(dòng)同等數(shù)量的應(yīng)用容器。可以看出，云原生進(jìn)一步釋放了價(jià)值紅利。

在此基礎(chǔ)上，由于應(yīng)用托管服務(wù)能夠感知到應(yīng)用運(yùn)行期的數(shù)據(jù)，例如業(yè)務(wù)流量的并發(fā)、cpu load、內(nèi)存占用等，業(yè)務(wù)就可以配置基于這些指標(biāo)的伸縮規(guī)則，再由平臺(tái)執(zhí)行這些規(guī)則，根據(jù)業(yè)務(wù)流量的實(shí)際情況增加或者減少容器數(shù)量，這就是最基本的 auto scaling——自動(dòng)伸縮。這能夠幫助用戶避免在業(yè)務(wù)低峰期限制資源，節(jié)省成本，提升運(yùn)維效率。

以上就是 Serverless 架構(gòu)的演進(jìn)示例分析，丸趣 TV 小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道。