![harry-cunningham--VOAA8_Y33Y-unsplash.jpg](https://ucc.alicdn.com/pic/developer-ecology/46296d8da9b148cdb46f895072ca6f67.jpg)

作者 | 許曉斌  阿里雲高階技術專家

本文整理自《Serverless 技術公開課》第 1 講，[點選開始學習](https://developer.aliyun.com/learning/roadmap/serverless)。
關注 “**Serverless**” 公眾號，回覆 **入門 **，即可獲取 Serverless 系列文章 PPT。

# 傳統單體應用架構

十多年前主流的應用架構都是單體應用，部署形式就是一臺伺服器加一個資料庫，在這種架構下，運維人員會小心翼翼地維護這臺伺服器，以保證服務的可用性。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/3c9672aae777496b8f1e5a8606bc3b37.png)

（單體架構）

隨著業務的增長，這種最簡單的單體應用架構很快就面臨兩個問題。首先，這裡只有一臺伺服器，如果這臺伺服器出現故障，例如硬體損壞，那麼整個服務就會不可用；其次，業務量變大之後，一臺伺服器的資源很快會無法承載所有流量。

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/5112b34baaeb462eb8ee0dfc9bfd492c.png)
（單體架構-水平伸縮）

# 微服務架構

## 1. 微服務架構演進出通用服務

隨著業務的進一步增長，更多的研發人員加入到團隊中，共同在單體應用上開發特性。由於單體應用內的程式碼沒有明確的物理邊界，大家很快就會遇到各種衝突，需要人工協調，以及大量的 conflict merge 操作，研發效率直線下降。

因此大家開始把單體應用拆分成一個個可以獨立開發、獨立測試、獨立部署的微服務應用，服務和服務之間透過 API 通訊，如 HTTP、GRPC 或者 DUBBO。基於領域驅動設計中 Bounded Context 拆分的微服務架構能夠大幅提升中大型團隊的研發效率。

## 2. 微服務架構給運維帶來挑戰

應用從單體架構演進到微服務架構，從物理的角度看，分散式就成了預設選項，這時應用架構師就不得不面對分散式帶來的新挑戰。在這個過程中，大家都會開始使用一些分散式服務和框架，例如快取服務 Redis，配置服務 ACM，狀態協調服務 ZooKeeper，訊息服務 Kafka，還有通訊框架如 GRPC 或者 DUBBO，以及分散式追蹤系統等。

除分散式環境帶來的挑戰之外，微服務架構給運維也帶來新挑戰。研發人員原來只需要運維一個應用，現在可能需要運維十個甚至更多的應用，這意味著安全 patch 升級、容量評估、故障診斷等事務的工作量呈現成倍增長，這時，應用分發標準、生命週期標準、觀測標準、自動化彈性等能力的重要性也更加凸顯。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/70bd0e9b598b4e95b305e67a555c2f6d.png)
（微服務架構）

# 雲原生

## 1. 基於雲產品架構

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

另外兩個不得不提的技術就是 Docker 和 Kubenetes，其中，前者標準化了應用分發的標準，不論是 Spring Boot 寫的應用，還是 NodeJS 寫的應用，都以映象的方式分發；而後者在前者的技術上又定義了應用生命週期的標準，一個應用從啟動到上線，到健康檢查，再到下線，都有了統一的標準。

## 2. 應用生命週期託管

有了應用分發的標準和生命週期的標準，雲就能提供標準化的應用託管服務。包括應用的版本管理、釋出、上線後的觀測、自愈等。例如對於無狀態的應用來說，一個底層物理節點的故障根本不會影響到研發，因為應用託管服務基於標準化應用生命週期可以自動完成騰挪工作，在故障物理節點上將應用的容器下線，在新的物理節點上啟動同等數量的應用容器。可以看出，雲原生進一步釋放了價值紅利。

在此基礎上，由於應用託管服務能夠感知到應用執行期的資料，例如業務流量的併發、cpu load、記憶體佔用等，業務就可以配置基於這些指標的伸縮規則，再由平臺執行這些規則，根據業務流量的實際情況增加或者減少容器數量，這就是最基本的 auto scaling——自動伸縮。這能夠幫助使用者避免在業務低峰期限制資源，節省成本，提升運維效率。

# 本文總結

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

## 作者簡介

許曉斌，阿里雲高階技術專家。目前負責阿里集團 Serverless 研發運維平臺建設，在這之前負責 AliExpress 微服務架構、Spring Boot 框架、研發效率提升工作。《 Maven 實戰》作者，曾經是 Maven 中央倉庫的維護者。

# 關注有禮

關注 **“Serverless” **公眾號，後臺回覆 **抽獎** ，將有機會獲得“紐曼藍芽音響”、“阿里雲全自動定製雨傘”、“淘公仔”，5 月 25 日 10:00 開獎，快來試試運氣吧！

>“[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

從零入門 Serverless | 架構的演進

相關文章