支撑京东上千业务线、百亿级交易量的金融系统，在架构设计上有哪些难点？

3 月 1 日，InfoQ 技术大会旗下《大会早班车》直播栏目邀请到了京东科技金融科技群架构师康杨，来一起聊一下金融级系统海量流量下的高可用架构实践话题，本文整理自直播内容。

同时，康杨也将参与 3 月 17-18 日的 ArchSummit 全球架构师峰会北京站，他将在高并发架构实现专题下分享《金融级系统海量流量下的高可用架构实践》。复制链接了解演讲详情：https://archsummit.infoq.cn/202303/beijing/presentation/4917

康杨：大家好，我叫康杨，目前在京东科技，主要是负责金融相关的工作，重点是推动整体的架构升级和数字化转型和高可用体系的打造。我日常重点关注是业务和技术之间的关系，主要是三个方向：

第一方向是：如何通过技术更好实现业务达成，满足业务的诉求；

第二个方向是：如何在业务场景快速裂变，业务模型快速变化，底层基础设施持续更新迭代的情况，保证系统的高可用，保障业务的连续性；

第三个方向是：如何通过对技术的挖掘来赋能业务，也就是业内大家都在谈的数字化转型，业务和技术的双轮驱动。

康杨：其实这里面聊的是一个时代背景的问题，其实我觉得现在最大的一个优势就是国家的十四五规划，也就是国家的意志和动力在推动着这场变更，过去关于企业还在讨论要不要进行数字化转型，到现在已经基本达成共识。就是一定要用云计算、大数据、AI 等新兴技术，帮助企业提升效率并进行更好的商业化运作。我觉得这对于金融行业，以及每一个从业者来说都是一个巨大的机会。

康杨：金融系统的可用性直接影响到用户的钱包，所以相关的各类用户都更加关注，也更容易受到攻击，同时金融是一个强监管的行业，金融系统的可用性，不仅仅是金融公司本身重要的事情，也是各级监管部⻔密切关注的内容。而且金融行业也是一个对于信任非常看重的行业，用户的信任是业务存续的前提，所以相较于其他行业，系统的可用性或者说业务的连续性对于金融行业相较于其他行业是一件更重要的事情。

历史上比较有名的比如美国的 9.11 事件，不同的金融公司日常对于高可用或者业务连续性的重视的区别，导致在灾难面前业务能恢复的时间，和在消费者中的口碑受到了很大的影响，甚至直接反映到股价上。也是在 9.11 之后，人们才真正对金融行业系统的可用性，业务的连续性投以足够的重视。从而引出了巴塞尔协议，《巴塞尔协议》明确指出，操作⻛险是由于不确定的内部操作流程、人员、系统或外部事件导致的直接或间接损失的⻛险。由于信息系统软件、硬件、网络、机房环境、通信电力等不确定性因素发生故障，导致业务中断或者出现差错，势必对金融机构的服务、资金、名誉等造成损失。近年来，国际社会日益关注操作性⻛险防控和金融系统的稳定，因而建立一套以业务连续性⻛险控制为核心的⻛险防控体系，防止运营中断事件发生或者即使发生要能快速应对，是金融机构确保业务连续运营和健康发展的重要途径，也是面临的痛点和难点。

金融的系统的可用性、业务连续性，对业务的展业、名誉、资金、用户体验各方面都是有很大的影响的，所以也是被越来越重视的原因。

康杨：每次备战其实不亚于发起一起战役，从战略制定到战术执行，从战前的多兵种配合演练，到战时的有效应对，保障成功，我理解可以精炼成一句话：看得准、做的对、运气好。

第一个就是：看的准。所谓看的准就是理解备战是什么，哪些需要备战，本次备战有哪些不同，⻛险点在哪，以我自身为例，虽然已经经历了快 10 次备战，但是每次对于备战的理解都不一样，而这种感觉和《三国演义》里草船借箭那段，诸葛亮对于兵的理解非常像，他说：“兵者有可⻅之兵，荷戟执戈，肉躯之身乃可⻅之兵，不可⻅之兵者，日月星辰，⻛云水火，山川之灵气，如此万物万象，均可以为兵。为将帅者，不懂天文，不明地理，不晓阴阳，不懂奇⻔遁甲及阵图兵势乃庸才也。”

对应到备战里，我的感觉是已知越多未知越多，而我们很容易陷入到已知里，看不到变化和未知的⻛险，比如我们肯定会做链路的梳理，容灾的规划，曾经有一个核心系统，每次备战都需要按照一个非常高的 TPS 来备战，而作为研发也是以能够支持这个 TPS 的系统为荣，当然也会通过技术的升级优化，提升单机的吞吐，实现降本增效。

