# 一、为什么要上云
1、为了数据合规；2、提高用户体验；
在全球战略的背景下，公司正在推进国际化战略部署，公司正在积极投入资源和力量来拓展海外业务，通过将应用、数据部署新加坡、法兰克福等中心，从而给全球用户带来更好的体验和减少数据合规带来的风险。。而海外公有云环境与国内私有云环境有一定差异。所以主要内容包括公有云与私有云的差距、双边数据互通、网关、内网错综复杂的微服务和各种持久化存储等。
WARNING
这里的国内和海外是用户当前所处的地理位置是国内(大陆)还是海外(含港澳台)，非国籍上的，如上海人在美国打开App，此时应当做海外用户对待。
# 二、主要差异
【1】网络延迟： 海外AWS与国内私有云之间有明显的网络延迟，根据不同区域延迟不同，比如新加坡到上海的延迟基本为80ms左右。迁移过程中，会出现部分应用部署在海外机房，但部分应用仍然部署在上海私有云上的情况。此时应用之间的互访以及双边数据的同步就会出现地理距离导致的延迟，以SIN为例，通常为60～200ms不等。对响应时间比较敏感的应用，需要考虑和下游依赖服务一起上云，避免跨区域访问产生高延迟。同时，如果调用链较长且复杂，还需要避免流量在两个region之间来回切换的情况，否则会导致耗时大幅增加，客户端调用超时。
【2】框架组件支持： 海外AWS上部署和使用框架与国内私有云有一些差异，主要包含：Redis/QMQ/MySQL/SOA等。
【3】网络流量： 海外AWS与国内私有云之间的宽带有限，尽量减少/减小两者之间传输的数据。
【4】成本费用： 海外AWS的费用大概是国内的10倍左右，根据不同的框架这个差距不同，开发人员需要进行代码重构，减少资源的使用。应用需要考虑对性能和效率做优化，尽量减少内外的资源开销，例如减少内存消耗，压缩报文，减少不需要的日志记录等等。
【5】数据新鲜度/一致性： 由于上述网络延迟问题以及合规要求，应用不允许直接跨region访问DB，只能依靠DRC的单向/双向的同步数据，上海与新加坡网络正常情况下，同步延迟在90ms，也就是说在这段时间内，两个region之间的数据是不一致的。如果有上海的A应用在更新数据库后，在新加坡的B应用立刻去查询该数据，会有概率获取不到该数据（即DRC同步延迟 > SOA/QMQ网络延迟）。如果对应场景对数据新鲜度要求不高，可以忽略该问题，但是如果对新鲜度或者一致性要求较高的话，需要考虑将读写点作为一个单元化整体一起部署到公有云上。
【6】容量风险： 单个AZ容量风险较高，易出现AZ间容量倾斜与容量不足，需要多AZ与Rebalance。
【7】弹性供应： 公有云弹性资源及资源整合众多，可有效降低成本，但需要动态平衡各资源供应不足风险。
【8】可靠性风险： 弹性场景下，故障域需进一步分级，核心链路架构上需要做到故障域隔离。
【9】研发费力度高： 用户发布感知AZ，多Region多AZ情况下Group众多，需要简化。
WARNING
公有云成本优化与优势在于弹性，而弹性强依赖于可靠性。单点的故障是无法消除的，可以控制风险不要成为一个系统风险，这就是韧性架构的思想。
# 三、名词解释
Region： 物理距离远，网络质量不保证，延迟+10ms~+100ms，隔离性极高，数据默认不同步。Region包含多个AZ；
Region(可用区)选择：选择适合的Region需要考虑用户需求、法律和隐私、基础设施和网络、数据跨境风险评估以及成本和效益等多个因素。根据以上因素和自身业务需求发展方向综合考虑，并进行详细的市场调研和分析，做出可用区选择：把新加坡SIN和法兰克福FRA作为业务出海部署的数据中心。
AZ： 物理距离近，网络质量保证，延迟1ms~4ms，隔离性高，数据默认可选同步。AZ包含多个DC；
网络接入层： 如何设置网络路由以实现可靠、高效的路由访问和数据传输，总共分三种场景。
【1】外网： 多路径、就近访问。考虑到不同地域之间的网络延迟和带宽限制，采用就近访问路由策略。即选择距离最近或带宽最大的路径进行数据传输，以减少延迟和提高速度。优势：保证同一用户就近访问网路链路最优的IDC。配置FRA、SIN多条路径进行数据传输，多路径路由。这样即使某一条路径出现故障，数据仍然可以通过其他路径传输。
【2】内网： 尽量访问同Region内的资源，实现同Region业务闭环。
【3】跨Region访问场景： 如果同Region内不存在需要获取的业务资源，必须跨Region访问时，则进行链路优化。比如，欧洲用户访问FRA通过专线链路请求SIN资源。这样避免直接跨洋访问其他Region，因网络跨洋传输、链路质量不稳定等问题导致网络耗时过长。
# 四、上云的挑战
在全球化背景下，除了要考虑全球的平滑部署来满足应用可用性和用户访问性能要求外，还需要考虑数据出海的安全性、法律合规和数据隔离等严格要求。通过以下几个角度举例：
# 全球部署
改造前，业务应用和数据都部署在原机房的同城：存在IDC A+B两中心的（同一个逻辑机房）同城双活。
与改造前架构特点相对比，如表格所示：
| 容灾级别 | 同一逻辑分区 | 用户分区 | 就近访问 | 数据多活 | 公共访问 | |
|---|---|---|---|---|---|---|
| 改造前(同城双活) | 跨机房级别 | 是 | 否 | 否 | 否 | 支持完善，成熟 |
| 全球多中心 | region级别 | 否 | 是，单元化分区 | 是 | 需严格遵守数据跨境政策 | 需支持多IDC场景 |
由此得知，多IDC场景下不可避免地需要去面临数据分片、单元化、数据冲突和业务幂等问题。相比传统分布式架构，不止是业务应用项目，还有PaaS平台基础设施在应对全球化技术体系都遇到了全新的挑战，需要有巨大的调整。
# 性能问题
面对全球范围内的用户的业务请求响应，难免会有用户因为网络跨洋传输、链路传输距离过长等问题造成的业务访问质量差。如何保证用户的请求访问链路最优，减少网络延迟，提供更快服务响应。
# 数据合规和监管
如何严格遵守不同地区针对数据跨境流动、数据泄露等数据安全问题颁布的相关法律法规。
# 数据出海问题
【1】数据一致性： 多IDC读写场景下，全球范围内用户在多个数据中心创建和操作订单，多个数据中心之间相互同步和操作订单业务时，应该如何保证数据一致性的问题。
【2】同步合规： 因数据跨境政策影响，一般不进行异地多活，需要如何避免数据跨境流动所带来的违规。
# 全球扩展性
以轻松地扩大业务覆盖范围为目标，新业务扩展时，如何通过对业务和数据进行改造操作，达到便捷动态调整数据存储策略，来应对动态多变的的数据合规政策。
通常一个大型项目会依赖/牵扯到成百上千个应用。如果将所有的应用都迁移到云上，从开发成本和硬件成本考量都不太合理。所以需要先部署依赖最少的服务，比如某个活动服务【只包含一个
API】等。
# 五、流量分析
【1】流量组成： 按协议划分，流量链路可分为HTTP、SOTP、QUIC三类。
| HTTP | SOTP | QUIC | |
|---|---|---|---|
| 场景 | 所有HTTP请求，无固定场景 | 国内外APP等 | 海外APP端 |
| 链路选择 | DNS/CDN(当前特指Akamai) | APP端保底IP列表/动态IP下发 | APP端保底IP列表/动态IP下发 |
【2】请求链路： 公司用户遍布世界各地，用户 — 接入层（SLB/Gateway等）— 服务 三者很可能不在一个地区，设计合理的访问链路，对用户体验提升明显。
宏观链路如图：
链路可分成两个阶段看：
Region前：用户请求选择合适的Region访问。链路选择作用于该阶段。
Region内：请求通过接入层进入Region后。流量调度作用于该阶段。
# 六、链路分析
链路选择阶段（Region前） ：目前链路选择主要遵循用户流量就近访问接入层的原则。链路选择是怎么实现的？
| HTTP | SOTP | QUIC | |
|---|---|---|---|
| 选择能力 | DNS + GTM(Global Traffic Manager)/CDN（Akamai） | App端无线网络框架自实现选路 | App端无线网络框架自实现选路 |
| 选择逻辑 | ● GTM即全局流量管理, 按负载权重、地域或运营商属性来进行流量分配, 为用户提供最佳访问IP。● CDN也是GTM解析的结果，单独列出是因为Akamai也具有链路选择能力，如根据路径、用户地理位置等选择请求源站。域名开启CDN加速后，一般海外用户的请求会被GTM解析到CDN● Tips：可通过webinfo查询域名的解析链，或通过dig(用海外DNS)检测域名是否开启Akamai加速 | ● App需配置所有的入口IP，获取IP有两种(共存)方式：1、代码内置IP列表（静态）2、MCD(前身叫MTP)平台动态下发● 网络框架会根据一定的策略(链路质量/ App当前网络属性/地理位置等)选择合适的链路IP发送请求 | ● 同Sotp协议● 目前只有海外 App在用 |
流量调度阶段（Region内链路）：该阶段是指请求进入Region后，请求是否允许在当前Region处理，否则转发至其他Region，实现流量跨Region的调度转发。
Region内请求链路：一般有以下几种场景（可自行甄别自己服务的请求链路）
链路1：SLB(Http) → 后端服务
场景：一般为非SOA服务，如nodejs、.net服务等，也存在一些Mobile Service。
识别方式：paas/captain查看是否有外网SLB入口。
链路2：SLB(Http) → H5 Gateway → 后端服务
场景： 接入了H5 Gateway的服务，一般都是SOA服务，也存在部分非SOA服务。
识别方式： 在Gateway Portal上根据AppId或SOA ServiceCode查询服务是否接入H5 Gateway(强调：Gateway团队有多套GW，这里是H5 Gateway，非其他)。
链路3：TCP Gateway(SOTP) → 后端服务 场景： 使用SOTP协议的Mobile Service。Tips：TCP Gateway仅限App端使用。
识别方式： 可在MTP平台根据Sotp Servicecode查询。
链路4：TCP Gateway(STOP) → H5 Gateway → 后端服务
场景： 接入了H5 Gateway的服务，且调用方为App。一般都是SOA服务，也存在部分非SOA服务。
识别方式： 先明确调用方必须为App，在Gateway Portal上根据AppId或SOA ServiceCode查询服务是否接入H5 Gateway(强调：Gateway团队有多套GW，这里是H5 Gateway，非其他)。
链路5：QUIC → H5 Gateway → 后端服务
场景： 接入了H5 Gateway的服务，且调用方为海外App（截止目前只有海外App使用了QUIC）。一般都是SOA服务，也存在部分非SOA服务。
识别方式： 先明确调用方必须为海外App，在Gateway Portal上根据AppId或SOA ServiceCode查询服务是否接入H5 Gateway(强调：Gateway团队有多套GW，这里是H5 Gateway，非其他)。
# 七、实现成本最优
主要从三个方向实现成本优化：数据洞察（了解钱花在了哪里，应用多少钱，每一条消息/日志多少钱，并查看是否合理。Cost/Efficiency/Usage/Capacity/Budget）、成本节省（通过“混合云弹性调度平台”在保证可靠性的前提下自动优化成本）、成本运营（由各BU研发统筹成本相关问题，是否需要重构项目，缩容等操作）。主要是培养成本意识，追求成本、效率、质量的动态平衡
# Cluster Autoscaler
【1】复杂动态的机型&价格： OnDemand按需实例，即用即扩。Spot竞价实例，可被AWS主动回收。Saving Plan(SP)预付费折扣包。下面是各机型组合单价比例：
| Intel架构 | Amd架构 | Arm架构 | |
|---|---|---|---|
| OnDemand | 1 | 0.9 | 0.8 |
| OnDemand+SP | 0.6 | 0.5 | 0.4 |
| SpotInstance | 0.4 | 0.35 | 0.3 |
【2】挑战： 不同机型扩容成功率随时间动态变化。扩容请求需要在2min左右完成。
【3】方案： 监测数据，周期性更新高优机型列表，剔除失败率高的机型。扩容失败时，Autoscaler自动切换机型。Spot扩容失败时，调度器自动切换到OnDemand。
【4】方向： Autopilot纳管Autoscaler，自动优化参数及机型列表，实现成本扩容成功率最优。下面是不同机型组合随时间动态变化监控图
# SmartVPA
【1】海外AWS应用特征：利用率低（Avg Cpu 8%）长尾明显，实例数少，SmartHPA无法充分发挥作用。
【2】方案：数据监测，动态超卖，降低实际资源占用。实时监测超卖热点，驱逐与再平衡。
【3】效果：海外超卖比3~4倍，等价于降低3~4倍的资源使用。超卖比随切流及负载情况动态调整。
FRA-AWS切流导致利率上升，超卖比自动降低。
# 方案
【1】公有云上缓存使用ROR（冷热分离，减少内存使用），已替换Redis,。
【2】公有云上的ROR，采用AMD芯片，价格一致下，性能提升10%~15%左右。
【3】迁移期间还未接入流量的实例，不需要高可用，进行单实例部署，云上的DB都是4C16G比较弱，私有云的都是40C256G，如果流量切过去之后，会升配置。
【4】RDS最小化部署，流量上升才进行提配。