前言

随着AWS、阿裡雲、Azure、騰訊雲等公有雲的蓬勃發展，越來越多的企業開始在考慮上公有雲了。

這些年做架構咨詢，發現很多傳統的公司在基礎設施上雲的過程中沒有明确的設計思路，隻是一通購買雲産品，然後使用雲産品，認為這樣就是上雲了。

但其實，如果沒有一個很好的雲基礎設施架構設計，會使後續的雲使用變得難以維護，達不到預期的效果，同時成本上升。

這篇文章裡面，我會分享一些過去項目中的公有雲設計經驗和思路，給大家提供一些基于微服務的場景下如何設計雲基礎設施架構的參考。其中這裡的雲指的是如阿裡雲，AWS的公有雲。

為什麼要上雲

上雲的好處或價值在各大文章裡面已經說得非常多了。

我這裡也敷衍的列舉幾個好處和價值吧。

1. 降低成本
2. 可伸縮性
3. 專業的運維
4. 速度

降低成本

降低成本主要是降低了兩類成本。

• 公司不再需要招聘專業的運維人員專門負責維護伺服器。（大型公司除外，他們通常需要大量的運維人員統一維護全公司的雲資産或者自建雲計算）
• 公司不再需要專門的人員來針對運維開發各類工具，如今常見的雲計算平台都包含豐富的功能，以及完善的售後體系。

可伸縮性

可伸縮是傳統的伺服器無法做到的，這也正是如今雲計算越來越火的一個很大的原因。

我們可以根據業務的需要，擴充服務性能，不僅如此，而且還能做到縮小服務性能，以節約成本。

專業的運維

上雲之後不是沒有運維了，而是把運維交給了雲計算平台的專業的人來做了。而你隻需要關心如何基于這些雲基礎設施建構自己的産品了。

速度

速度是指各方面的速度都提升了。比如，你隻需要花1分鐘時間就能建立一台新的伺服器，你隻需要花1分鐘時間就能擴容某個服務。由于減少了各種搭建配置時間，開發時間是以也縮短了。縮短了試驗和測試的時間，更快的為客戶提供可用性。

雲基礎設施架構成熟度評估

那麼上雲之後我們如何知道我們的雲基礎設施架構是足夠優秀的呢？

這裡就需要有一套雲基礎設施架構成熟度評估模型。

我根據這些年的架構咨詢工作，結合多個項目總結了這套雲基礎設施架構成熟度評估模型。它

主要分為8個模型，5種等級。

這8個模型是：

1. 可伸縮性 - 雲基礎設施能根據業務需要自由伸縮
2. 可複制性 - 雲基礎設施能根據業務需要快速複制
3. 可恢複性 - 雲基礎設施挂了之後能自動或快速恢複
4. 可用性 - 雲基礎設施的設計能保證服務的高可用性
5. 安全性 - 雲基礎設施的設計能有非常高的安全設計
6. 可量化管理 - 雲基礎設施應該可以被量化管理以優化成本
7. 可維護性 - 雲基礎設施應該具有更簡單的可維護性
8. 可組合性 - ****雲基礎設施會根據業務需要組合使用

這5種等級是：

1. 原始級 - 完全沒有使用雲基礎設施
2. 基礎級 - 嘗試了一些基本的雲基礎設施
3. 标準級 - 所有基礎設施都上雲了
4. 成熟級 - 所有基礎設施都上雲了并且掌握雲基礎設施架構的最佳實踐
5. 領先級 - 自建雲計算

結合上面的模型，我們就可以得出如下的打分。

基于這個打分，我們就可以得到如下的評估圖。

那麼接下來，我們就把這個架構設計展開來說一說。

主要說一說VPC設計，通路控制設計，安全設計和資料庫設計。

VPC設計

VPC全稱是Virtual Private Cloud，是雲上的一個邏輯隔離的專有網絡。

使用VPC主要是為了安全隔離，把不同的環境隔離開來。一是避免環境污染，二是保障安全性。

是以，如下圖所示，通常一個企業都會設計以下幾個VPC環境：

1. 産品環境
2. 測試環境
3. 開發環境
4. UAT環境

産品環境是我們線上所有産品運作的VPC環境，隻有使用者能接觸到的一個環境。

測試環境是做測試用的，也是大部分公司開發人員和測試人員能接觸的一個環境。

開發環境則是日常工作所在的環境，它通常與辦公網絡是連通的，這裡會放我們的git，pipeline，鏡像倉庫，制品庫等。