但是从另外一个维度，这么高的流量是从哪来的，是否都是有效的？而这就是另外一种思路和视野，当然也需要全链路的理解和跨部⻔的沟通，而结果是通过全链路的梳理和上游的优化，我们需要备战的 TPS 直接降为原来的十分之一，而以这样的方式，在核心的链路上，我们在其他的系统上也取得了类似的非常好的效果。这也体现了备战的一个趋势，就是从单一部⻔的备战到跨部⻔的协同优化。包括现在业内越来越火的业务混部等都是从更高的视⻆，去做整体的协同降本。包括降级方案，我们谈到降级方案，⻢上就会想到滑动窗口，但是如何构建一个全链路的整体降级方案，实现一个全链路的高可用，我理解才是真正的挑战，这就像你打造了一个非常结实的柜子，但是如果地震的时候，你所在楼房就是质量很差的，你依然难以幸免。

还有就是关于不可⻅之兵，我想举个例子就是时间，我们谈到备战会想到系统梳理、容灾规划、容灾备案、降级预案、军演压测、监控，但是时间也是一个很隐秘的但是非常重要的因素，比如秘钥到期，证书到期，费用到期，跨时区，跨年、跨月、跨日，关键时间的定时任务，可能其他都准备的很好，但是忽略了这一点也会产生影响。

第二个就是：做的对。每次备战我们一定会准备很多预案，当然还会有历史成功经验的累计，但是所有的预案是否都是可执行的，出现异常的时候谁来决策，如何决策，如何执行，谁来执行，如何验收，如何恢复，其实也是非常关键的。

第三个就是：运气好。虽然每次备战都非常顺利，但是我们依然不敢掉以轻心，每一次都当成是第一次去备战，避免经验主义。因为本来每次面对的也是不同的客体，业务本身是在快速变化的，包括云原生这些基础设施的应用，每一次都是全新的挑战，运气好的另一层理解，我觉得是要保持敬畏之心，避免陷入到历史的成功里，而忽略到眼前的未知的⻛险。

康杨：就像您说的，革新是一种动作，而不是一个目标，也就是不要为了革新而革新，首先要认清革新的目标是什么，确定好革新的价值和意义，当然也要认清革新的必然性，新是相对于旧来说的，背后的含义其实是这个世界是在快速变化的，我们目前处于信息化时代向数字化转型的阶段，云作为基础设施也得到了越来越多的应用，覆盖各行各业，即使是作为传统金融机构比如银行，也在国家十四五规划制定下，快速进行各种基础设施的升级，作为金融科技公司，我们这些年也一直在技术的前沿探索技术的应用和技术对业务的赋能，包括像类似科技上云，混沌工程，数字化架构升级等，也取得了非常好的效果。

康杨：首先我们提到了高可用架构，我理解可以从两个维度来考虑，第一：什么是高可用，第二：如何通过架构来赋能高可用。

关于第一点：什么是高可用，关于这个词，其实好像空气和水一样，似乎大家都不会有什么歧义，业内也有很多相关性的定义，比如从整体性来看，SLA（Service-Level Agreement），从时间的⻆度来说有 MTTR，包括海恩法则，好像我们每次提到高可用就很自然想到几个 9，我们会说，我们的系统是 2 个 9，还是 3 个 9，还是 5 个 9，9 的个数越多就越觉得很牛。

而实际上对于不同的行业、不同的公司、不同的部⻔、不同的系统、不同的人，甚至不同的人的不同阶段，高可用的含义和感受其实是完全不一样的，这就很像我们经常说的，大家都在读《红楼梦》，但是“仁者⻅仁，智者⻅智”，对中医感兴趣的，读到了药方，对于建筑感兴趣的，读到了园林设计，对历史感兴趣的，读到了典故。每个人都在读红楼梦，每个人都在说它好，但是这个好背后的语义，好的程度，这个好对每个人的意义是完全不同的。所以认知的不统一，以及不知道不统一，是我认为的第一个难点。

以我的经历来说，我刚毕业的时候是在富士康工作，负责富士康和 NOKIA 之间的电子商务系统，虽然这个系统也很重要，但是还是属于内部系统，用户主要是内部的采购、运营，使用的时间也是固定的，不用考虑凌晨是否有人用，就是下班后用的人也不多，所以当时在我的认知里就没有高可用的概念，或者只要不耽误业务人员使用，那就是高可用的。

第一次让我对高可用有了概念的时候是我去了搜狐，当时我负责搜狐微博的 NewsFeed，也就是现在新浪微博的前身，当时我刚加入搜狐，有一天晚上因为数据库的连接池没有关闭，导致我把系统重新发布了 6 次才好，我还非常清晰的记得，当时我老板和我说，你再搞不定老板就下来找你了，但是也是那次，让我意识到除了能写代码，对于问题的快速定位和诊断，以及熟练掌握相关的工具是非常重要的，也是那次问题，让我知道了一个命令就是 LSOF 可以查看链接的建立情况，也让我意识到这些我们平时不关心的事情，在关键的时候却可能是救命的。但是在搜狐的整个工作期间，不管是做博客，还是后来我们做最早的 SNS 白社会，日常工作中对于高可用其实没有那么强的感知，一个方面是大家的能力确实都很强，很少出错，另一方面，即使出现问题也还好，起码我是没遇到过哪个老板冲下来找我们查问题的情况。

