如何从整体上考虑核心系统同城双活？

我觉得主要从以下几个层面考虑：

1. 从整体架构上来看，通常关注网络层、应用层、数据库层和存储层这几个层面，对于网络层要求双中心间二层打通，实现双中心间业务引流；对于应用层，采用GTM & LTM 联动技术实现跨数据中心保护；对于数据库层，采用跨数据中心集群部署，系统保留ADG等类型的复制模式；对于存储层，通过各家厂商的存储双活技术实现跨数据中心集群部署。
2. 从成本角度考虑，主要包含设备购买成本、建设成本、运维成本。这块比较难估算，因为不同地域，不同公司资源的情况下成本会有较大出入。设备的购买成本主要包含应用主机、存储、核心以太交换机等；建设成本包括前期规划、实验室确认参数、业务场景下业务测试、安装调试、真实环境压力测试、切换演练等方面，以上均需要人员成本的投入；运维成本取决于自动化程度的高低，通常情况下如果各节点完全可实现自动切换，相对的复杂度也有所提高，对于运维人员的技术要求有一定限制。
3. 从技术成熟度和方案及方案健壮性方面来看，刚才在上面第一点中提到的四个层次所使用的关键技术，目前已经非常成熟，各厂商均有成熟的解决方案。使用如Power上的双活方案，基于存储的双写复制的技术，数据库的基于事务日志回放的数据技术，以及基于系统级逻辑卷镜像技术，这些技术均有成熟的方案，在很多银行也有实际落地的案例，并且已经稳定运行了好多年；
4. 需要充分的风险评估，比如要解决数据库和存储仲裁不一致，集群发生脑裂的问题，如何解决应用负载会话一致性的问题，如何解决I/O时延，如何应对光纤抖动，如何解决资源高度冗余导致资源浪费问题。这些都需要在企业架构范围内考虑，也并不是所有问题都能在技术层面解决；
5. 除此之外，还需要考虑功能拓展性问题，对于功能的拓展性，以业务功能拓展性来说，当前设计的双活架构应不仅仅适用于核心系统，也适合支持未来其他重要的业务系统使用

这问题比较宏观，同城双活概况上来讲要考虑的层次有：

• 网络层
• 应用层
• 数据库层

 - 存储层
这几层的实现难度是不同的，通常网络层和应用层比较容易实现，成熟的产品和方案也比较多，因为这两层只分发请求，不处理请求，比较容易横向扩展，也基本不存在相互间需要同步数据的问题。问题中的负载均衡设备，网络DNS调度、应用横向部署等基本都在这层解决。
数据库层双活，就涉及到问题中提到的数据库和共享文件系统等问题，这些也有成熟的解决方案，比如数据的Extend RAC、分布式文件系统、GPFS等数据同步，但从这层开始就设计节点间数据同步的问题了，就需要根据实际的需求和成本的评估进行技术的取舍。比如线路不稳定、带宽不够等因素就不适合做同步双活和复制。
存储层的数据复制，在各厂家的中高端存储中是都能实现的，也要根据线路，距离等因素抉择复制的方式。