写点什么

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

  • 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:2512571
用户头像
赵钰莹 极客邦科技 总编辑

发布了 894 篇内容, 共 679.6 次阅读, 收获喜欢 2694 次。

关注

评论

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

Android开发38岁被裁,本以为稳进Top3,今天已经是失业第42天

android 程序员 移动开发

Android开发三年半5月份离职,面试10家公司后,这些面试官常问的面试题一定要了解

android 程序员 移动开发

Android常见原理性面试题(1),2021年阿里Android面试题精选

android 程序员 移动开发

Android应届毕业生“过五关斩六将”,移动端开发技术

android 程序员 移动开发

Android开发之旅:HelloWorld项目的目录结构,1个月学会Android开发

android 程序员 移动开发

Android常见原理性面试题,android高级开发面试题以及答案

android 程序员 移动开发

Android平台HTTPS抓包解决方案及问题分析,flutter弹窗效果

android 程序员 移动开发

Android庞大的源码体系是怎么设计的?2020字节跳动Framework-高频面试题详细总结

android 程序员 移动开发

Android开发北漂 8 年,飘飘飘 飘够了。,android开发艺术探索笔记

android 程序员 移动开发

Android开发把-LiveData-用于事件传递那些坑,一文详解

android 程序员 移动开发

Android应用保活实践,做了6年的Android

android 程序员 移动开发

Android庞大的源码体系是怎么设计的?2020字节跳动Framework 高频面试题详细总结

android 程序员 移动开发

Android常用adb命令,开源新作

android 程序员 移动开发

Android干货---丢掉你老旧的参数传递方式,投入Bracer的怀抱吧。

android 程序员 移动开发

Android应用启动流程分析,10天拿到字节跳动Android岗位offer

android 程序员 移动开发

Android应用开发者面试时HR是怎样试出你的真实水平!(1)

android 程序员 移动开发

Android开发之Theme、Style探索及源码浅析,音视频小程序开发

android 程序员 移动开发

Android开发失业50天,面了10家公司,唯二的offer也主动拒了

android 程序员 移动开发

Android开发1年背了几十份面经还是连挂了6个面试,拿到最终字节腾讯offer后我总结了这些坑点

android 程序员 移动开发

Android开发人员不得不收集的代码(持续更新中),重磅来袭

android 程序员 移动开发

Android开发必看:一文教你完全理解DataBinding框架(下

android 程序员 移动开发

Android开发没有一技之长就废了吗?,flutter通知推送

android 程序员 移动开发

Android学习路线总结,绝对干货,保洁阿姨看完都会了

android 程序员 移动开发

Android平台Camera开发实践指南,【大牛疯狂教学】

android 程序员 移动开发

Android应用开发性能优化完全分析,flutter蓝牙开发

android 程序员 移动开发

Android小菜鸡2 个月的面试亲身经历告诉大家,如何进入 BAT 等大厂?

android 程序员 移动开发

Android应用开发者面试时HR是怎样试出你的真实水平!,大厂Android开发面试解答

android 程序员 移动开发

Android应用开发进阶,android开发从入门到精通项目案例版

android 程序员 移动开发

Android开发已经到了要烧香求职的地步了?,Android程序员的春天

android 程序员 移动开发

Android开发必看:一文教你完全理解DataBinding框架(上

android 程序员 移动开发

Android开发最担心,在乎的三个问题!你有几个,android直播原理

android 程序员 移动开发

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