一、架构梳理

需要清楚上云服务的架构，入口是谁，入口的应用依赖了什么应用和存储，依赖的应用又依赖什么应用和存储，总共有多少层。可以借助工具，例如BAT/等

二、范围选择

哪些系统需要上云。原则是最小成本上云。主要从两个方面考虑合规（设计数据安全的应用）和成本（从部署的那一刻就可以收到账单，AWS的成本是上海的好几倍）

分析：
【1】是否存在冗余的应用和存储。 应用的冗余比较少，存储的比较膨胀，特别是Redis。
【2】是否有海外暂时不需要的业务。

改造：
【1】减少冗余
【2】屏蔽掉不需要的业务

最后确定范围

三、组件上云

SOA海外应用访问国内应用的三种方式：
【1】虫洞： 主要给服务访问，你的服务上了云，但是依赖的服务因为某些情况不适合出海，可以通过虫洞访问回上海，本身是新加坡到上海之间的一条链路。走的是公网，但是有加速。框架给的平均响应时间是73ms作用。
【2】专线： 两个机房之间拉了一条专线，成本高，使用与稳定性要求特别高的应用。当前上海到香港之间就有一条专线。
【3】代理： 直接走公网，都需要通过代理服务器。

客户端流量分配：APP通过TCP或者Quic访问时，框架会根据性能找到最快的接入点。通过HTTP访问时，会根据DNS自动解析到合适的收入点。接入点主要是两个方向，一个是上海，另一个是新加坡。我们根据上面的规则和性能，引导东南亚的用户到新加坡，日韩的用户到上海，其他地方也是依据性能去合适的地方进行接入。新加坡的应用接入GateWay之后，会基于策略访问新加坡的服务或者路由到上海，如果新加坡没有部署的时候，也会路由到上海，这个本身就是框架支持的一种策略。同样，也可以通过上海的GateWay路由到新加坡。

QConfig上云

【1】QConfig上云默认不用做任何事情，QConfig会从母环境读取现有配置。
【2】如果需要云上有不同于其他环境的个性化配置，需要在云上的子环境配置。
【3】子环境的配置只到文件级别，不到字段级别。

MySQL

【1】云上的应用只会访问云上的DB Cluster节点，和上海的DB是隔离的。
【2】可以通过DRC在上海和AWS之间建立单向或者双向复制。
【3】延迟平均100ms以内。
【4】复制延迟监控：
【5】代码无需改动。

Redis

【1】云上的应用只会访问云上的Redis和上海隔离。
【2】部署Redis有三种方案：
  ■ 对于不同的IDC内部独立读写，IDC之间数据隔离。
  ■ 上海写并且Xpipe单向同步到云上，云上只读。平均延迟时间200ms。
  ■ 双向Xpipe同步。
【3】可以非对称框架（上海和云上分片不同）
【4】代码无需改动
【5】延迟监控

QMQ

【1】支持公有云和上海IDC之间跨区域发送和消费消息。
【2】需要向Admin申请配置消息同步。
【3】延迟时间 250ms

四、监控与测试

五、收益

【1】合规
【2】用户体验：减少用户响应时间，提高用户体验。减少了虫洞传输的时间，按照70ms的延迟的话，可能节省140ms的时间。

(adsbygoogle = window.adsbygoogle || []).push({});