云时代分布式系统演进
作者：潘罡 （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的各个虚拟概念以及它的工作机制。
