作者：潘罡 （Van Pan） @ Microsoft
在上一節中，我們大致了解了分布式系統的整體架構。簡而言之，因為單台機器性能總是有限（摩爾定律增長性能速率無法滿足實際應用場景的增速），系統架構師通過各種方式將來自用戶的請求分散至多個服務系統和服務器協同完成。
而在現今最火熱的雲時代，微軟已經從雲服務層面整體解決了所有分布式系統需要考慮和實現的難題。
下面我們將粗粒度介紹微軟雲Azure中所有和上一節各個環節相關的服務組件。我們會大致介紹其功能，並且在后續章節中詳細介紹其使用方法。
動態DNS —— Azure Traffic Manager (ATM)
https://azure.microsoft.com/en-us/services/traffic-manager/
在上一節中，我們了解用戶首先通過域名來獲得服務器的IP入口。
同時我們也已經知道動態域名可以從地域靠近，線路優化，負載均衡IP等多種方式來解決其他服務無法達到的網絡物理環境優化。
Azure Traffic Manager就是這樣一個動態DNS解決方案。
最終用戶請求業務域名 –> 域名CNAME映射至ATM域名 –> ATM根據配置從多個endpoint域名中返回一個作為其CNAME
我們可以通過如下方式來配置和指定Azure Traffic Manager的工作行為。
- 創建一個Azure Traffic Manager，從而得到一個ATM域名，類似 xxx.trafficmanager.windows.net。
- 將ATM域名作為自己域名（例如：www.contoso.com）的CNAME進行綁定，從而實現對最終用戶屏蔽ATM域名的效果。
- 在ATM中配置多個endpoint站點域名，作為動態DNS目標結果。
- 配置ATM工作模式：Priority (failover 模式), Performance, Weighted
- Priority：ATM探針會定時探測所有endpoint站點是否可用，如果站點失效，自動將域名切換至下一個endpoint。
- Performance：ATM全球探針會定時探測所有endpoint到全球各個主要網絡節點的響應速度。並且定時記錄並刷新該速度列表。當最終用戶進行DNS解析請求時，該列表會作為參考標准返回對應最終用戶性能最快的一個endpoint域名。
- Weighted：在配置endpoint時進行權重配置，ATM會根據權重在解析時按不同權重比例返回結果。例如70%的時間返回endpoint A域名，另外其余時間返回endpoint B域名。
通過以上配置，Azure幫助架構師從域名層面進行了第一次負載均衡處理。
網絡負載均衡 —— Azure Load Balancer (ALB)
https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
在上文中，ATM作為第一層系統，將業務域名最終映射到了endpoint域名。
從網絡DNS角度考慮，endpoint域名最終必定是一個公用IP的ANAME。
但是我們知道，IP只是作為網絡連接的接入地址，它和真正處理服務的服務器沒有必然相關性。
因此在Azure中，從endpoint域名->IP->服務器之間又可以做如下拆分工作，事實上Azure Service Fabric也是這樣做的。
- 創建Azure Virtual Machine Scale Set （我們會在本節下文講到VMSS，在此你可以先簡單理解為這是一個VM集群，可以進行一些統一的對外IP配置 ）
- 為VMSS配置一個公共的IP及Azure子域名，例如：207.46.154.78 / xxx.eastasia.cloudapp.azure.com
- 為該公共IP創建ALB，配置以下信息
- IP池，用來告知ALB需要將請求負載均衡至VMSS中的多少台VM的IP列表。
- 端口映射，將公開端口映射至VMSS中具體每台VM監聽的端口號。例如 207.46.154.78:80 –> 192.168.1.3:8080
- 探針策略，配置ALB如何探測后台IP端口是否可用，以免負載均衡至不可用服務器
根據以上配置，所有請求至 xxx.eastasia.cloudapp.azure.com 域名后都會經由ALB轉發至真正的VM。
虛擬機擴展集群 —— Azure Virtual Machine Scale Set (VMSS)
https://azure.microsoft.com/en-us/services/virtual-machine-scale-sets/
接下來簡單介紹上文提及的VMSS。
在雲服務時代，雲服務使用者已經不需要考慮物理機的部署和運維工作。對業務系統架構師和運維人員而言，都是在和虛擬機打交道。
Azure提供了VMSS，一個非常友好的VM集群控制系統。
VMSS從一個整體唯獨提供了服務器層面的監控管理方案，使用者可以從整體把握其系統的工作情況。例如：
- 當VMSS平均CPU變高時，可以臨時加入新的虛擬機來分攤壓力。當然后續也可以移除減少費用。
- 因為有ALB的存在，所以當加入新VM進入VMSS時，不需要額外的其他操作。ALB可以在探針確認新VM服務可用后立即進行負載均衡。
- 如果需要對所有虛擬機打補丁或者安裝新組件，可以針對VMSS進行，所有部署工作都將在各個VM上執行。
對Azure Service Fabric而言，運行的底層即是依賴於VMSS。
PaaS 微服務架構 —— Azure Service Fabric (ASF)
https://azure.microsoft.com/zh-cn/services/service-fabric/
前面講了這么多鋪墊，終於開始進入我們的主題：Azure Service Fabric
在開始之前，我們需要理清一些思路。它們對於我們之后學習Azure Service Fabric會非常有用。
- Azure Service Fabric其實分為兩塊：Azure和Service Fabric。
- Service Fabric只是一套軟件分布式系統，理論上它可以使用在非Azure環境。也就是說：非Azure環境的機器集群，進行合理配置，也可以使用Service Fabric 構建分布式系統。
- 當我們在Azure門戶上創建Azure Service Fabric時，會自動創建Azure Load Balancer, Azure Virtual Machine Scale Set, Azure Virtual Machine。這是因為這些組件都是在Azure環境中將Service Fabric接入公網必須的組件和平台。但是理論上如果今后有其他的產品，通過合理的負載均衡和配置邏輯，只要可以讓服務器集群面向外部網絡提供服務，Service Fabric都可以適用。
- Service Fabric自行構建了一整套虛擬概念，包括后面會提及的Micro Service, Node type, Node等等。這些概念都是僅在Service Fabric范圍內適用。例如Micro Service，可以用C#構建，也可以用Java實現。Node type可以是Azure VMSS, 也可是是硬件物理服務器。
- Service Fabric幫助架構師將分布式系統和硬件進行脫耦。理想程度下，所有職責如下：
- 軟件開發者只需要關系分布式微服務功能邏輯實現，微服務之間如何調用通過統一接口完成
- 應用部署者只需要關心如何將微服務部署至各個node，以及考慮應用的升級維護
- 硬件架構師只需要關心維護虛擬機和網絡之間的部署關系，並且在虛擬機性能產生問題是增加虛擬機來分擔壓力
我們會在下一節介紹Azure Service Fabric的各個虛擬概念以及它的工作機制。