是时候获得更多的创新，即使与大型机！这个博客文章涵盖了我在项目中看到的步骤，其中企业开始将数据从大型机卸载到Apache Kafka，最终目标是取代旧遗留系统。
大型机仍在努力工作，每天处理全球 70% 以上的最重要的计算事务。银行、信用卡公司、医疗设施、股票经纪公司等绝对不能承受停机时间和错误的组织，要靠大型机来完成工作。近四分之三的财富500强企业仍然转向大型机，以完成关键处理工作“（BMC）。
成本、整体架构和缺乏专家是大型机应用面临的主要挑战。大型机用于多个行业，但我想从考虑德国银行的现状开始这一职位;了解为什么这么多企业请求大型机卸载和更换帮助的动机…
2020年德国金融业
德国是我住在的地方，所以我从当地报纸得到的新闻最多。但世界上其他国家的情况非常相似…
以下是德国目前的情况：
- 传统银行陷入困境。越来越多的分支机构每年都关闭。
- 财务数字相当糟糕。市值显著下跌（在科罗纳之前！德意志银行（DeutscheBank）和德国商业银行（Commerzbank）——德国金融业的前旗舰——每周都出现在新闻中。通常是坏消息。
- 德国商业银行不得不在2019年离开DAX（由法兰克福证券交易所交易的30家德国大公司组成的蓝筹股指数）;由Wirecard取代，一个现代化的全球互联网技术和金融服务提供商，为客户提供电子支付交易服务和风险管理。
- 传统银行谈论了很多关于创建”前沿”区块链联盟和分布式账本，以改善其未来流程和”创新”。例如，一些银行计划使用联合分发的分类账改进”了解您的客户”（KYC）流程，以降低成本。不幸的是，这离实施还有好几年了;不清楚这是否有意义，并增加了真正的商业价值。区块链在大多数情况下仍未证明其附加价值
根据我个人的经验，国际银行交易通常不到24小时。相反，我的德国私人银行的移动应用程序和网站是一个真正的痛苦。感觉好像越来越糟，而不是更好。公平地说，如果出现问题（如欺诈-他们有时只是冻结您的帐户，并且没有提供良好的支持），Neobanks 不会提供客户服务。
传统银行应该关注。当然，其他行业也是如此。然而，如上所述，许多企业在与创新竞争对手竞争的同时，仍然严重依赖50多年的大型机。感觉这些依靠大型机的公司比航空公司或零售行业更难改变。
带（出）大型机进行数字化转型
几个月前我和一家保险公司有个会议。团队向我出示了一份内部文件，引用他们的首席执行官：”这一定是与 IBM 签订的最后 20M 大型机合同！五年后，我预计不会续约。这就是我所说的 IT 团队的”明确期望和目标”…
为什么每个人都想摆脱大型机？
许多大型、成熟的公司，尤其是金融服务和保险领域的公司，仍然依赖大型机来提供最关键的应用和数据。除了可靠性外，大型机还具有高昂的运营成本，因为它们传统上由 MIPS 收取（每秒数百万条指令）。减少 MIPS 可降低运营成本，有时显著降低运营费用。
其中许多公司目前正在进行架构现代化，包括云迁移、从单一应用程序转向微服务以及采用开放系统。
现代化与大型机与现代技术
这种现代化不容易拥抱大型机，但能够访问这些数据将受益匪浅。Kafka 可用于使更现代化的数据存储与大型机实时同步，同时将事件数据保留在总线上以启用微服务，并将数据传递到其他系统（如数据仓库和搜索索引）。
这不仅将减少运营成本，而且将为架构现代化和敏捷性提供一条仅靠大型机无法获取的路径。
作为大多数企业的最后一步和最终愿景，大型机可能被使用现代技术的新应用程序所取代kai-waehner.de/blog/2020/04/15/apache-kafka-machine-learning-banking-finance-industry/”rel=”nofollow”目标=”_blank”=使用 Kafka 和机器学习进行大规模实时评分，可以改进支付应用程序。以下是银行和保险公司利用 Apache Kafka 及其生态系统进行创新、灵活性和降低成本的一些具体示例：
- 资本一：成为真正的事件驱动 – 提供银行其他部门可以使用的服务。
- ING： 显著改善客户体验 – 作为差异化和欺诈检测并节省成本。
- 免费你：实时风险和索赔管理在他们的汽车保险应用程序。
- Generali：通过基于事件流的现代集成架构连接传统数据库和现代世界。
- Nordea： 能够满足实时报告和成本节约的严格监管要求。
- Paypal： 每天处理 4000+ 十亿个事件，用于用户行为跟踪、商家监控、风险和合规性、欺诈检测和其他用例。
- 加拿大皇家银行（RBC）：大型机卸载，更好的用户体验和欺诈检测 – 带来了银行的许多部分在一起。
最后一个例子让我回到这个博客文章的主题：公司可以节省数百万美元”只是”通过卸载数据从他们的主机到卡夫卡进一步消费和处理。大型机更换可能是长期目标;但只是卸载数据是一个巨大的$$赢。
集成层的域驱动设计 （DDD）
那么，为什么要使用卡夫卡进行大型机卸载和更换呢？市场上有数百种中间件工具可用于大型机集成和迁移。
嗯，除了开放和可扩展（我不会涵盖卡夫卡的所有特征在这篇文章）。一个关键特征是Kafka 比任何其他消息传递或集成中间件更好地实现分离应用程序大型机无法在单个项目中替换。一声巨响就会失败。这必须是长期规划的。实现是一步一步的。
与此同时，这个星球上几乎每家公司都有云战略。云具有许多优点，如可扩展性、弹性性、创新性等。当然，也有权衡：云并不总是便宜。需要学习新的概念。安全性非常不同（我不是说更糟或更好，只是不同）。对于大多数企业来说，混合动力是常态。只有 10 岁以下的企业才是云的。
因此，我使用术语”云”如下。但是，如果您”只是”想要远离大型机，而是留在自己的本地数据中心，则也会存在相同的阶段。
在非常高的级别上，大型机迁移可以包含三个阶段：
- 第 1 阶段 – 云采用：将数据复制到云以进行进一步的分析和处理。大型机卸载是其中的一部分。
- 第 2 阶段 – 混合云：在云和数据中心应用程序（包括大型机应用程序）之间实时进行数据的双向复制。
- 第 3 阶段云 – 第一个开发：所有新应用程序都内置于云中。即使是核心银行系统（或至少部分）在云中（或数据中心的现代基础设施中）运行。
我们怎么去那里？正如我所说，一声巨响会失败。让我们来看看我在不同客户身上看到的一种非常常见的方法…
状态 Quo：大型机限制和 $$$
现状如下：应用程序正在使用来自大型机的数据，从而产生昂贵的 MIPS：
大型机正在运行，并部署了核心业务逻辑。它工作良好（24/7，任务关键）。但是，进行更改或添加新功能确实很困难，甚至是不可能的。可扩展性通常已经成为一个问题。好吧，我们不要谈论成本。大型机花费数百万美元。
大型机卸载
大型机卸载意味着数据被复制到Kafka，供其他应用程序进一步分析和处理。数据继续通过现有的旧应用程序写入大型机：
卸载数据是容易的部分，因为您不必更改大型机上的代码。因此，第一个项目通常只是读取数据。
写入大型机要困难得多，因为必须理解大型机上的业务逻辑才能进行更改。因此，许多项目通过保持写入保持…，避免了这种巨大的（有时无法解决）的挑战。当然，这并不理想。不能向现有应用程序添加新功能或更改。
人们不能或不想冒险去改变它。没有DevOps或CI/CD管道，也没有A/B测试基础设施背后的主机，亲爱的大学毕业生！:-)
大型机更换
每个人都想更换大型机，因为他们的技术限制和成本。但是，由于所有任务关键型业务应用程序，企业不能简单地关闭大型机。
因此，作为大型机的主要编程语言COBOL，在大型批处理和事务处理作业的应用中仍然广泛使用。阅读博客文章”刷你的COBOL：为什么一个60岁的语言突然的需求？“为一个不错的2020年介绍COBOL。
企业有以下选项：
- 继续积极发展大型机。培训或雇佣更多（昂贵的）COBOL 开发人员来扩展和维护您的旧应用程序。嗯，这是你想离开的地方。如果您忘记了原因：成本、成本、成本。和技术限制。我发现大型机竟然支持”现代技术”，如Web服务，这令人惊奇。大型机不会静止。话虽如此，即使你使用更现代的技术和标准，你仍然运行在大型机上，其所有的缺点。
- 使用迁移和代码生成工具将 COBOL 代码替换为现代应用程序。各种供应商提供工具，获取 COBOL 代码，然后以现代编程语言（通常是 Java）自动将其迁移到生成的源代码。可以重构和更改新的源代码（因为 Java 使用静态类型，以便在 IDE 中显示任何错误，并且更改可以应用于代码结构中的所有相关依赖项）。
这就是理论。COBOL 代码越复杂，迁移越难，迁移所需的自定义编码就越多（这会导致 COBOL 开发人员在主机上遇到同样的问题）。如果您不了解代码例程，则无法更改代码例程，而不会在新版本的应用程序中出现错误、数据丢失或停机的风险。
- 使用现代技术开发面向未来的新应用程序，提供开放、灵活且可扩展的体系结构
根据需要保持旧旧主机运行。迁移不是大爆炸。逐步更换用例和功能。不管怎样，新应用程序将有不同的功能要求。因此，看看金融科技和英达科技公司。启动绿地项目有很多优点。最大的缺点是开发和迁移成本高。
在现实中，这三种选择的组合也可能发生。无论什么对你有效，让我们现在想想阿帕奇卡夫卡如何融入这个故事。
集成层的域驱动设计
卡夫卡不仅仅是一个消息系统。它是一个事件流平台，提供存储资本支出。与 MQ 系统或基于 Web 服务/API 的体系结构相反，Kafka 确实将生产者和消费者分离：
借助 Kafka 及其域驱动设计，每个应用程序/服务/微服务/数据库/”您名称-it”都是完全独立且松散耦合的。但可扩展、高度可用且可靠！博客文章“Apache Kafka，微服务和域驱动设计（DDD）”深入于这个话题。
Sberbank是俄罗斯最大的银行，是其域名驱动方法的一个很好的例子：Sberbank在阿帕奇卡夫卡生态系统之上建立了新的核心银行系统。此基础架构是开放和可扩展的，但也可用于关键任务支付用例，如即时付款或欺诈检测，但也可用于创新应用程序，如客户服务中的聊天机器人或针对交易市场的 Robo 建议。
为什么这种脱钩如此重要？因为大型机集成、迁移和更换是一个（漫长的）旅程…
事件流平台和传统中间件
事件流平台赋予应用程序独立性。无论应用程序是否使用新的现代技术或传统、专有的单片组件。Apache Kafka 提供自由挖掘和管理共享数据，无论接口是实时消息传送、同步 REST/SOAP Web 服务、基于文件的系统、SQL 或 NoSQL 数据库、数据仓库、数据湖或其他任何内容：
阿帕奇卡夫卡作为集成中间件
Apache Kafka 生态系统是一个高度可扩展、可靠的基础设施，可实现实时高吞吐量。Kafka Connect 提供与任何现代或旧系统（无论是大型机、IBM MQ、Oracle 数据库、CSV 文件、Hadoop、Spark、Flink、TensorFlow）等任何系统的集成。
卡夫卡安全与数据治理生态系统
阿帕奇卡夫卡生态系统提供了额外的功能。这一点很重要，因为 Kafka 不仅用作消息传递或引入层，还用于大多数任务关键型用例的平台。记住我在本文开头展示的银行业和保险业的例子。这些只是世界各地更多任务关键型 Kafka 部署中的一部分。查看过去的卡夫卡峰会视频录音和幻灯片，了解更多的任务关键型用例和架构。
我不会在这个博客文章的细节，但Apache Kafka生态系统提供安全和数据治理的功能，如架构注册表（+架构演变），基于角色的访问控制（RBAC），加密（在消息或现场级别），审计日志，数据流分析工具等…
未来 5 年大型机卸载和更换
考虑到所有的理论，现在让我们来看看一个实际的例子。以下是许多企业走过的一段旅程。一些企业刚刚开始这个旅程，而其他企业已经通过卸载甚至更换大型机节省了数百万美元。
我将引导您完成一个现实的方法，在本示例中需要 +5 年（但根据部署和组织的复杂性，这很容易需要 10 年以上）。重要的是快速获胜和成功的循其以继日的方法;不管需要多长时间
第 0 年：应用程序与大型机之间的直接通信
让我们开始吧。这里再次是当前的情况：应用程序直接与大型机通信。
让我们减少大型机和其他应用程序之间的成本和依赖关系。
第 1 年：用于大型机和应用程序之间的分离的卡夫卡
从大型机卸载数据使现有应用程序能够使用 Kafka 的数据，而不是为直接主机访问创建高负载和成本：
这节省了大量 MIPS（每秒数百万个指令）。MIPS 是测量大型机计算成本的一种方式。减少 MIPS，降低成本。
从大型机卸载数据后，新应用程序还可以使用 Kafka 的主机数据。无需额外的 MIPS 成本！这允许在大型机数据上构建新应用程序。开发人员无法构建新的创新应用程序的时间已经一去不复返了，因为 MIPS 成本是访问大型机数据的主要阻止程序。
Kafka 可以存储数据，只要需要存储。对于一个卡夫卡主题进行日志分析，这可能需要 60 分钟，而另一个 Kafka 主题的客户交互可能只有 10 年时间。借助 Kafka 分层存储，您甚至可以通过将处理与 AWS S3 等后端存储分离处理，从而降低成本并增加弹性。此讨论已不讨论本文的范围。请查看”阿帕奇卡夫卡是一个数据库吗？
更改大型机卸载到卡夫卡的数据捕获 （CDC）
大型机卸载的最常见选项是更改数据捕获 （CDC）：基于事务日志的 CDC 将数据更改（插入、更新、删除）从主机推送到 Kafka。优点：
- 实时推送到卡夫卡的更新。
- 消除破坏性满负荷，即将生产影响降至最低。
- 减少 MIPS 消耗。
- 与任何大型机技术（DB2 Z/OS、VSAM、IMS/DB、CISC 等）集成
- 全力支持。
在第一个连接中，CDC 工具读取所有白名单的表的一致快照。当该快照完成后，连接器会持续流式传输在捕获模式下为所有白名单表提交到 DB2 数据库的更改。这将生成相应的插入、更新和删除事件。每个表的所有事件都记录在单独的 Kafka 主题中，应用程序和服务可以轻松地使用它们。
CDC 最大的缺点是许可成本高。因此，存在其他集成选项…
卡夫卡和大机的集成选项
虽然 CDC 是首选，但还有更多的替代方案。以下是我在大型机卸载领域讨论的集成选项：
- IBM 信息圈数据复制 （IIDR） CDC 大型机解决方案。
- 第三方商业 CDC 解决方案（例如，Atunity 或 HLR）。
- 开源 CDC 解决方案（例如Debezium – 但您仍然需要 IIDC 许可证，这与 Oracle 和金门 CDC 面临的挑战相同）
评估权衡并做出决策。需要完全支持的解决方案通常会快速消除多个选项：-）根据我的经验，大多数人使用CDC，其次是IBMMQ。在大多数情况下，其他选项更具有理论性。
第 2 至 4 年：新项目和应用程序
现在，是时候构建新的应用程序了：
这可以是使用任何技术的敏捷、轻量级的微服务。或者，这可以是外部解决方案，如数据湖或云服务。选择您需要的内容。你可以灵活。基础设施的核心允许这样做。它是开放、灵活和可扩展的。欢迎来到一个新的现代IT世界！:-)
第 5 年：大型机更换
在某个时候，您可能会想：旧的大型机应用程序呢？我们最终能替换他们吗？至少有些？当基于现代技术的新应用程序准备就绪时，切换：
由于这是一个循步的方法，因此风险是有限的。首先，大型机可以继续运行。如果新应用程序不起作用，请切换回大型机（它仍然是最新的，因为您没有停止与新应用程序并行地将更新插入到其数据库中）。
一旦新应用程序经过战斗测试和验证，大型机应用程序就可以关闭。为下一次大型机更新编入预算的美元可用于其他创新项目。祝贺！
大型机卸载和更换是一个旅程…卡夫卡可以帮忙！
以下是我们大型机卸载和更换故事的全局图景：
请记住我前面讨论的三个阶段：阶段 1 – 云采用，第 2 阶段 – 混合云，第 3 阶段 – 云优先开发。我没有在这个博客文章详细解决这个问题。话虽如此，卡夫卡是这次旅行的理想人选。因此，这是混合和多云策略中卸载和替换大型机的完美组合kai-waehner.de/blog/2020/01/29/deployment-patterns-distributed-hybrid-edge-global-multi-data-center-kafka-architecture/
您在大型机卸载和更换方面的经验是什么？你打算使用阿帕奇卡夫卡及其生态系统吗？你的策略是什么？让我们在LinkedIn上联系并讨论！