架構師之路 -- 基礎設施架構

系統層次劃分

任何一個系統按照邏輯部署維度均可以劃分紅應用層與基礎設施層，開發的應用軟件還有使用第三方的應用能夠抽象成一些組件的集合，爲了運行這些組件須要基礎設施層來提供支撐，基礎設施層有物理機、存儲、虛擬機、容器這些元素。

基礎設施層中最基本的是物理機，隨着技術的發展慢慢出現了虛擬機和容器。

咱們先來看看基礎設施架構的演進。

基礎設施架構演進

基礎設施架構不是一步到位的事情，是須要循環漸進不斷完善，隨着系統複雜度的提高和業務發展不斷的演進。接下來咱們以Ngnix+web+db這樣最基礎的架構看看一個系統的基礎設施從簡單到複雜的演變的過程：

一臺主機運行多個組件

在系統上線初期用戶量比較小，對系統的可用性要求也比較低。這樣咱們能夠將全部組件都部署在一臺主機上。

一臺主機運行一個組件

隨着系統業務發展，系統有了性能方面的要求，這時候就須要獨立部署，一個組件部署到一臺機器上，每臺機器的配置也不盡相同，好比數據庫和web服務器配置會更高點。

一個組件運行在多臺主機上

隨着業務的繼續發展，系統有了可用性方面的要求，這時候就須要將組件進行多實例部署，每一個實例部署在不一樣的機器上，經過集羣軟件來支持主備切換，這樣就造成了既保證性能又保證可用性的架構。

主機有多臺，每臺運行多個組件，有負載均衡和主備切換機制

隨着系統複雜度的提高，部署的組件愈來愈多。若是再採用一臺機器部署一個組件的話會致使運營成本上升過快，考慮到資源成本這時候就會考慮交叉式的部署架構。一臺機器部署多個組件，可是他們之間是交叉進行部署。這樣既保證了組件有多實例又保證了任何一臺機器掛了的話最少還有一個實例能提供服務。

一個組件用一臺虛擬機運行，一臺物理機運行多個虛擬機

物理機的性能相對都比較高，若是一臺物理機只部署幾個組件其實是對物理機的浪費。爲了提升物理機的資源利用率這時候咱們將物理機拆分紅虛擬機來對外提供部署能力。

一臺物理機首先劃分出若干個虛擬機，這些組件分別部署在這些虛擬機裏。這樣就實現了資源的充分利用也提高了系統的可用性還有運維的便利度。

一個組件用一個容器運行，一臺物理機上運行多個容器

再日後咱們能夠將虛擬機替換成容器實現，容器是更輕量的技術，使用容器能夠有更高的資源使用率

這就是一個系統基礎設施演進的過程，固然這些方案並非說只能選擇其中一種，能夠根據實際場景組合使用，演變成既有物理機也有虛擬機、容器的混合狀態。

基礎架構核心問題

基礎設施原則上是解決組件到運行環境的映射問題，基礎設施架構須要考慮下面十個方面的核心問題：

• 主機硬件配置 須要選擇什麼樣的配置來支撐組件部署？
• 主機與組件的對應關係 主機與組件之間是什麼關係？哪些組件部署在哪些主機上？
• 主機管理 如何管理這些主機？
• 組件管理 如何管理衆多的組件？
• 環境隔離 不一樣開發環境之間如何隔離？
• 資源隔離 一個組件佔用太多資源的話勢必會致使其餘組件資源變少？如何給組件分配合適的資源？
• 整體資源利用率 系統的利用率是否處在一個合理的狀態？
• 性能 部署架構下各個組件的性能是否能獲得保障？會不會出現瓶頸？
• 可用性 主機掛了系統的可用性可否獲得保障？
• 成本 如何在有限的預算下去支撐全部組件的運行，或者說是可否經過一些好的設計去節省預算？

考慮了上面幾個核心問題作出的基礎設施架構纔是良好的架構，這些核心問題的解決又須要架構師對服務器、網絡、存儲等知識有必定的瞭解，關注本系列文章，幫你解決這些問題。