再谈高可用性(10.11)

今天做了下验证，对于Oracle OSB集群，在正式运行状态下，如果对应的DB数据库停机，这个时候并不影响服务本身的运行和服务消费调用，而只是会影响到新的服务部署操作。因此可以看到OSB集群在整个运行起来后，Admin服务器，服务需要的各类元数据实际上都已经导入到了内存中，因此并不会影响到服务本身的正常运行。在这种情况下可以看到OSB服务运行对DB的依赖度就更小，也进一步保证了服务运行高可用性。

对于SOA管控本身，在最初架构设计的时候，我们的思路就是对于管控平台和OSB引擎应该是完全独立状态，即管控平台APP应用加数据库即使宕机，对于OSB集群运行也不会有任何影响。要实现这个涉及到对两个关键部分内容的处理，具体为：

1. 对于安全控制部分的逻辑和涉及到的元数据，需要提前刷新到OSB集群的缓存中。

2. 对于OSB日志的记录，首先是写入到JMS服务器，然后写入到数据库，如果写库失败能够落地到磁盘。

做到以上两点后可以看到，对于管控平台应用和数据库，即使宕机对OSB集群运行也没有任何影响。那么如何出现整个Weblogic Cluster集群出现问题该如何处理？

在整个架构设计的时候，我们就采用分域设计的方式，即涉及多组完全独立的OSB集群，每组集群都有独立的Admin节点和独立的端口。那么如果集群A出现重大的故障，我们可以通过调整负载均衡设置，将集群A的所有节点请求全部转移到集群B上面。

当然你也可以启用OSB集群本身的Proxy代理路由管理节点，和上层的硬件负载均衡形成两级的负载路由。

上面分析都是针对数据库和中间件故障出现时候的紧急应对方法，这个故障是指即使对整个Weblogic集群或Oracle数据库进行重启，仍然无法解决问题的情况。在这种情况下，诊断问题往往就需要较长的一段时间才能够完成，必须有临时的紧急应对方法和策略。

而我们指的高可用性，还有一个层面就是OSB集群本身的正常高性能调用，如果出现问题了，比如内存溢出要通过重启才能够解决问题，那么本身也是一种生产环境故障。因此还需要考虑如何避免集群本身由于大数据量大并发量的调用导致的内存溢出，服务调用缓慢或不可能等问题。

在前面讲服务流量控制这篇文章的时候，重点就是在讲如何对服务调用的大并发量和大数据量进行控制，大出现这种异常调用的时候直接拒绝或抛出异常即可。

在前面谈整个架构设计和高可用设计的时候，我们谈到过，如果对于整个OSB集群里面某一个节点服务器出现调用缓慢或该服务器本身在Admin里面的状态不对的时候，最好是新的服务请求不再路由到该服务器节点上。而实际在配置完路由和负载均衡的时候，即使节点出现问题仍然会接收到路由分发。

对于这个问题，我们前面分析过，主要通过两种方法来解决：

1. 在硬件负载均衡上面配置一个探测的Http地址，负载均衡设备实时探测该地址，如果出现该地址无法访问则不再分发新的服务请求到该服务器。

2. 自己实现一个Java程序去监听所有的Server状态，当发现节点状态不对时候直接将该Server停用掉。

通过这两种方式，我们就可以快速的将出现问题的OSB节点从集群里面摘除掉，以防止有新的服务调用请求再分发到该节点上面。但是对于第一种情况，前期进行测试验证的时候，需要在负载均衡上面启用七层负载均衡，而七层负载均衡本身性能会比四层均衡会差很多。这也是一个影响到负载性能的关键地方。

分多组域来规划OSB集群是从12年开始实施Oracle SOA项目就采用的方法，核心目的就是避免一个大的单一集群出现问题后影响到所有的服务。对于服务分域，在前面也谈到过，主要考虑两种方式：

1. 按服务提供系统进行分域，比如ERP系统在A域部署，CMS系统在B域部署。

2. 按消费方系统或组织进行分域，比如集团消费用A域部署服务，子公司消费用B域部署服务。

注意不论是上面哪种方式，我们都在所有域部署全量的服务。

对于方式1，可以确保某个服务运行异常只影响到单个域，而对于方式2则可以确保某个消费端的调用异常只影响到单独的一个域。我们来看下两种方式的差异。

a)集团侧大量消费ERP的一个服务导致OSB出现性能故障

方式1：同时对集团和子公司都造成影响 ；但是对非ERP提供的服务不造成影响。 

方式2：只对集团造成影响，不影响子公司。但是会对集团侧会对非ERP提供的服务也造成影响。

在方式1下面可以看到虽然对集团和子公司都有影响，但是只会影响到个别服务而不是所有服务。而方式2的好处就是可以确保某个组织是使用完全正常。因此在一个类似多租户的应用架构模式下，单个组织的业务独立性和高可用性往往优先级更高，因此按组织区分往往更优。