最近在琢磨上云的事情，本意是找找如何迁移上公有云。调研了一下网络，惊喜地发现，搜索出来的结果主要都是运营商制定的一些相关IT系统上云（企业私有云）规范。为什么会这样呢，我想确实有其原因。在国资委管辖的97个央企（会有合并等变化）中，银行的IT自主研发能力毫无疑问是最强的，从我经历的大客户、面试招聘的情况均可以看出来：除了互联网，也就银行的还可以（人数不多）。和马云说的，“未来每年将会向社会输出1000名在阿里工作10年以上的人才”相比，金融行业差远了。运营商是国资委体系下，另外一个重度依赖IT的行业。和银行一样，运营商也有非常庞大的内部IT系统，内部IT系统上云（企业私有云），但是运营商的核心IT系统，基本上都是合作单位开发的。因此和银行自己在家上云不同，运营商上云严重依赖于一个产业链，因此运营商IT系统上云成为社会化的话题、并被搜索引擎排到最前面不奇怪。
一、运营商提出的3阶段上云（企业私有云）：去IOE、云化（PaaS）、云原生
从研发模式看，运营商和银行有很大的不同，运营商的BOM（业支、网络、管信）三大系统基本上100%都是由运营商出需求，厂家完成的。以至于云计算到来的时候，运营商所谓的上云，开始基本上就是集中化，这种“假上云”的方式后来才得到了改善。但方案并不是去自主研发BOM系统，而是制定更多的方法论和管理要求，促成厂家上云。其中，以中国电信上云的方法论最强，而且看上去执行的情况也不错，当然，真实情况和效果不可知。电信确实使用了自主研发的TeleDB（MySQL改）做了去IOE（附录1），据说引起Oracle的不满。第三方公司还写了专利，可以参见附录3。
结合中国电信云网运营部大数据和AI中心在2021年3月撰写的一个汇报材料《中国电信IT全面上云工作方案》（参见相关信息，作者：肖彦昌），可以得到很多有价值的信息。参见下面几个图，细节不多，偏方法论。具体细节参见附录2。
- 首先是给上云制定了3个层次（1）去IOE（2）云化改造，这主要是统一PaaS能力和云化（3）打造上云标杆，也就是真的云原生化
- 技术上提供了4个工具：云桥（能开DCOS）、云翼（统一PaaS）、云道（DevOps）、云眼（AIOPS）
- 流程上提供了5步骤10流程：分析、方案、选型、实施部署、交付运维。其中非常细致，还涉及到应用存储过程改造，当然，看到这里，我们也知道此乃存量Oracle的系统了。
2020年数据：运营商财经网获悉，截至11月底，中国电信全网整体上云率为33%，累计上云972套系统，其中BSS上云率为46%，OSS上云率为17%，MSS上云率为30%，DSS上云率为29%。
此外，甘肃、新疆、福建、陕西、湖北等整体上云率超40%。下半年全网新增371套IT系统上云，四川、湖北、安徽、江苏、甘肃等新增上云系统192套，占比53%。
具体的信息，可以参加参考文献和附录。
比较有趣的是2020年CNBPS组织了一个闭门会议，主持人是灵雀云赵昕，邀请了移动赵淳、联通张亚威和电信肖彦昌的三位技术专家分享各自的云化方案和进展，挺有意思的一段是肖彦昌说的，“另外两家运营商刚说他们“盘字辈儿”和“天字辈儿”的平台，其实我们也有四个平台，我们是“云字辈儿“的PaaS底座，我们叫“云眼”，然后类似监控系统就是我们叫“云翼”，然后还有一个叫DevOps的流水线的系统叫“云道”，还有一个数字化能力开放平台我们叫“云桥”，这是我们目前在做的事情，这四个平台目前已经在支持全国近4000套系统上云”
二、Gartner提出的上公有云5R方法论：Rehost、Revise、Rearchitect、Rebuild、Replace
与运营商作为甲方给乙方提要求式的方法论不同，咨询商（主要是Gartner）站在相对中立的角度，客观分析了公有云客户上云面临的实际问题，给出了另外一套方法论，看上去更为务实和可行。下面的内容多数引自Gartner的2022年6月前后的几个报告，主要是文献[8]，为了便于理解，简化了部分内容（原文参见文后Gartner报告），老外写文章很啰嗦。我们先看结论：
1.重新托管（Rehost）：将应用程序从当前物理或虚拟环境“直接迁移”（Lift & Shift）到云平台上，尽可能少地更改应用程序及其运行时环境。在旧迁移方案中，必须重新托管具有强依赖项的应用程序（例如，数据引力、与商业许可证捆绑在一起）。
2.修订（Revise/Replatform）：“直接迁移和调整”您的应用程序，使其在公共云中管理更安全、更轻松、成本更低。核心应用程序架构保持不变，但部分云优化。例如，利用云上数据库 PaaS 或容器即服务 （CaaS） 的能力。
3.重新架构（Rearchitect）：对应用程序进行实质性的更改或重构，使其达到云优化的体系结构，同时利用云原生功能。重新架构适用于针对云应用程序平台服务（如 Kubernetes、fPaaS 和无服务器容器能力）的迁移项目。
4.重建（Rebuild）：通过从头开始重写应用程序，保留核心业务逻辑和算法，但放弃遗留代码并在云平台和服务上重新构建来优化云。通过从头开始重写应用、保留核心业务逻辑和算法，但放弃旧代码并在云平台和服务上重新构建，针对云进行优化。
5.替换（Replace/Repurchase）：将应用程序替换为第三方 SaaS 替代方案，配置或扩展 SaaS 环境以满足要求，并（如有必要）将旧数据迁移到新环境中。将现有的商业应用程序替换为 SaaS 解决方案，配置或扩展 SaaS 环境以满足要求，并在必要时将遗留数据迁移到新环境中。
这个图充分比较了5种迁移模式的各种成本比较。长期看，模式1和2成本最高。因此I&O领导就要在“长痛”、“短痛”中做出选择。
有意思的是，国内一些文章演绎了Gartner的5R，提出了6R等模式（Re-host、Re-install 、Re-platforming、Refactoring、Retire、Retain），但是本质还是前面5个R，注意Gartner专门针对中国的报告中，实际上已经把5R变成了7个R，但是Revise和Replatform是一样的，Replace和Repurchase是一样。注意分辨即可。
Gartner方法论的推演过程，请参考附录0。
三、主流云厂商的实践
虽然Gartner的报告指出云厂商并不重视上云迁移，上云方案能力也不行，然而通过查看国内几个云厂商的产品体系，发现这些厂家实际上都布局了相当的上云支撑能力，不仅有线下的服务（例如移动云，就有很强的线下自有省公司渠道和能力，而阿里云正在模仿华为构建传统线下区域x行业的矩阵式线下交付能力）。而且均有线上的服务类产品和迁移服务平台，我们分别来看看。需要说明，各个厂家还有相应的数据和数据库迁移工具，这里不做讨论。
3.1 阿里云
阿里云有一个云迁移中心（Cloud Migration Hub，简称CMH）一站式迁移平台。为广泛用户的迁移上云项目提供自动与智能的系统调研、云上规划、迁移管理，简化和加速用户上云过程，辅助用户业务化可视化管理迁移全生命周期。支持4个主要能力
（1）多源适配。可以迁移IDC、境外云、境内云，提供咨询等一条龙服务，还有可视化的成本分析等工具。
（2）数据安全。可以“导出上传”，也可以“自动上传”。
（3）业务全景。可以针对存量业务做集团分类，排序迁移，有全景视图，可以参加下面的图。
（4）任务集成。可以和阿里云迁移工具集成、OpenAPI集成第三方工具。
3.2 腾讯云
腾讯云提供迁移服务平台（Migration Service Platform，MSP）。整合了各种迁移工具，并提供统一监控。用户在迁移时可选择腾讯云官方迁移工具，也可选择官方认证的第三方迁移工具。迁移服务平台帮助用户方便快捷的将系统迁移上云，并清晰掌握迁移进度。迁移服务平台 MSP 不收取任何额外费用，用户只需为使用的迁移工具及资源付费。有5个重要特性：
（1）统一监控。在 MSP 中统一监控所有的迁移任务，并按照迁移类型聚合展示，帮助用户不会在大规模的复杂迁移过程中被繁杂的迁移数据所淹没。
（2）可视化操作。所有迁移任务状态都可以通过可视化图表进行查看，友好的人机交互界面从不同维度对迁移信息清晰展示，帮助用户对迁移情况一目了然。
（3）简单管理。在 MSP 中，迁移任务可以按项目分组管理。无论是跨时间段分批次迁移，或完整系统一次性大规模迁移，监控同样井井有条。
（4）广泛支持。在腾讯官方迁移方案和工具之外，集成了众多的合作伙伴，为用户提供丰富的迁移选择，无论官方还是第三方，都可无缝连接。
（5）可靠性认证。腾讯云对第三方迁移工具的能力和迁移经验进行严格的评估和认证，确保用户所选方案和工具皆安全可靠，业务迁移万无一失。
3.3 百度智能云
百度云提供了一个“业务迁移解决方案”，基于百度十多年基础架构的技术沉淀，集合了专业的售前方案咨询、迁移上云方案评估、迁移实施服务、迁移优化验证等，为客户提供从企业应用架构、业务系统、数据库到网络配置、安全优化的一站式迁移服务，助力企业实现业务系统的快速平滑上云。可以下载白皮书，但是需要填表，填表了也不给下载… 网站给出了一个方法论，参加下图。图中给出了3个主要阶段，其中迁移分为线上和线下的。还有一个架构的规划，这个也非常重要，其实是深度上云，涉及到企业组织架构上云（可能不是必选），然后就是具体的迁移，提供了计算（镜像）、网络和存储的迁移，另外就是数据库迁移DTS，这个名字和阿里云、腾讯云是一样的。但是内涵方面，腾讯云和这两个不太一样。
3.4 华为云
华为云毕竟是做项目起家的，对于企业上云有丰富的经验，给出了体系是这几个云最为完整的，有一个“企业上云中心”解决方案套件。可以看到覆盖了各种上云的可能性。包括建站、出海、上云等各种场景。我们主要就看看迁移上云。
可以看到企业上云解决方案是分技术场景的，可以看做是业务场景之下通用的部分，涉及到的领域很多，包括灾备、网络、Web、ERP、网站、容器（云原生）等技术场景。具体包括8个主要步骤，是不是很眼熟，这个和华为做项目的方法论，几乎一样的。其中有个业务压测，在云场景下确实比较重要，也是其他云厂商忽略的内容。
3.5 移动云
移动云提供了“云迁移解决方案”帮助客户上云。移动云采用自有迁云服务，结合云主机、云硬盘、对象存储等产品，协同生态合作伙伴云融云迁移、鼎甲云迁移等，面向各级政府机关、企事业单位提供便捷的上云迁移服务以及更优惠的云上环境及资源。方案支持公有云和私有云等各种场景上云，也涵盖了从计算、存储和数据等全方位的迁移。结合移动网络和云技术优势，有如下特点：
（1）零停机。迁移过程无需中断业务，新数据增量同步至目标端。
（2）工作负载一体化迁移。操作系统-应用-数据一体化迁移至目标端。
（3）极快的迁移速度。千兆带宽下迁移任何数据可达280GB-420GB/h。
（4）一键上云。一键实现业务系统上云，摆脱重新部署苦恼。
（5）X2X迁移。支持P-V-C间在线无缝迁移。
（6）智能管控。迁移任务统一管控，管控迁移进度。
小结：
迁移上云是一件看上去简单，实则是目前云计算进入深水区的重要技术，这个方面AWS走的可能更远，但是对于中国的政企客户系统来说，AWS也未必能覆盖全部的领域。这需要国内云厂商，特别是国家背景的云厂商付出更多的努力。从方法论上看，Gartner的5R方法更为全面，涵盖了中国运营商内部上云的方法论（资源上云、数据上云、云原生）。但是正如附录0中分析的那样，仅有方法论还不够，还需要解决方案和技术支持，特别是线上和线下的工具。整体看，国内的云厂商中，华为可能是走到了前面，华为作为老牌ICT厂家，深知政企客户的痛点。但是从线上工具方面看，阿里云可能更为全面。对于移动云来说，还要继续追赶！
相关信息
03、https://www.docin.com/p-2483848049.html
05、基于TeleDB和MySQL数据库的分布式数据集成系统及方法与流程
07、三大运营商如何玩转云原生？｜CNBPS 2020演讲实录
08、Break Down 3 Barriers to Cloud Migration
09、Move From Siloed Infrastructure-Led Disruption to Reusable Services（5R）
10、How to Build a Cloud Migration Cost Estimate
11、Ignition Guide to Creating a Migration Plan for Public Cloud
12、Quick Answer: Four Cloud Migration Challenges Infrastructure and Operations Leaders Need to Address
14、华为云：上云迁移服务
15、百度云：业务迁移解决方案
16、腾讯云：迁移服务平台
17、阿里云：云迁移中心
19、Optimize Infrastructure Patterns to Extend Control to the Edge and IoT
20、Best Practices for Public Cloud Adoption in China
21、Migrate an Oracle database to Aurora PostgreSQL using AWS DMS and AWS SCT
22、AWS Aurora Vs. Oracle: What To Choose And Why To Migrate
23、How to Migrate Your Oracle Database to Amazon Aurora
24、移动云：云迁移解决方案
附录0：Gartner方法论的推演过程
1、面临的主要问题
虚拟机（VM）的进步使基础架构和运营领导者（I&O Leaders）能够将中型应用程序（占用2TB~6TB内存）迁移到云中，但他们还无法在单个虚拟机上迁移大于6TB的应用程序。I&O领导者的任务是管理各种各样定制化应用程序组合，这些应用程序不是为在云中（或类似云的本地基础设施）运行而设计的。云 IaaS 提供商提供底层基础架构，擅长提供有SLA保证的运营和实施服务。但云IaaS提供商通常依赖合作伙伴获得专门的过渡和转型技能，从而导致与I&O之间存在技能差距。
为了分析方便，Gartner咨询师做了一个假定：到2024年，15%的企业应用程序将在容器环境中运行，而2020年这一比例还不到5%。到 2024 年，30% 的自定义企业应用程序将在容器环境中运行，高于 2020 年的不到 10%。注意，这是一个假定，但是确实可能发生，而且很有可能，特定种类应用的很大部分甚至会直接使用Serverless模式，进一步压降成本、提升效益。
2、上云步骤和建议模式
负责数据中心基础设施的I&O领导者必须：
（1）通过根据大小对应用程序进行分类，确定每个现有应用程序（即云与托管）的最佳迁移路径。
（2）与应用程序团队合作，对老旧应用分类处置：重新配置原先高度定制化的应用程序（用于托管）；还是重新构建轻度自定义应用程序（用于云）来标准化老旧应用程序。
（3）通过向传统I&O团队补充战略合作伙伴或系统集成商（SI）的过渡和转型技能，推动应用现代化工作。
为了在管理成本和风险的同时提供高效的基础设施服务，I&O 领导者必须给企业应用提供标准化、现代化和可重复的基础设施（请参阅[10]）。超大规模公有云基础架构的出现为提高基础架构配置（如 IaaS）的可重复性创造了新的或改进的方法。这种改进的基础结构配置还具有如下属性，这些属性对于创建超大规模公有云所需的工业自动化和可重复性级别是必需的。它们还有助于提高企业 IT 的敏捷性，但最适合现代、类似云的应用程序和基础架构。
（1）不可变（Immutable）：一种在 IT 资源上管理服务和软件部署的方法，其中组件被替换而不是更改。发生更改时，可以有效地重新预配应用程序或服务。【云的能力是不变的，应用随时可以更新】
（2）短暂（Ephemeral）：IT 资源无一例外无法更改。【应用无法改变IT资源】
（3）幂等（Idempotent）：任意重复一个动作而不会产生累加或有害影响的能力。【多次重复部署应用，结果是一样的】
与新应用程序不同，大部分企业应用程序组合（约占现有核心IT应用程序的85%）并未使用云原生架构的原则进行设计。例如传统大型机和中端应用程序、ERP 应用程序和基于 UNIX 的专有应用程序。这些应用程序通常是高度定制的，并且规模庞大，与大多数云平台不兼容。将旧版应用程序迁移到云的直接迁移方法不是一种有效的现代化策略。Gartner的 2020 年云最终用户购买行为调查中，受访者表示，到 2022 年，他们的组织不太可能采用直接迁移策略，而是将增加其他现代化方法的使用，包括更换和构建/购买新应用程序。在迁移工作中，I&O团队要考虑（1）应用规模（2）应用的定制化程度（3）云侧的迁移支持。
1、考虑应用程序的规模
小于 2TB 的应用程序占大多数 IT 产品组合的大部分。Gartner 客户查询表明，大约 95% 的云应用程序和 90% 的本地应用程序低于 2TB 阈值。除非应用程序超过2TB，否则I&O领导者应该计划虚拟化它并将其迁移到云或类似云的基础设施。这个就是传统P2V、V2V的天下，当然，云服务商也提供镜像导入到云的工具。一般可以通过热迁移提升SLA、通过异地双活或者容灾提高应用可用性。
随着 VMware 7.0 的发布，虚拟机大小不再严格限制为 30 个虚拟 CPU （vCPU）。因此，I&O领导者现在可以在云中运行大于2TB的应用程序。但是，VMware 7.0 的内存上限仍在测试中。虽然一些 5TB 到 6TB 的应用程序在虚拟机上运行，但并非所有云提供商都能在每个地区或每个垂直领域支持这些大型应用程序。红帽 KVM 的类似增强功能也增加了本地和云提供商的虚拟机容量。因此，I&O领导者在迁移大于2TB的应用程序之前，必须从基础架构/云提供商那里获得参考。在提供商证明他们能够在您所在的地区或垂直领域提供支持之前，不要移动这些中型应用程序。
大于 4TB 到 6TB 的应用程序会突破 VM 的内存限制（本地和云中）。对于这些应用程序，I&O领导者应评估裸机托管选项。由于这些产品使用专用的服务器硬件，因此它们不是弹性云，而是被视为类似云的基础架构。在许多情况下，I&O领导者可能仍然需要传统的高可用性（HA）解决方案。
2、考虑应用的定制化程度
标准化的路径取决于自定义级别。大多数旧版应用程序都有三种类型的自定义：（1）可以动态.添加或自定义屏幕和报告；（2）可以动态添加字段或索引/总计；（3）可以新增流程和自定义脚本。定制级别越高，I&O领导者将应用程序迁移到云并使其现代化就越困难和耗时。为啥会有这种问题呢？我考虑了一下，这主要是因为这种应用的定制化水平，对所用到的数据库、可视化、流程引擎提出了可定制的要求。一般来说，云平台上的此类组件是通用的，不好定制的。例如，由于定制化字段，可能就会依赖于某种特定的数据库，或者某种数据库的特定功能。
改造的目标是将轻度自定义的应用程序转换为具有以下功能的已配置应用程序：（1）在配置中编辑文本类型字段（2）隐藏字段或索引/总计；（3）使用标准流程和自定义脚本。这类系统更容易迁移上云。与自定义项少于 100 个的应用程序相比，高度自定义的应用程序过于复杂，无法转换为配置的云兼容格式。因此，I&O领导者将无法将这些应用程序迁移到云端，直到2025年的至少一个项目周期。相反，他们必须重新配置应用程序，以便在 IaaS 上进行裸机托管交付。
3、云侧提供迁移、转换的能力
这是对云服务商的能力要求，Gartner用了一个很好的比喻，针对应用迁移，云服务商一般提供了“Build”和“Run”的能力，但是一般没有提供Plan能力（参见下图）。当然我也看了一下国内的几个云平台，目前华为云已经提供了很清晰的迁移上云计划，还有专门的服务。百度智能云给出了方法论。均参见附录。因此Gartner给出的分析可能不是最新的。但是其方法论依然值得借鉴。
鉴于云服务商提供的能力不足，为了促进向云的顺利迁移之旅，I&O领导者需要四种技能来支持三种不同的迁移路径以及云操作：
（1）操作技能。能够以比本地基础结构更低的成本在云中运行标准化应用程序。云 IaaS 提供商擅长提供基础架构技能。提供商基于订阅的消费模型通常比基于项目的本地替代方案更便宜（至少在合同的前三年）–因为一般有折扣价。
（2）实施技能。能够将标准化应用程序直接迁移到云中。云提供商对已配置的应用程序具有此功能。但是，高度定制和复杂的应用程序在迁移到云时不一定更便宜（尤其是从长远来看）。
（3）过渡技能。能够将自定义应用程序从本地移动到 PaaS。如果没有与系统相关的专业技能，这些转换就不会发生。云提供商通常缺乏这些技能，并与系统集成商 （SI） 合作提供此功能。
（4）转型技能。能够将自定义应用程序从本地移动到新的打包应用程序或 SaaS。要完成此迁移，必须对应用程序进行标准化、现代化和配置，这需要任务关键型专业技能，这些技能非常宝贵，并且只能从 SI 和第三方获得
4、关于竖井式资源迁移到云服务
竖井式应用一般在资源、组网、基础设施方面都相互独立，资源的重用度很低，很容易造成资源的浪费，进一步提高了IT系统的建设成本，下图是个很形象的示意。Gartner假定（1）到 2022 年，至少有 40% 的紧密集成的传统核心本地应用程序将迁移到云，这比 2020 年的 20% 有所增加。（2）到 2024 年，20% 的核心 IT 和传统应用程序基础架构仍将不适合云计算，这一句看着令人伤心！这类竖井式应用迁移上云通常难度最大。当然效益也最大，很类似“让2个人干5个人的活，发3-4个人的工资”的提法，机器和人一样，都是资源！
I&O领导们需要在以下7种业务系统交付方案中选择部署方案，分别是本地部署（自建云）、主机托管（云托管）、应用托管（托管云）、云I+P托管（公有云）、云SaaS（SaaS）、边缘（边缘云）和IOT（物联网），Gartner这个分类虽然确实存在一些重叠之处，例如Edge和云I+P托管、Hosting都有很强的相似性，但是逻辑是清楚的[19]。一旦选择了某几种交付模型，那么在添加新业务的时候，有三个选择方法：（1）整合 – 在基础架构模式中共享虚拟机 （VM） 和操作系统（重用）。（2）合理化 — 跨模式利用通用管理和软件堆栈（纳管）。（3）标准化 – 将商用软件 （COTS） 基础架构用于新的或异常工作负载（标准化软件）。后面的迁移主要针对迁移到公有云。
附录1：天翼云TeleDB
TeleDB 是天翼云在数据库领域丰富实践经验和先进技术架构的有机结合，由天翼云自主研发，具有兼容社区生态、全面国产化适配等核心能力。目前 TeleDB 已研发核心 PaaS 技术 20 余项，获得核心专利技术 16 项，承载 7 亿 + 用户，稳定性得到全面验证。
IT之家获悉，官方介绍，TeleDB 数据库采用容器化技术和分布式块存储技术，通过云原生技术改造业务，使得数据库服务器的 CPU、内存能够快速扩容，通过动态增减节点提升性能和节省成本，存储空间无需手动配置，实现自动弹性伸缩。
面对多元化的业务需求，企业需要服务提供商能够提供横向主流数据库产品和纵向多版本技术服务的全覆盖能力，为此，天翼云还构建了 TeleDB 数据库上云全生态。
在数据库内核方面，TeleDB 采用云原生架构，高度兼容 MySQL、PostgreSQL、openGauss、TiDB，寻求社区深度合作，在强化自身能力的同时反哺社区，提升代码自主可控能力及数据库团队的社区影响力。
- TeleDB 是一款兼容开源 MySQL 协议的企业级智能化关系型数据库引擎，适用于在线事务处理，可为用户提供稳定可靠的企业级数据库服务；
- TeleDB 兼容开源 PostgreSQL 协议，支持 SQL 规范的完整实现、丰富多样的数据库类型，并高度兼容 Oracle 语法，集成了一系列管理功能，减轻运维压力；
- TeleDB 支持在线事务处理（TP）和在线分析处理（AP），是一款高性能 HTAP 融合型 NewSQL 数据库引擎，适用于数据规模大、高可用、高吞吐等业务场景。
在建设层面，TeleDB 聚焦掌握数据备份、数据迁移、数据库自动驾驶仓、数据库安全网关等核心生态产品。支持 HBase、文档数据库、时序数据库等 NoSQL 数据库协议，提供实时分析云服务，适合 PB 级，千万级 QPS 的分布式计算应用场景，是风控、推荐、广告、物联网、车联网、Feeds 流、数据大屏等场景的首选数据库。
此外，TeleDB 借助外部生态体系夯实完善交付、实施、运营、维护等过程，可以实现端到端软硬件深度的整合和优化，提升数据存储效率和访问效率，进一步发挥网络和新介质能力，构建一站式强体验生态体系。
TeleDB 数据库作为中国电信天翼云自主研发的产品，实现数据库基础软件全面自主可控。基于 TeleDB 数据库，解决核心基础软件卡脖子问题，为用户提供更安全、更可靠、更智能的云数据库产品和服务。
附录2：中国电信上云L3标准
附录3：基于TeleDB和MySQL数据库的分布式数据集成系统及方法与流程
本发明涉及分布式数据处理技术领域，尤其涉及基于teledb和mysql数据库的分布式数据集成系统及方法。
背景技术：
目前同类的技术或者产品在底层的数据库日志解析上技术上共通外，当涉及到业务方面，就不太适用于复杂的电信业务的分布式业务，数据库集群多，数据量大，稳定性和实时性要求高，需适配电信集团自研组件，同时也存在监控运维等生产问题，这个在同类的技术或者产品上都不具备。
技术实现要素：
本发明的目的在于提供基于teledb和mysql数据库的分布式数据集成系统及方法，用于解决teledb和mysql的分布式数据库集群，在多个应用中心间的复杂的数据交互和分享的问题。
本发明采用的技术方案是：
基于teledb和mysql数据库的分布式数据集成系统，系统包括设于管理平台上的数据同步服务模块、数据修复模块、数据稽核模块、数据迁移模块和监控告警服务模块，数据同步服务模块负责实施的增量数据复制；数据修复模块负责同步过程异常数据的修复和稽核数据的修复；数据稽核模块负责检查并保证数据的一致性；数据迁移模块用于数据初始化和全量数据迁移以保证一致性；监控告警服务模块负责监控系统的运行告警。
基于teledb和mysql数据库的分布式数据集成系统的控制方法，其包括以下步骤：
步骤1，管理平台查询应用数据库的数据，并配置同步任务数据；
步骤2，管理平台下发同步任务数据至数据同步服务模块，并发起数据同步请求；
步骤3，数据同步服务模块解析同步任务数据开始执行数据实时同步；
步骤4，判断同步任务执行是否发生异常；是则，记录异常数据，当触发熔断条件时下发任务熔断指令并执行步骤5；否则，执行步骤6；
步骤5，监控告警服务模块监控到同步异常数据，根据告警策略发出同步异常告警；
步骤6，通过数据稽核模块进行稽核数据判断同步数据是否发现数据差异；是则，向数据修复模块发起数据修复并执行步骤7；否则，执行步骤8
步骤7，数据修复模块收到修复任务后执行数据修复任务，完成数据修复后执行步骤6；
步骤8，结束完成数据集成应用。
进一步地，作为一种较优实施方式，步骤1中管理平台通过主从切换变更对应的监控数据库。
进一步地，作为一种较优实施方式，步骤1中管理平台监控发现同步数据异常时，则通知监控告警服务模块发出异常告警。
进一步地，作为一种较优实施方式，步骤5中通过短信通知服务发出短信告警。
本发明采用以上技术方案，通过binlog应用,整合数据仓库etl思路，将分散、零乱、标准不统一的数据整合到一起进行集中管理和使用，具有资源集中管理，规范流程，统一操作，完善的监控体系，减少在这方面的人力投入和资源的投入，具有很好的经济效应，并且支撑集成电信应用的特性，集成了中国电信集群研发组件等现有技术不具备的特性，能够很好支撑电信应用系统。高可靠，高性能特性满足了大批量亿级别数据的应用，除了能支撑除了电信应用外的系统支撑，涵盖和超越了现有技术的应用，是现有技术不具备有的能力。
附图说明
以下结合附图和具体实施方式对本发明做进一步详细说明；
图1为本发明基于teledb和mysql数据库的分布式数据集成系统原理架构示意图；
图2为本发明基于teledb和mysql数据库的分布式数据集成系统的控制方法的流程示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图对本申请实施例中的技术方案进行清楚、完整地描述。
本发明基于mysql的主从复制原理，从mysql中源源不断的抽取操作的数据，向外围系统传送数据，支持多种数据源加载，包括mysql,oracle,db2,postgresql，可以方便的集成主流的数据源。为了减少对生产库的数据复制压力，引入了消息中间件，使用电信集团的ctgmq作为数据流管道进行数据分发。能够保障电信系统的出账等的大数据量处理场景，高可靠，高可用，稳定运行，提供了监控告警服务，提前发现问题和解决问题。
如图1或图2所示，本发明公开了基于teledb和mysql数据库的分布式数据集成系统，系统包括设于管理平台上的数据同步服务模块、数据修复模块、数据稽核模块、数据迁移模块和监控告警服务模块，数据同步服务模块负责实施的增量数据复制；数据修复模块负责同步过程异常数据的修复和稽核数据的修复；数据稽核模块负责检查并保证数据的一致性；数据迁移模块用于数据初始化和全量数据迁移以保证一致性；监控告警服务模块负责监控系统的运行告警。为数据的应用提供实时，可靠的数据应用保证。
如图2所示，本发明还公开了基于teledb和mysql数据库的分布式数据集成系统的控制方法，其包括以下步骤：
步骤1，管理平台查询监控数据库的数据，并配置同步任务数据；
步骤2，管理平台下发同步任务数据至数据同步服务模块，并发起数据同步请求；
步骤3，数据同步服务模块解析同步任务数据开始执行数据实时同步；
步骤4，判断同步任务执行是否发生异常；是则，记录异常数据，触发熔断条件时下发任务熔断指令并执行步骤5；否则，执行步骤6；
步骤5，监控告警服务模块监控到同步异常数据，根据告警策略发出同步异常告警；
步骤6，通过数据稽核模块进行稽核数据判断同步数据是否发现数据差异；是则，向数据修复模块发起数据修复并执行步骤7；否则，执行步骤8
步骤7，数据修复模块收到修复任务后执行数据修复任务，完成数据修复后执行步骤6；
步骤8，结束完成数据集成应用。
进一步地，作为一种较优实施方式，步骤1中管理平台通过主从切换变更对应的teledb和mysql数据库。
进一步地，作为一种较优实施方式，步骤1中管理平台发现同步数据异常时，则通知监控告警服务模块发出异常告警。
进一步地，作为一种较优实施方式，步骤5中短信通知服务发出短信告警。
本发明采用以上技术方案，通过binlog应用,整合数据仓库etl思路，将分散、零乱、标准不统一的数据整合到一起进行集中管理和使用，具有资源集中管理，规范流程，统一操作，完善的监控体系，减少在这方面的人力投入和资源的投入，具有很好的经济效应，并且支撑集成电信应用的特性，集成了中国电信集群研发组件等现有技术不具备的特性，能够很好支撑电信应用系统。高可靠，高性能特性满足了大批量,亿级别数据的应用，除了能支撑除了电信应用外的系统支撑，同时也涵盖和超越了现有技术的应用,是现有技术不具备有的能力。
显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
技术特征：
1.基于teledb和mysql数据库的分布式数据集成系统，其特征在于：包括设于管理平台上的数据同步服务模块、数据修复模块、数据稽核模块、数据迁移模块和监控告警服务模块，数据同步服务模块负责实施的增量数据复制；数据修复模块负责通同步过程异常数据的修复和稽核数据的修复；数据稽核模块负责检查并保证数据的一致性；数据迁移模块用于数据初始化和全量数据迁移以保证一致性；监控告警服务模块负责监控系统的运行告警。
2.基于teledb和mysql数据库的分布式数据集成系统的控制方法，采用了权利要求1所述的基于teledb和mysql数据库的分布式数据集成系统；其特征在于：方法包括以下步骤：
步骤1，管理平台查询应用数据库的数据，并配置同步任务数据；
步骤2，管理平台下发同步任务数据至数据同步服务模块，并发起数据同步请求；
步骤3，数据同步服务模块解析同步任务数据开始执行数据实时同步；
步骤4，判断同步任务执行是否发生异常；是则，记录异常数据，在触发熔断条件时下发任务熔断指令并执行步骤5；否则，执行步骤6；
步骤5，监控告警服务模块监控到同步异常数据根据告警策略发出告警；
步骤6，通过数据稽核模块进行稽核数据判断同步数据是否发现数据差异；是则，向数据修复模块发起数据修复并执行步骤7；否则，执行步骤8；
步骤7，数据修复模块收到修复任务后执行数据修复任务，完成数据修复后执行步骤6；
步骤8，结束完成数据集成应用。
3.根据权利要求2所述的基于teledb和mysql数据库的分布式数据集成系统的控制方法，其特征在于：步骤1中管理平台通过主从切换变更对应的应用数据库。
4.根据权利要求2所述的基于teledb和mysql数据库的分布式数据集成系统的控制方法，其特征在于：步骤1中管理平台监控发现同步数据异常时，则通知监控告警服务模块发出异常告警。
5.根据权利要求2所述的基于teledb和mysql数据库的分布式数据集成系统的控制方法，其特征在于：步骤5中通过短信通知服务发出短信告警。
技术总结
本发明公开基于TeleDB和MySQL数据库的分布式数据集成系统及方法，系统包括设于管理平台上的数据同步服务模块、数据修复模块、数据稽核模块、数据迁移模块和监控告警服务模块，数据同步服务模块负责实施的增量数据复制；数据修复模块负责同步过程异常数据的修复和稽核数据的修复；数据稽核模块负责检查并保证数据的一致性；数据迁移模块用于数据初始化和全量数据迁移以保证一致性；监控告警服务模块负责监控系统的运行告警。本发明将分散、零乱、标准不统一的数据整合到一起进行集中管理和使用，具有资源集中管理，规范流程，统一操作，完善的监控体系，减少在这方面的人力投入和资源的投入，具体很好的经济效应。
技术研发人员：陈知;吴宇星;林志强;郑志浩;吴智元;叶海强;郑国伟
受保护的技术使用者：中电福富信息科技有限公司
技术研发日：2021.05.31
技术公布日：2021.08.24