写点什么

当架构进入“超高可用”时代,信创环境下的应用可持续运行得到保证

  • 2023-01-09
    北京
  • 本文字数:3765 字

    阅读完需:约 12 分钟

当架构进入“超高可用”时代,信创环境下的应用可持续运行得到保证

2023 年,一个全球化部署的业务还需要停服更新?

2023 年,打开一个应用的加载时间还需要以分钟计?

2023 年,一个系统的访问延迟还停留在分钟级时代?

 

数字化时代,我们的信息水平在显著提升,但上述三种情况并没有完全消失。如今,仍然有大量的应用在持续性层面存在问题,现阶段只有 1%(数据来源:艾瑞咨询研究院发布的《数字时代应用可持续性和验证白皮书》)的用户认为数字化体验达到了自己最初或者最好的预期,而这种应用不可持续性问题最直接影响的就是企业收入,Facebook 在 2021 年 10 月初宕机三小时导致市值蒸发数十亿美金。

 

既然技术如此重要,那么砸钱、砸人是不是就能解决了?

 

且不论很多企业没有办法像互联网大厂、四大行、三大运营商那样投入大量资源达成目标。即便可以,应用本身的流量是不稳定的;技术栈也在逐年变化;新的诉求不断产生,比如实现对系统全链路的可观测;信创对系统全部迁移完成的时间做出了明确规定,企业无法按照原计划逐步替代旧有系统......每一项变数都将企业陷入多难境地。

 

既然现有方案无法解决问题,我们就需要反向思考:满足数字化及信创要求的、满足应用可持续性要求的、满足不断变化的业务要求的架构应该长什么样子?

探索架构新模式:双轨超高可用架构设计

 

当下,维持应用可持续性的架构主要分为两大流派:一是 F5 过去多年在金融领域主要推广的双活数据中心架构,这种分布式的体系可以保证单节点出现故障不影响整个应用运行;二是以云厂商为主的“Design for Failure”模式。前者在五年前是非常先进的架构模式,但现在已经无法满足企业“多云多活”的现状;后者对企业而言的实现门槛颇高,不投入一定的资源是很难建成企业级解决方案的。

 

基于此,神州云科试图以全新的架构来解决应用可持续的问题,这种新的模式就是双轨超高可用架构设计。


神州云科副总裁,通明湖云和信创研究院副院长吴静涛表示,“在提出双轨超高可用架构之前,神州云科一直专注和实现应用领域的高可用,通过产品和解决方案帮助用户实现从小机到 X86 服务器的过渡,从大机时代到 X86 服务器时代的更迭,再从 X86 服务器时代到虚拟化、云时代的更迭。应用平滑迁移,应用高可用,全局智能调度,应用安全和应用优化一直是神州云科专注和擅长。在应用交付走向国产化信创的时代,神州云科考察和调研了用户在信创建设过程中所面临的痛点和挑战。基于此,提出了双轨超高可用架构的解决方案。”

 

双轨超高可用架构解决方案的设计理念是两个分和四个原则。第一个“分”指的是分阶段建设思想,即用户在信创建设过程中采用分段的建设思路。在第一阶段,用户先实现信创业务和非信创业务的双轨运行模式;第二阶段,用户可以分批次逐渐扩大信创建设的业务范围;第三阶段实现全栈信创。第二个“分”指的是分区、分域、分中心的思想,基于此思想对信创建设进行统筹规划,分阶段故障隔离以稳步推进信创建设。四大原则则分别是:超高可靠原则,高效推进原则,业务创新原则,安全防范原则。这四大原则基本满足了用户在信创建设中所要达成的目标。

 

从架构层面,双轨超高可用架构可以看作是高可用架构的另一种表现形式,这里的“双轨”主要指的是在跨中心和跨区之间增加了域的逻辑层,实现了跨中心、跨域和跨区的协同。比如信创域和非信创域之间的调度,在域里边还有互联网区、核心业务区、一般业务区之间的调度。

   

举例来说,一个业务在同一个数据中心里面无法同时运转在信创域和非信创域,一旦信创过程出现什么问题,系统无法回退将会给企业带来巨大的损失。双轨超高可用架构就可以很好地解决这个问题。

 

那么,这种信创域与非信创域之间的协同调度具体是如何设计出来的呢?

双轨超高可用架构设计思路


首先,信创域与非信创域在能力编排、服务构建等层面是一样,既包含传统互联网业务,也包含云原生业务,二者之间的协同调度则通过五大引擎来实现。

