数字化转型浪潮之下，采用云计算服务提升业务敏捷性、降低运维成本，成为了传统企业的优选方案。网易云资深解决方案架构师张亮通过某物流企业客户的实际案例，分享了传统业务系统在云上的架构设计如何满足数据高可靠、业务高可用的需求，并总结了传统业务上云的常见问题和解决方案。
物流企业业务系统上云需求
对于物流企业来说，内部沟通、供应链协同对优化供应链效率提升核心竞争力非常重要。作为行业翘楚，该物流企业客户建立了一个企业级移动办公平台，该平台集成了即时通讯（IM）、企业内部的ERP、OA以及核心供应链信息，用于支持内部员工的内部沟通协作，会议、日程安排以及供应链信息、ERP信息、OA流程审批和办理的查询，平台同时也提供给上下游合作伙伴查询供应链信息，以满足供应链协同的需求。该系统最初部署在客户自建机房中，服务于客户内部员工，但为了给一些大型合作伙伴提供类似的能力，客户同时采用了网易云支撑系统的建设和运行。
客户自建机房和网易云基础设施存在一些差异，例如客户自建机房有共享SAN和NAS，并采用带库和商业备份软件来满足数据合规的要求（存储冷数据、归档），MySQL数据库运行在物理机上，而网易云作为成熟的互联网服务，采并没有提供共享块存储服务，数据库是运行在虚拟机上的。
由于该系统要作为一项业务给第三方提供服务，项目一期覆盖数万名用户，考虑基础设施的差异性，客户最为关注如下四个方面：
数据安全性：影响客户业务的数据，包括员工通信记录、日程和供应链信息等，必须保证最高的安全性和可靠性；
业务可用性：此业务系统是客户为其客户提供的服务，因此对于SLA关注度非常高。客户要求在极端状况下（整个生产站点不可用）需要有快速业务恢复能力；
功能：应用探活、监控告警、内网负载均衡（LB）、内网DNS等功能，直接影响客户的运维能力和部署高可用业务的便捷性；
性能：客户原有数据库使用物理机，采用虚拟机担心性能不足，需要避免高并发场景下会的卡顿甚至崩溃的情况。
网易云跨机房容灾架构方案
客户原有业务系统底层是一个传统的同城主备容灾双机房架构（主机房宕机，则备机房接管），在应用侧采用了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要低很多。
文章来源：网易云