系统高可用技术探讨

作者：陈森炯，新炬网络高级技术专家。

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

随着IT时代的进步，系统高可用性越来越重要。系统高可用性核心思想就是避免单点故障引起的业务连续性问题，要保障在最短的时间切换到系统集群其他节点或者系统备端。接着我们以网络层负载均衡器，主机层，中间件层，数据层的高可用为讨论点进行这方面的探讨。

网络层负载均衡器高可用：网络层负载均衡器产品有F5,ARRAY等，负载均衡器设备必须满足一台设备宕机后，另外一台能够及时接管的条件。设备切换过程中，尽量做到无缝切换，负载均衡器的后台实例不需要重启，确保应用侧维护人员不进行介入的情况下应用切换成功。

主机层高可用：主机层的高可用主要需要在两方面进行探讨：主机硬件网卡可用性和主机上应用高可用。主机网卡需要符合高可用，测试方法为拔主网卡网线，看是否能切换到备用网卡，测试结果为：主网卡正常切换到备用网卡，应用无影响。主机上应用高可用依赖于中间件层和非标准进程的高可用，这个其他章节会展开探讨。

中间件层高可用：中间件的高可用有集群模式和HA模式。具体中间件层大多数系统都分为WEB层和APP层。WEB 层主要负责http协议的数据交互，WEB层的容器中主要部署的是JSP,html,JS应用。而APP层则主要是部署应用的具体负责逻辑代码，典型的代表就是EJB，WEB层调用EJB层走的是RMI协议。

WEB层的高可用可以从三方面进行测试，WEB层的主机CRASH高可用，实例HANG高可用和实例CRASH的高可用。WEB层的主机CRASH高可用和主机CRASH高可用原理相当，主要是在主机或者WEB实例CRASH的时候，其他实例能够平滑过渡，接管业务。WEB实例HANG高可用也需要实现，因为当实例有问题导致中间件实例HANG住的时候，系统要及时进行故障隔离，如果没有这层故障隔离功能，那业务请求继续发送到这个故障实例的时候，业务就会异常。所以在中间件这层需要最好有超载机制，有个超载，在负载均衡器向WEB服务发送http请求检测的时候，超载机制会发动一个服务器忙的信号，这样当实例HANG的时候，ARRAY负载均衡器就会知道目标实例很忙。当然负载均衡设备默认是没有http协议的检测机制，所以需要在代码层放上一个检测页面，然后在负载均衡器里面配置上页面检测功能。

APP层高可用性主要体现在三个场景，APP实例单实例HANG，APP实例单实例crash，APP实例主机CRASH。WEB层访问APP层主要是利用中间件层的cluster机制来做负载均衡和高可用，接下来我们围绕中间件WebLogic  cluster的集群机制进行讨论。

Weblogic支持集群技术，即让一组Server指向同一域名一起工作从而提供一个更强大、更可靠的应用平台。对于客户端而言，无论Cluster中有几个Server在工作，看上去都是一个。集群技术有两个最明显的特色：

(1)可伸缩性：Cluster对加入其中的Server在性能上没有限制，为了提高性能，当客户端的请求大幅增加时，可以动态地向Cluster中添加Server。并且，配置Cluster当一台机器的资源没有被完全利用时，可以在同一机器上启动多个Server，但要求每一个Server使用不同的IP，而不能用同一IP的不同端口。

(2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中，因此相同的请求可以有多个Server提供，并且Server间还可以复制状态信息。这样，当其中某一Server宕机或无法响应请求时，其它的Server会立即接管它的任务，从而把应用和客户端完全隔离开来。

下面来探讨下weblogic cluster的具体机制，每一个Clustered service,在每一个server上都会有一个instance，即一个replica，这些replicas集合在一起形成一个replica-aware stub。这些stubs负责客户端与相关的服务器段对象的通信，当客户端请求该service时，实际上是向stub发出请求，stub根据不同的算法调用集合中某一replica，如果调用失败，stub会检测到错误并重新调用其它的replica。Cluster支持多种算法：随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(Parameter-based routing)。Weblogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。为了提高Cluster的可伸缩性，必须保证充分利用每一个Server。Weblogic可以在不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡，从而使每一个Server都得到充分的利用。为了使Cluster具有高可用性，必须具备故障恢复的能力，这一点可以通过replica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求)，容错功能自动实现。而有些情况下，重新调用可能会导致某一service被请求了多次的错误结果。

例如：客户端C请求Clustered购物车服务中的additem()方法，replica-aware stub接收到请求，根据算法调用Server1上的service,Server1响应请求并返回结果，但在结果成功到达客户端之前，Server1出现错误。此时stub接收到错误信息，因此重新调用Server2上的这一方法，但实际上Server1已经将item加入购物车，这样就造成重复。为了解决这种问题，可以为服务添加一个唯一标识，如上述的additem()方法中可添加一个参数——序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。

APP层高可用主要依赖于中间件cluster和代码中的健康检测机制实现，有部分也依赖于先进的开发框架。所以在评估项目的时候需要严格把关，在开发框架这层一定要实现对应的高可用机制。并在项目上线的测试阶段，严格测试。说到这里，做到精致的话还有一个所有实例hang的友好页面提示功能，也就是说WEB层要判断当所有APP实例DOWN或者所有实例HANG的时候，如果调用不到APP服务，前台需要有个友好界面弹出来，需要在WEB层框架里面实现。

数据层的高可用：鉴于现在关系型数据库中Oracle用的比较多，我们就以Oracle RAC的高可用性进行探讨。

Oracle RAC主要支持Oracle9i、10g、11g版本，可以支持24 x 7 有效的数据库应用系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用，无需修改代码。在Oracle RAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。

(1)多节点负载均衡;

(2)提供高可用：故障容错和无缝切换功能，将硬件和软件错误造成的影响最小化;

(3)通过并行执行技术提高事务响应时间----通常用于数据分析系统;

(4)通过横向扩展提高每秒交易数和连接数----通常对于联机事务系统;

(5)节约硬件成本，可以用多个廉价PC服务器代替昂贵的小型机或大型机，同时节约相应维护成本;

(6)可扩展性好，可以方便添加删除节点，扩展硬件资源。

Oracle RAC机制配置vip时候需要用域名的技术，这给rac的高可用机制带来了润滑剂。

在一些非常核心的系统中，我们也可以用容灾数据库的架构，底层生产库和容灾库在存储这层做CA复制。如果碰到生产库不能承受压力逼不得已切换到容灾库的情况，这种容灾库的高可用机制可以起到一锤定音的效果。

以上是对于系统架构的高可用探讨，后续系统对高可用要求会越来越高，在高可用领域上也有更多的技术山峰等待我们去挑战。