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

轉自：

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 是基礎設施的監控和應用的監控，發現資源層面的問題以及應用調用的問題。