轉自：

https://cloud.tencent.com/info/e9695bd18d1c7752b3924bb3ac38cc95.html

https://mp.weixin.qq.com/s/81DIj_ErsPTCcUJD0nPKAA

三個維度

IT 架構

IT 架構其實就是計算，網絡，存儲。這是雲架構師的基本功，也是最傳統的雲架構師應該首先掌握的部分。

良好設計的 IT 架構，可以降低 CAPEX 和 OPEX，減輕運維的負擔。數據中心，虛擬化，雲平臺，容器平臺都屬於 IT 架構的範疇。

應用架構

隨著應用從傳統應用向互聯網應用轉型，僅僅搞定資源層面的彈性還不夠，常常會出現創建了大批機器，仍然撐不住高並發流量。因而基於微服務的互聯網架構，越來越成為雲架構師所必需的技能。

良好設計的應用架構，可以實現快速叠代和高並發。數據庫，緩存，消息隊列等 PaaS，以及基於 Spring Cloud 和 Dubbo 的微服務框架，都屬於應用架構的範疇。

數據架構

數據成為人工智能時代的核心資產，在做互聯網化轉型的同時，往往進行的也是數字化轉型，並有戰略的進行數據收集，這就需要雲架構師同時有大數據思維。

有意識的建設統一的數據平臺，並給予數據進行數字化運營。搜索引擎，Hadoop，Spark，人工智能都屬於數據架構的範疇。

六個層面

基礎設施層

在數據中心裏面，會有大量的機架，大量的服務器，並通過交換機和路由器將服務器連接起來，有的應用例如 Oracle 是需要部署在物理機上的。

為了管理的方便，在物理機之上會部署虛擬化，例如 Vmware，可以將對於物理機復雜的運維簡化為虛擬機靈活的運維。

虛擬化采取的運維方式多是由運維部門統一管理，當一個公司裏面部門非常多的時候，往往要引入良好的租戶管理。

隨著應用架構越來越重要，對於標準化交付和彈性伸縮的需求越來越大，容器做為軟件交付的集裝箱，可以實現基於鏡像的跨環境遷移，Kubernetes 是容器管理平臺的事實標準。

數據層

數據層，如果是傳統應用，可能會使用 Oracle，並使用大量的存儲過程，有大量的表聯合查詢，成本也往往比較高。

但是對於高並發的互聯網應用，需要進行微服務的拆分，數據庫實例會比較多，使用開源的 MySQL 是常見的選擇。

大量的存儲過程和聯合查詢往往會使得微服務無法拆分，性能會比較差，因而需要放到應用層去做復雜的業務邏輯，而且數據庫表和索引的設計非常重要。

當並發量比較大的時候，需要實現橫向擴展，就需要基於分布式數據庫，也是需要基於單庫良好的表和索引設計。

對於結構比較靈活的數據，可以使用 MongoDB 數據庫，橫向擴展能力比較好。

對於大量的聯合查詢需求，可以使用 ElasticSearch 之類的搜索引擎來做，速度快，更加靈活。

中間件層

數據庫層往往需要保證數據的不丟失以及一些事務，因而並發性能不可能非常大。

所以我們經常說，數據庫是中軍大營，不能所有的請求都到這裏來，因而需要一層緩存層，用來攔截大部分的熱點請求。

Memcached 適合做簡單的 key-value 存儲，內存使用率比較高，而且由於是多核處理，對於比較大的數據，性能較好。

但是缺點也比較明顯，Memcached 嚴格來講沒有集群機制，橫向擴展完全靠客戶端來實現。

另外 Memcached 無法持久化，一旦掛了數據就都丟失了，如果想實現高可用，也是需要客戶端進行雙寫才可以。

Redis 的數據結構比較豐富，提供持久化的功能，提供成熟的主備同步，故障切換的功能，從而保證了高可用性。

另外微服務拆分以後，有時候處理一個訂單要經過非常多的服務，處理過程會比較慢，這個時候需要使用消息隊列，讓服務之間的調用變成對於消息的訂閱，實現異步處理。

RabbitMQ 和 Kafka 是常用的消息隊列，當事件比較重要的時候，會結合數據庫實現可靠消息隊列。

基礎服務層

有的時候稱做中臺層，將通用的能力抽象為服務對外提供原子化接口。

這樣上層可以根據業務需求，通過靈活的組合這些原子化接口，靈活的應對業務需求的變化，實現能力的復用，以及數據的統一管理，例如用戶數據，支付數據，不會分散到各個應用中。

另外基礎服務層稱為應用、數據庫和緩存的一個分界線，不應該所有的應用都直接連數據庫，一旦出現分庫分表，數據庫遷移，緩存選型改變等，影響面會非常大，幾乎無法執行。

如果將這些底層的變更攔截在基礎服務層，上層僅僅使用基礎服務層的接口，這樣底層的變化會對上層透明，可以逐步演進。

業務服務層或者組合服務層

大部分的業務邏輯都是在這個層面實現，業務邏輯比較面向用戶，因而會經常改變，所以需要組合基礎服務的接口進行實現。

在這一層，會經常進行服務的拆分，實現開發獨立，上線獨立，擴容獨立，容災降級獨立。

微服務的拆分不應該是一個運動，而應該是一個遇到耦合痛點的時候，不斷解決，不斷演進的一個過程。

微服務拆分之後，有時候需要通過分布式事務，保證多個操作的原子性，也是在組合服務層來實現的。

用戶接口層

用戶接口層，也即對終端客戶呈現出來的界面和 App，但是卻不僅僅是界面這麽簡單。

這一層有時候稱為接入層。在這一層，動態資源和靜態資源應該分離，靜態資源應該在接入層做緩存，使用 CDN 進行緩存。

也應該 UI 和 API 分離，界面應該通過組合 API 進行數據拼裝。API 會通過統一的 API 網關進行統一的管理和治理。

一方面後端組合服務層的拆分對 APP 是透明的；另一方面當並發量比較大的時候，可以在這一層實現限流和降級。

支撐層

為了支撐這六個層次，在上圖的左側是一些公共能力：

• 持續集成和持續發布是保證微服務拆分過程中的快速叠代，以及變更後保證功能不變的，不引入新的 Bug。

• 服務發現和服務治理是微服務之間互相的調用，以及調用過程中出現異常情況下的熔斷，限流，降級策略。

• 大數據和人工智能是通過收集各個層面的數據，例如用戶訪問數據，用戶下單數據，客服詢問數據等，結合統一的中臺，對數據進行分析，實現智能推薦。

• 監控與 APM 是基礎設施的監控和應用的監控，發現資源層面的問題以及應用調用的問題。

架構的三個維度和六個層面