從零入門 Serverless | 架構的演進

時間 2020-05-27

標籤入門 serverless 架構演進欄目系統架構简体版

原文原文鏈接

做者 | 許曉斌阿里雲高級技術專家數據庫

本文整理自《Serverless 技術公開課》第 1 講，點擊開始學習。關注「Serverless」公衆號，回覆 **入門 **，便可獲取 Serverless 系列文章 PPT。緩存

傳統單體應用架構

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

（單體架構）服務器

隨着業務的增加，這種最簡單的單體應用架構很快就面臨兩個問題。首先，這裏只有一臺服務器，若是這臺服務器出現故障，例如硬件損壞，那麼整個服務就會不可用；其次，業務量變大以後，一臺服務器的資源很快會沒法承載全部流量。架構

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

（單體架構-水平伸縮）負載均衡

微服務架構

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

隨着業務的進一步增加，更多的研發人員加入到團隊中，共同在單體應用上開發特性。因爲單體應用內的代碼沒有明確的物理邊界，你們很快就會遇到各類衝突，須要人工協調，以及大量的 conflict merge 操做，研發效率直線降低。框架

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

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

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

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

（微服務架構）

雲原生

1. 基於雲產品架構

一個架構是不是雲原生，就看這個架構是不是長在雲上的，這是對「雲原生」的簡單理解。這個「長在雲上」不是簡單地說用雲的 IaaS 層服務，好比簡單的 ECS、OSS 這些基本的計算存儲；而是應該理解成有沒有使用雲上的分佈式服務，好比 Redis、Kafka 等，這些纔是直接影響到業務架構的服務。微服務架構下，分佈式服務是必要的，原來你們都是本身研發這樣的服務，或者基於開源版本本身運維這樣的服務。而到了雲原生時代，業務則能夠直接使用雲服務。

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

2. 應用生命週期託管

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

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