UAT環境通常是給客戶做驗證的，比如上線前，需要讓客戶去驗證是否符合預期了，這個環境之是以不能使用測試環境是因為通常客戶需要導入一些真實資料做測試，需要保證UAT環境的幹淨。

另外，如果有多地域部署系統的要求，就需要使用多個VPC，因為VPC是地域級别的資源，是不能跨地域的。

通路控制設計

我們的雲資源不是對所有人開放的，特别是對于産品環境的通路控制應該尤其嚴格，一是防止内部人的誤操作，二是防止黑客的入侵。

但我在很多客戶那裡都遇到過，他們沒有任何通路控制設計，所有的開發人員都共用一個或幾個賬号。這是非常危險的使用方式，不利于管理，也有諸多風險。

現在的公用雲都有通路控制功能，通常叫做Resource Access Management。

通路控制的設計主要從下面幾個緯度去考慮：

1. 使用者管理
   1. 使用者分為：真實使用者，虛拟使用者
   2. 真實使用者就是那些真實的人。比如員工和使用者。
   3. 虛拟使用者就是配置設定給某個系統使用的賬号。比如某系統需要有上傳圖檔的權限。
2. 讀寫分離
   1. 通常有的人隻應該擁有隻讀權限。
   2. 有的提供給系統的賬号應該隻有隻讀權限。
   3. 比如，通路對象存儲的使用者頭像的賬号應該隻有隻讀權限。
   4. 管理者或者上傳圖檔功能需要擁有寫入權限。
3. 角色管理
   1. 不同的人可能都是同一個角色。
   2. 同一個人可能擁有不同角色。
   3. 角色決定了我們擁有哪些權限集。

其次就是，雲基礎設施的通路控制是否需要和企業内部自己的單點登入內建，也是需要考慮的設計。

總結一下就是，通路控制應該遵循最小權限原則，才能最大限度的保證系統的安全性。

安全設計

大部分人的誤區是，我已經用雲了，再買個防火牆什麼的，就很安全了。

但其實公有雲是完全暴露在網際網路的，是以也需要有完善的安全設計才能保證雲基礎設施的安全。

把該隐藏的隐藏進私網裡面，隻暴露最少的資訊。

基礎設施的安全設計主要包含幾個方面：

1. 網絡安全
   1. 包括傳輸安全，比如資料如何加密傳輸
   2. 網絡是否暴露
   3. 網絡設計是否合理
2. 資料安全
   1. 資料是否被足夠的保護了
   2. 資料是否暴露在了外面
3. 權限安全
   1. 是否按照最小權限設計的
   2. 是否讀寫權限分離了

總結一下，設計的時候需要遵循兩個原則：

1. 零信任網絡
2. 最小權限設計

資料庫設計

這裡主要是涉及到資料庫的高可用和高性能的設計問題。

高可用方案通常有3種方向：

1. 主備架構
   1. 通常會有多節點，不同點節點會在不同的可用區
2. 容災
   1. 容災主要分為異地容災和同城容災
3. 備份恢複
   1. 資料庫挂了之後如何快速自動恢複
   2. 恢複期間的資料丢失如何找回

這裡的高性能設計不包括分庫分表相關的設計，因為這隻是關于基礎設施的架構設計。

通常需要考慮：

1. 如何彈性擴容？
2. 是否需要讀寫分離？
   1. 讀寫分離後資料的一緻性如何保證？
   2. 根據業務場景，需要多少讀執行個體？
3. 緩存如何設計

下面是一個大概的高性能高可用資料庫架構的樣子，供大家參考。

雲基礎設施架構設計

總結起來，一個常見的基于微服務的雲基礎架構設計，大概就長下圖的樣子。

我們在設計的時候可能需要考慮的遠不止下圖的中的東西。

比如我們得考慮：

• 多個VPC如何通信
• 叢集如何編排
• 資料庫選型
• 日志收集用什麼工具才能易于收集易于搜尋
• 運維監控用什麼工具才能全面監控并能智能警報
• MQ是否要滿足一些特殊場景
• 第三方服務是否有特殊要求
• 在這個架構下我們是否能動态橫向和縱向擴容

總結

希望上面的一些分享能幫助大家在設計雲基礎設施架構的時候提供一些參考。

這樣的架構設計涉及的東西是非常廣的，不同的項目也會有不同的設計要求。

是以，最終設計一定要結合項目的實際情況，滿足了業務需要就是好的設計。

記住一句話，沒有正确的設計，隻有剛好适用的設計。