高可用部署需求图1高可用部署（*注：随着服务满足高可用需求，服务的高可用能力会更强）这里的一致性Consistency是指模块依赖的方方面面，包括但不限于硬件规格和配置、操作系统、基础软件、系统参数，以及模块本身的信息，如配置文件、版本、上下游依赖组件的一致性等。.可以通过Puppet等配置管理工具进行管理和定期维护，保证配置一致。列出一些不一致的地方，比如CPU上是否开启了超线程，内存上是否关闭了SWAP，操作系统版本，JDK版本，内核的各种参数，文件系统类型，模块配置等等，可能会有一个严重影响服务可用性。并带来巨大的问题定位成本。消除单点和单点有两种场景：一种是某个模块只部署了一个实例；二是虽然部署了某个模块的多个实例，但任何一个实例故障都会导致服务整体或大面积不可用。如何识别系统的单点？通过检查模块的实例数并进行破坏性测试，找出系统中是否存在单点。对于已知的单点，你应该尽量制定一个计划来减少故障的持续时间。要了解归置组，首先要了解容错域（FaultDomain）的概念。故障域是指单个机房（通常是一个或一组机柜）内的交换机或电源发生故障的最大影响范围。同一个模块需要尽量分布部署在不同的容错域，避免单个容错域异常导致模块整体不可用。公有云下的放置组是为了提高业务的高可用。实例创建时，按照一定的策略强制分散，以减少底层硬件/软件故障对业务的影响。例如，一个模块的所有实例都不能部署在同一个接入交换机下，因为一旦接入交换机出现故障，整个模块就会出现故障，而一个机房内接入交换机数量众多。这场悲剧本可以完全避免。流量隔离流量隔离就是构建多套同构集群，根据流量的属性进行分而治之的管理。常见的隔离策略主要基于流量来源、重要性和资源消耗。例如：按地域划分，用户分为华北、华中、华南。根据硬件类型，用户分为PC和APP。根据重要性分为VIP用户和普通用户。根据资源消耗，分为报表请求和用户请求。Active是多AZ部署。同城机房间延迟很低，ping延迟一般在5ms以内。同城AZ基于网络、供电等物理隔离，避免单个机房故障导致业务中断。同城双活是以“系统消除单点”为前提的。多个AZ之间，业务请求尽量在一个AZ处理。可根据同城机房数量，在多个可用区部署N+1冗余业务。N+1中的“N”是指处理请求所需的资源容量，“1”是指资源冗余，防止机房故障。因此，N+1中的所有机房应该具有相同的请求处理能力，避免一个机房出现故障，其他机房无法处理需要的请求。N+1会导致一定的资源冗余，合理设置N的数量可以降低成本。比如2个机房的冗余度是50%，而5个机房的冗余度只有20%。远程多活是一种保证服务高可用的高层方法。目前多用于国内大型互联网公司，用于防御单一区域的整体故障。远程多活的主要问题是跨区域带宽、成本问题、跨区域延迟大。比如同城延迟一般在5ms以内，而华北和华南之间的延迟可达50ms。这还是使用专线的前提。案例：“Yum源服务”高可用部署实践Yum源服务是一个提供Centos系统Yum仓库的下载服务。案例以该服务为例，讨论如何搭建一个高可用的yum源服务。Yum源服务最简单的架构设计如下：图2简单服务架构该服务由云主机提供，数据存储在本地，下载服务由Nginx提供。以上架构服务可以完整实现yum源服务的功能。但是这种架构的服务如果需要对外提供服务，会面临以下问题：单机部署，一旦服务器宕机，服务就会失效；性能瓶颈，一台机器一次处理的请求数是有限的，服务器IO会成为性能瓶颈。我们需要调整架构，实现高可用的服务架构。HighAvailabilityService2.0vHighAvailability2.0v的目的就是为了解决以上问题。首先识别服务中的模块是否支持多实例部署（排除单点）：对于Nginx模块，Nginx是无状态的，可以水平扩展；存储在本地磁盘的数据也可以水平扩展，但此时数据的一致性将是主要问题。推荐使用分布式文件系统解决数据存储一致性问题。服务必须满足一定的并发量要求。Nginx具有高并发能力，支持横向扩展。使用分布式文件系统来满足并发性和数据一致性的要求。我们使用Puppet来管理服务器的配置，保证服务器的配置一致（consistency）。要求每台服务器不在同一个故障域（归置组）中。高可用服务架构如下：图3高可用部署架构2.0v高可用服务3.0v3.0v的高可用部署考虑了同城双活的场景。我们选择华北两个可用区来部署高可用服务。架构图如下图所示。两个AZ部署相同配置的服务，流量通过阿里云DNS分发到两个AZ，实现故障转移和负载均衡。图4高可用部署架构3.0v高可用服务4.0v考虑远程多活架构。上面提到的远程多活的难点在于数据同步。对于这个服务，它并不强烈依赖数据的一致性，短期的数据不一致是可以接受的。基于区域隔离流量，达到分而治之的目的（流量隔离）。我们选择在华南的两个机房部署一套服务，配置和华北的机器一样。服务架构如下：图5上面写的高可用部署4.0v只是一个简单的高可用部署实践。现实中，服务模块有几十到上百个，服务的复杂度与高可用成反比。而且，随着服务具有更多的高可用部署特性，服务的复杂度也会增加。如果故障转移和应急预案建设没有做好，可能会降低服务可用性指标。另一方面，服务的高可用部署也与成本息息相关，跨机房、跨地域的服务部署会带来资源成本和技术能力方面的挑战。因此，高可用部署需要实现的是服务复杂度和成本之间的平衡，以满足服务当前和未来的需求。本期作者：勿忘我京东云应用研发部一个高可用的服务，需要从部署、变更、规划、监控、安全等多方面考虑。如何达到99.99%服务高可用的要求，需要各个角色的工程师共同努力。本文从部署的角度，介绍高可用服务所需的规范。案例部分通过yum源服务架构的演进，让读者更好的理解高可用服务的部署。希望对大家有所帮助。【本文为专栏作者“京东云”原创稿件，转载请通过作者微信公众号JD-jcloud获得授权】点此查看作者更多好文
