传统业务上云：跨AZ容灾架构解析
本文由 网易云 发布前端
数字化转型浪潮之下，采用云计算服务提高业务敏捷性、下降运维成本，成为了传统企业的优选方案。网易云资深解决方案架构师张亮经过某物流企业客户的实际案例，分享了传统业务系统在云上的架构设计如何知足数据高可靠、业务高可用的需求，并总结了传统业务上云的常见问题和解决方案。数据库
物流企业业务系统上云需求后端
对于物流企业来讲，内部沟通、供应链协同对优化供应链效率提高核心竞争力很是重要。做为行业翘楚，该物流企业客户创建了一个企业级移动办公平台，该平台集成了即时通信（IM）、企业内部的ERP、OA以及核心供应链信息，用于支持内部员工的内部沟通协做，会议、日程安排以及供应链信息、ERP信息、OA流程审批和办理的查询，平台同时也提供给上下游合做伙伴查询供应链信息，以知足供应链协同的需求。该系统最初部署在客户自建机房中，服务于客户内部员工，但为了给一些大型合做伙伴提供相似的能力，客户同时采用了网易云支撑系统的建设和运行。缓存
客户自建机房和网易云基础设施存在一些差别，例如客户自建机房有共享SAN和NAS，并采用带库和商业备份软件来知足数据合规的要求（存储冷数据、归档），MySQL数据库运行在物理机上，而网易云做为成熟的互联网服务，采并无提供共享块存储服务，数据库是运行在虚拟机上的。安全
因为该系统要做为一项业务给第三方提供服务，项目一期覆盖数万名用户，考虑基础设施的差别性，客户最为关注以下四个方面：网络
数据安全性：影响客户业务的数据，包括员工通讯记录、日程和供应链信息等，必须保证最高的安全性和可靠性；架构
业务可用性：此业务系统是客户为其客户提供的服务，所以对于SLA关注度很是高。客户要求在极端情况下（整个生产站点不可用）须要有快速业务恢复能力；并发
功能：应用探活、监控告警、内网负载均衡（LB）、内网DNS等功能，直接影响客户的运维能力和部署高可用业务的便捷性；app
性能：客户原有数据库使用物理机，采用虚拟机担忧性能不足，须要避免高并发场景下会的卡顿甚至崩溃的状况。负载均衡
网易云跨机房容灾架构方案
客户原有业务系统底层是一个传统的同城主备容灾双机房架构（主机房宕机，则备机房接管），在应用侧采用了Redis缓存、Kafka、内外网负载均衡，是一个类互联网架构。系统采用商业硬件全局负载均衡（GSLB）作站点间的容灾，后端存储有传统的SAN、NAS、磁带库和VTL（虚拟磁带库）等，持久化数据大部分在存储上，经过专线和存储能力作跨站点的快照同步和数据同步复制。通常说来，商业磁盘阵列的高级License会带这些功能，但高级License比较昂贵，且该方案的容灾能力极大依赖于阵列设备的容灾能力，一旦阵列设备出故障，数据存储就危险。此外，Jetty、Java应用间是软负载均衡的设计，对外有硬件负载均衡。
该业务系统在网易云上的部署是一个分步试水、逐步完善的过程。业务系统的即时通信能力由网易云通讯服务（云信）SDK提供底层能力，客户本身作上层的封装，云信和应用系统部署在不一样的机房，经过网易云内部高速通讯。刚开始的架构相对简单，没有考虑容灾，Redis、Kafka、RDS、NAS都映射原来的系统架构，GSLB取消，用Elasticsearch作日志搜索。
以后是跨机房容灾的完善。针对原有系统，运维部门每隔半年会进行一次容灾切换的演练，因此客户但愿云上容灾也能知足数据可靠性、业务可用性的需求。
张亮介绍，云上跨机房容灾根据机房距离和网络延迟，能够分为两种：一是跨可用区（AZ）容灾，通常用来支持须要双活的业务；二是跨Region的容灾，通常是异地，两个机房比较远，网络延迟没法知足双活的要求。网易云为客户设计了跨AZ容灾的方案。客户最初在云主机中本身搭建Redis和Kafka，后来发现须要本身关注监控、高可用，但这是网易云现成的Redis和Kafka服务自带的功能。
网易云提供的容灾服务包括：
负载均衡：提供跨机房的负载均衡服务（NLB），每一个机房是2个NLB实例（主备），但客户流量进来只看到同一个公网IP——若是生产站点AZ1宕机，路由会实现IP漂移，把IP关联到灾备站点AZ2上，客户不须要关注IP的变化。
数据持久化：提供跨机房的RDS高可用实例，生产站点主备2个实例，灾备站点1个实例（考虑成本因素），经过内部DNS访问，一边的RDS宕机，对于应用来讲是无感知的，由于系统会自动把域名解析到灾备站点的RDS实例上。
文件系统服务：经过跨机房的复制作数据同步，对于用户来讲，数据持久化不须要管。
Kafka：经过MirrorMaker作跨机房同步，它的消费者能够在灾备站点去消费Kafka和消息，若是只是部分服务宕机，系统能够提供跨机房的访问，固然延迟会比同机房高一些，这取决于应用对访问数据延迟的要求，若是延迟要求很是高，可能须要作应用单元化，尽可能减小跨机房的访问，把一些对延迟敏感的请求放在一个机房内，这是业务架构上的设计。
张亮补充说，网易云支持应用去访问另一个机房的RDS，但应用之间的容灾还须要客户本身作跨机房部署。NLB能够经过内网DNS判断请求是从哪一个AZ过来的，从而让应用可以正确访问对应的底层服务。
跨Region和跨AZ不同，后者在同一个VPC里面，前者在两个不一样的VPC里面，网络延迟比较高，NLB没有提供跨机房高可用实例，对外IP不同，须要外部有一个相似GSLB或者DNS的服务去作流量切换。其余的如RDS、Kafka的复制，依赖于VPC Peering，须要在核心交换机上作一些后台操做，让两个VPC能打通（默认内网是不通的），不然须要经过公网再从前端路由绕回来，没法经过机房内部专线直接访问。
跨Region的RPO（恢复点目标）比跨AZ要差，跨AZ的RDS能够作到RPO等于0，两边都写入之后，才能返回“写成功”。而跨Region，一边写完就返回“写成功”，若是数据只是在主站点写成功，还没有复制到灾备站点时主站点宕机，这就会形成数据永久丢失。传统架构下的Oracle RAC跨机房集群、存储双活的方案，其实每一次数据写入都是双写，才能实现双活。
因此，跨Region容灾通常用于两地三中心的异地灾备，业务可用性要求高的状况下，建议客户采用跨AZ容灾的部署架构。对于客户而言，基于云的跨AZ容灾方案，只是在容灾、监控、服务的使用方法上和自建机房有所区别，但知足RPO和RTO的要求没有问题。
张亮补充说，跨AZ容灾切换是客户本身作切换，RPO取决于客户运维团队多久才能感知故障、多久把灾备站点服务配置好，由于客户应用的配置比较传统，提早把后端的服务IP、DNS域名写入配置文件，而不是采用服务注册/服务发现的机制动态发布。若是进行应用微服务化改造，RTO还能够有很大的提高空间。
上云常见问题与对策
对于托管IDC、自建机房的传统行业而言，云基础设施带来的变化确实须要虑周全。基于网易云支撑传统业务上云的经验，张亮最后总结了传统业务上云的常见问题和解决方案。
云上不多有共享块存储。SQL Server提供的Always-On故障转移集群高可用方案须要共享块存储的支撑，但企业如今可使用无需共享存储的SQL Server高可用方案，好比日志传输、Always-On可用性组等SQL Server 2012及以后的版本都支持的方案，都不依赖于任何共享存储形式。
VPC网络不支持广播、多播，而一些应用须要经过广播、多播的形式作集群。
Keepalived：升级到支持单播的新版本，在配置文件中指定使用单播，便可在VPC网络下正常工做。
Tomcat经过广播支持集群成员通讯：一是使用Tomcat-Static cluster membership这种静态方式，经过在配置文件中手动告知集群节点有哪些成员，弹性伸缩比较麻烦，只适合规模小的业务；二是无状态化，把Session从Tomcat分出来，放到Redis之类的服务中。
采用N2N Peer-to-Peer VPN的方案，在VPC网络上再构建一个VPN网络，就能够广播，但这种方式会有性能损耗，能够用于POC测试、概念验证，生产环境慎用。
无物理磁带库。一些行业有合规要求，不常常访问的冷数据会存储在磁带库中。在云上有两种方案：一是经过云服务商提供的VTL存储网关，备份软件链接网关，能够把后端当作磁带库使用；二是如今很多的备份软件已经支持主流云服务商的对象存储服务，直接在备份软件中把数据备份到对象存储，成本比磁盘阵列或者NAS要低不少。
网易云为您提供对象存储、负载均衡等服务，感兴趣的朋友欢迎点击免费试用。
了解 网易云 ：
网易云官网：https://www.163yun.com/
新用户大礼包：https://www.163yun.com/gift
网易云社区：https://sq.163yun.com/