直到接手目前的工作，包括参与历次备战，才让我对于高可用有了全新的认知，但是这种认知，其实也是在各种失败中获得的，否则我们很容易陷入到一个自己虚拟的假设里，比如认为调用失败通过重试就能解决问题，比如我们目前的监控报警已经非常完善了，比如非关键的应用不会影响到核心的应用，比如故障发生时的沟通是顺畅的，所以对高可用的正确、全面的认知是第一个难点。

第二个难点：我理解是成本和⻛险之间的矛盾，造成高可用的一个关键点就是流量，就是突然的高流量对于系统的冲击，但是降本增效是业内大家基本都在做的事情，所以如何平衡成本和⻛险，同时还要考虑用户体验，我理解是高可用设计的第二个难点。

第三个难点：高可用是一个体系，而不仅仅是一些解决方案或者平台，如何打造一个全面的高可用体系，不管是面的广度的思考还是单个技术难点的攻克，都是比较大的挑战。

第四个难点：我理解是变化，我们要解决的问题在变，我们所应用的基础设施也在变，如何在变化中，保持一种业务与技术之间的平衡，也是需要考虑的内容；第二个方面就是如何通过架构赋能高可用，我们提到架构的价值或者架构师的职责就是降低系统复杂度，通过架构降低系统的⻔槛，而关于架构的高可用，其实业内已经有了非常成熟的方案，比如服务的无状态、设计数据架构时候的通过“冗余”实现高可用，读写分离、数据异构、异地多活、限流、降级、完善的监控体系等，如何在架构中把这些好的经验进行沉淀，减少人为犯错的机会和成本也是需要重点考虑的。

康杨：第一个我觉得非常关键的点，我觉得是选择。08 年 facebook 非常火的时候，当时 Social game 非常火，做 AS3 的程序员薪资很高，供不应求，类似的你会发现不同时间点市场的需求其实是不一样的，而且这种迭代速度会越来越快，以前可能是十年，慢慢的五年，然后可能一年就有颠覆性的出现，所以如何不被时代淘汰我认为是第一位要去考虑的。金融行业就像刚才说的，也处在一个历史的变革期，在国家十四五规划的指引下，整个金融行业的数字化转型已经越来越快，如何成为一个符合这个时代要求的人，找准新时代下自己的定位，我理解是非常关键的一步。

第二个我觉得非常关键的点，是终生学习。其实这也是一种世界观，我其实非常喜欢稻盛和夫说的，意思是“人生就是不断提高自己的人性，修炼灵魂，带着比初到人世时有更高层次的灵魂离开这个世界”，这一点也是支撑你做出正确选择的基础。

第三个点就是问题就是机会，能力的培养不是靠死读书来提升的，杨绛先生曾经说过一句话，“年轻的时候以为不读书不足以了解人生，直到后来才发现如果不了解人生，是读不懂书的。读书的意义大概就是用生活所感去读书，用读书所得去生活吧”，我也一直以为，代码是被加密的，不理解背后的问题，是无法真正读懂代码的，或者说对代码的领悟在代码之外，所以只有不断的去解决问题，不断的实践才能真正不断的提升。

第四个点就是不断的思考的能力，所谓“学而不思则罔，思而不学则殆”。

第五个点不要给自己一个局限，如何不断的打破认知的边界，比如柏拉图的洞穴隐喻提到的内容。

第六个点就是连接，一个架构师越到后面越是很难依靠自己的能力，只有不断的链接，汇聚更多的能量，才能更好地解决问题。

康杨，京东科技金融科技群架构师。目前整体负责京东支付 PaaS 化改造工作；北京消费券、国密改造、科技统一账号、科技开放平台架构师；所负责系统支撑京东 1000+ 业务线，大促 TPS 百万级，多宝阁账务平台，支撑科技多条核心业务线百亿级交易量。

2023 年 3 月 17-18 日，ArchSummit 全球架构师峰会将落地北京海航万豪酒店。来自百度、京东、华为、腾讯、斗鱼、中国信通院等企业与学术界的技术专家，将就数字化业务架构、低代码实践、国产化替代方案、分布式架构等主题展开分享讨论。

目前已上线数字化场景下的业务架构、低代码实践与应用、国产软件优化迭代之路、多数据中心的分布式架构实践、软件质量保障、技术 - 产品 - 业务、高并发架构实现、架构师成长与团队搭建落地实践、大数据和人工智能融合、大规模微服务架构演进、可观测技术落地、云原生大数据实践等多个专题，点击阅读原文去官网查看大会日程。

会期临近，门票即将售罄。购票及其他问题咨询请联系票务同学：15600537884（微信同电话）。