作者 | 許曉斌 阿里云高級技術(shù)專家

傳統(tǒng)單體應(yīng)用架構(gòu)

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

▲ 單體架構(gòu)

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

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

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

▲ 單體架構(gòu)（水平伸縮）

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

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

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

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

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

應(yīng)用從單體架構(gòu)演進到微服務(wù)架構(gòu)，從物理的角度看，分布式就成了默認選項，這時應(yīng)用架構(gòu)師就不得不面對分布式帶來的新挑戰(zhàn)。在這個過程中，大家都會開始使用一些分布式服務(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)給運維也帶來新挑戰(zhàn)。研發(fā)人員原來只需要運維一個應(yīng)用，現(xiàn)在可能需要運維十個甚至更多的應(yīng)用，這意味著安全 patch 升級、容量評估、故障診斷等事務(wù)的工作量呈現(xiàn)成倍增長，這時，應(yīng)用分發(fā)標準、生命周期標準、觀測標準、自動化彈性等能力的重要性也更加凸顯。

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

云原生

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

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

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

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

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

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

本文總結(jié)

在架構(gòu)的演進過程中，研發(fā)運維人員逐漸把關(guān)注點從機器上移走，希望更多地由平臺系統(tǒng)管理機器，而不是由人去管理，這就是一個對 Serverless 的樸素理解。

作者簡介

許曉斌，阿里云高級技術(shù)專家。目前負責(zé)阿里集團 Serverless 研發(fā)運維平臺建設(shè)，在這之前負責(zé) AliExpress 微服務(wù)架構(gòu)、Spring Boot 框架、研發(fā)效率提升工作。《 Maven 實戰(zhàn)》作者，曾經(jīng)是 Maven 中央倉庫的維護者。

總結(jié)

以上是生活随笔為你收集整理的架构的演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。