一是高可用调度引擎,其主动与信创域进行协同和调度。一旦信创域出现任何稳定性问题,该引擎负责立刻将流量切回到传统的非信创域系统。如果运转良好,则可以将非信创域的业务负载逐渐向信创域灰度交接。其具备如下三大特点:一是实现对信创业务的充分验证,企业可以复制真实的业务报文到信创区域进行充分验证,消除未知隐患;二是支持动态调整信创业务比例,企业可以精准识别业务类别,动态调整比例分配,从而保障信创业务的真实可用;三是实现信创业务的应急逃生,通过高可用调度引擎及时发现未知风险,实现业务的秒级切换,这样的好处是可以原封不动地保留信创业务的故障现场,方便分析以排除隐患,为下一次的成功上线做准备。

 

二是安全服务编排引擎。当部分业务需要防火墙等做应用和网络攻防,或者需要 3A 认证和 SSL 加解密,该引擎可以根据应用特征做安全流量编排。该引擎的特点是可以实现降本增效,对于安全设备的池化部署可以弹性扩展,并提高攻防对抗能力,提高可用性;池化之后还可以支持异构部署,池内的安全设备是异构状态,实现了信创业务的架构创新,提高整体信创业务的攻防对抗能力;支持灰度发布,实现安全服务动态编排,安全策略灰度发布,从而有效避免因此出现业务拦截。


三是信创高可用引擎。信创环境中的服务器、存储、操作系统、中间件等的良好运装均可通过云科通明湖系列技术能力得到保证。云科通明湖的解决方案可以为信创环境应用的可持续性提供负载均衡与应用交付服务。


四是现代应用高可用引擎。在云原生架构转型过程,神州云科可以提供以云科通明湖的以 NGINX 技术为实现原理的现代应用高可用引擎,类似互联网公司的四层用 ELB 技术,七层用 ALB 技术架构。

 

五是大数据引擎。神州云科在 2019 年基于探针技术研发了大数据引擎,进而实现了可观测性。大数据引擎可以率先发现问题根因,通过控制业务切换节奏来保证现网业务的绝对稳定和可靠。该引擎的特点是实时无侵,可以实现 T+0 的数据收集,包括对双轨运行状态的全景监控;基于这样的监控实现全程可视,实现网络质量、用户体验、用户行为分析等全路径的监控;支持快速排障,通过大数据引擎实现对于业务统一路径的监控,快速定位问题,发现问题并排除故障。

 

吴静涛强调,“五大引擎是双轨建设的核心灵魂。双轨超高可用架构的技术优势是实现了对于信创的高可用引擎和高可用调度引擎的智能协议级互联互通。高可用引擎可以通过信创引擎快速感知到信创业务的状态,从信创引擎里汲取必须要判断的信息,可以作为对一个业务质量的综合判断。体现的动作就是可以动态调整信创业务的分配比例,这是一个自动化的过程。甚至在一些极端情况下,还可以实现对于信创业务的应急逃生。”

 

基于这五大引擎,双轨超高可用架构可以极大帮助客户在信创过程中规避稳定性、可靠性或者用户体验层面的风险,确保主营业务或者核心业务平稳地进入信创区域。

 

从海外厂商提供的技术转向国产化信创技术,从主要依靠硬件的高性能转变为虚拟化甚至是云原生服务,从讨论端口、吞吐以及其他指标到现在讨论如何通过架构的形式实现可持续、可观测的服务,设备本身的性能和功能不是那么重要,架构是第一位的。神州云科认为最核心的是整个切换过程在保证可持续的过程中真正实现架构统一,统一纳管和服务才能保证企业以最低的风险完成迁移,而全过程的用户体验是没有任何区别的。

如何在信创环境中落地?


如果企业希望在内部落地双轨超高可用架构,大概可以为分为三步:一是进行充分验证之后实现信创双轨建设,重要业务、核心业务逐渐往信创切;二是不宕机的情况下进行灰度迁移;三是全部流量切换至全新的信创环境中。在该架构的帮助下,过去五年甚至十年的工作可以在两到三年时间全部完成。

 

以某银行的实际经验为例,起初该银行采用的是相对激进的新老系统替换的方式,最终由于对信创业务不熟悉导致业务稳定性很差,经常性出现业务故障,甚至遭到了行内多个领导的投诉。显然,这种盲目推进信创建设的行为是比较欠考虑的,且出现问题之后很难进行排查和故障定位。最终,该银行决定实践双轨超高可用架构,通过将部分核心业务在信创区域和非信创区域进行双轨运行,按照一定比例进行业务发布,充分预留出容错空间,为业务平滑性提供了稳步推进。最后,神州云科利用大数据引擎,帮助用户构建了一个大数据分级平台,通过这种无探针的采集实现了 T+0 的业务可视化。不仅帮用户解决了信创业务上线的可靠性问题,还帮助用户构建了信创业务全路径的可视化。

 

