SOA架构下多活的一些理解

核心是以客户的数据为唯一切分。用户、客户接入多中心负载实现多活，对外服务以域名的形式发布，流量负载依靠GTM实现。以用户为维度划分接入到那个中心做业务处理是最易实现的标准，随机接入对后台服务组件的数据要求无依赖。以客户为维度作为接入那个中心需要有统一的客户信息服务组件并实现在多中心间该组件的变化数据同步，具体实现可以考虑通过消息队列的方式将变化数据写入到其他中心的客户信息组件，并事先需要在客户信息组件上以客户数据为维度记录标识，当A中心的渠道层不可用时,首先GTM不会往该中心再发服务请求,同时后台将客户信息组件的客户标识做修订,将请求发到其他中心处理.举例：A客户不论在那个中心做接入，都需要在本中心或跨中心访问客户信息组件（需要企业信息总线支持跨中心服务路由，并支持全局服务目录）上查询该客户所需处理的业务应该在那个中心响应，并反馈给A客户端相应处理中心的接入界面。也可以考虑在渠道层有一份客户信息的数据副本方式实现。上述实现了渠道层多中心接入交易的多活.

对于后台产品服务组件的多活有几种可以考虑的方式,后台组件的数据同步其实也可以依赖于消息中心完成准实时的跨中心写入,对于数据一致性要求强的组件需要实现跨中心的同步写入才反馈前端,损失的是响应时间.上述的架构需要应用开发态的难度较大,基本这种技术方式很难覆盖所有的后台服务组件.对较小企业适用.

另一种做法就是多中心活单中心备份,1备多的方式,实现的技术手段也在磁盘层和数据库层实现.但数据库层实现维护的多套关系运维难度较大.另一种方式就是将查询拆离出来,所有后台组件的查询交易在其他中心处理,缓解主中心的负载压力,可以考虑采用数据库层技术实现.当主中心不可用时切换到查询中心处理交易,这个方案的核心是从业务\应用角度拆离查询交易和写交易,A/B中心的服务组件需在企业信息总线上同时注册查询\写交易的服务,并通过标识的方式做服务路由.损失RPO.RTO提升明显.

对于后台管理分析类组件因RTO要求不高，建议只做磁盘级的数据异地备份即可。

针对大数据类数据平台的特点，建议采用分布式文件系统的方式多点写入。
后续大家有什么具体问题欢迎大家提出交流！