与此同时,神州云科在架构设计的过程中同样围绕国内主流的硬件厂商做了很多兼容验证性工作。在负载均衡部分,研发团队突破了很多难题,最终云科通明湖信创系列产品性能突破了 80G 的大关,足以满足当前绝大多数客户在信创应用交付领域的性能需求。此外,神州云科的容翼系列产品在设计之初就考虑到要与云原生与微服务应用进行结合,以容器为底座并进行了 API 优先设计,可以帮助客户自动实现应用快速调用或者批量配置下发。在网络端口设计部分,该架构的高端接口部分设计了百 G 的网络接口,中低端在 25G 左右,这些接口全部都可以向下兼容,可以满足当前客户未来对于高流量输入输出的需求,同时兼具了绿色节能低碳环保的设计理念。

 

随着相关文件的出台,企业的信创进程明显加快。在这个过程中,企业内部的组织架构、技术栈设计等难免出现各种问题,只有可以充分容错的架构设计方案才可以更好地满足要求。信创不是唯一目标,业务和应用的可持续运行才是,双轨超高可用架构则在二者之间达到了绝妙的平衡。

 

2023-01-09 14:2511642
用户头像
赵钰莹 极客邦科技 总编辑

发布了 886 篇内容, 共 656.9 次阅读, 收获喜欢 2681 次。

关注

评论

发布
暂无评论
发现更多内容

【Java优化实战】「微基准系列」带你脚踏实地的进行开发和使用JMH测试和提升应用程序和服务指南

洛神灬殇

Java JMH 3月日更 JMH性能基准测试

英特尔公司高级副总裁、中国区董事长王锐: 下一个中国是中国!

科技之家

MathType2023免费版数学公式编辑器

茶色酒

MathType2023

推荐这5个很牛的开源项目,程序员直呼内行

引迈信息

开源 低代码

2022 IoTDB Summit:宝武智维徐少锋《Apache IoTDB 在宝武装备远程智能运维平台中的使用案例》

Apache IoTDB

大数据 时序数据库 IoTDB

1行Python代码,把PPT转成图片,python-office功能更新~

程序员晚枫

Python Office 自动化办公

三天吃透SpringMVC面试八股文

程序员大彬

Java spring springmvc

2022 IoTDB Summit:中冶赛迪工业互联网平台与CISDigital-TimeS(基于IoTDB)在钢铁行业的实践

Apache IoTDB

大数据 开源 IoTDB

你应该了解哪些延迟数字?

Kian.Lee

I/O Latency CPU 寄存器 RAM SDD L1\L2\L3

ListView简单实用

芯动大师

ListView baseadapter stackfrombottom

Jetpack-Compose 学习笔记(一)—— Compose 初探

修之竹

android Compose android jetpack

好用的数据校验&修复工具gt-checksum开源啦

GreatSQL

greatsql社区 gt-checksum

Spring进阶:定义bean时容易踩的两个坑,连老手也容易犯错

程序员拾山

spring

C++ 线程池

王玉川

c++ 编程语言 多线程 线程池

Docker 环境搭建

流火

Docker

ChatGPT,开启人机交互新篇章 | 社区征文

柒号华仔

人工智能 openai ChatGPT

阿里云函数计算助力高德 RTA 广告投放系统架构升级

Serverless Devs

Serverless 高德

软件测试 | Dashboard是什么?

测吧(北京)科技有限公司

测试

软件测试 | K&S批量运行测试用例

测吧(北京)科技有限公司

测试

设计模式之美—接口隔离

GalaxyCreater

设计模式

5分钟部署百台云上计算机,22支参赛队伍快速接入南网电力调度AI应用大赛

云布道师

无影云电脑

Janus: 基于eBPF的5G实时AI控制器

俞凡

架构 网络 通信 ebpf RIC

四步走搭建自己的专属 ChatGPT(附开源代码)| 社区征文

FN0

AI 话题广场 ChatGPT

2022 IoTDB Summit:IoTDB PMC 乔嘉林《端边云协同:Apache IoTDB 全新单机分布式架构》

Apache IoTDB

4.基于Label studio的训练数据标注指南:情感分析任务观点词抽取、属性抽取

汀丶人工智能

自然语言处理 数据标注 实体抽取

这样在 C# 使用 LongRunnigTask 是错的

newbe36524

C# Docker Kubernetes

Matlab实现小波变换

timerring

图像处理 数字图像处理

用友成为铸基计划-2022标准建设贡献单位!

用友BIP

免费赠送测试开发精品课,提高职场竞争力!

测吧(北京)科技有限公司

测试

详解基于 Celestia、Eclipse 构建的首个Layer3 链 Nautilus Chain

西柚子

放弃网站不是明智之举,中小企业要选择适合自己的营销模式

石头IT视角

当架构进入“超高可用”时代,信创环境下的应用可持续运行得到保证_AI&大模型_赵钰莹_InfoQ精选文章