京东618：商城交易平台的高可用架构之路
据腾讯科技报道，6月18日零点，京东全民年中购物节拉开了高潮的序幕。第一个小时的销售额超过去年同期的250%。从凌晨开始的海量订单让6月1日就拉开序幕的京东年中购物节奏出最强音，大量用户瞬间涌入，峰值订单被不断刷新。为了应对如此大规模的流量增长，京东研发团队几乎全年都在高筑墙、广积粮，一直着力从技术层面为用户提供流畅的交易体验，以保证在峰值交易时期系统的高可用性。在京东整个电商体系中，交易系统占据着其中的半壁江山，购物车、结算、库存、价格等相关的环节都包含在其中，可以说交易系统的高可用能力基本上决定了整个京东商城的高可用能力。在过去的一年时间里，京东的交易系统做了哪些迭代和优化？今年又有哪些创新？整体的交易系统规划是怎么样的？InfoQ记者带着这些问题采访了京东商城交易平台高级总监王晓钟。
\u0026#xD;\u0026#xD;ArchSummit全球架构师峰会深圳站将于2017年7月7日~8日在深圳·华侨城洲际酒店召开，京东商城运营研发部总架构师者文明策划了《低延迟系统架构设计》专题，将会为大家分享目前各大互联网企业在低延迟系统架构设计上都有哪些新思路，欢迎关注。
\u0026#xD;\u0026#xD;下面是往年京东618以及双11交易平台相关的文章：
\u0026#xD;\u0026#xD;- \u0026#xD;\t
京东618：多中心交易平台系统高压下的高可用性
\u0026#xD;\t\u0026#xD;\t - \u0026#xD;\t
京东商城交易系统双11总结
\u0026#xD;\t\u0026#xD;\t - \u0026#xD;\t
京东商城交易系统的演进之路
\u0026#xD;\t\u0026#xD;\t - \u0026#xD;\t
京东商城交易平台系统架构变迁
\u0026#xD;\t\u0026#xD;
受访嘉宾介绍
\u0026#xD;\u0026#xD;王晓钟，京东商城交易平台高级总监，京东交易黄金流程与智慧营销生态系统的掌舵人，带领的产品与研发团队为京东商城提供了核心交易的系统保证。
\u0026#xD;\u0026#xD;InfoQ：能否整体介绍下交易平台目前的架构体系？
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;王晓钟：交易平台负责商品、价格、用户、库存、订单等电商核心基础信息的中心化管理，以及对购物车、结算页、优惠券/礼品卡、订单中心等黄金交易流程的管控和平台化服务。交易平台致力于技术改变生活，打造智慧营销的交易平台。为用户提供黄金交易流程；为客户提供智慧营销解决方案包含促销建议、智能库存定位等智慧营销工具；为研发团队提供稳定、可靠的交易服务。
\u0026#xD;\u0026#xD; \u0026#xD;\u0026#xD;
- \u0026#xD;\t
渠道是交易的流量入口来源，目前主要包含几大部分，PC、APP、微信、手Q等。目前APP入口已经占据了整体流量的70%以上。
\u0026#xD;\t\u0026#xD;\t- \u0026#xD;\t
组件完成对现有基础服务的抽象与整合，将现有服务资源以多元化的方式展示给外界，灵活的组织并支持多种协议的交互，最终实现了系统的模块化、服务平台化、功能配置化。组件最大限度的减少外界对内部逻辑的耦合，从而实现对需求快速响应。
\u0026#xD;\t\u0026#xD;\t- \u0026#xD;\t
基础服务位于整个黄金流程的最底层，其扮演者交易平台心脏的角色。其中商品服务、价格服务、库存服务、用户服务、购物车等更是核心中的核心。
\u0026#xD;\t\u0026#xD;\t- \u0026#xD;\t
中间件、基础设施是基础服务的基石，对业务系统提供高性能，高可用的技术支撑。
\u0026#xD;\t\u0026#xD;
InfoQ：过去一年，交易平台在保证底层的基础平台稳固方面做了哪些事情？有哪些点读者是可以参考学习的？
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;王晓钟：除了我们一直在做的、已经形成常规的工作，比如线上压测、性能优化、扩容、故障切换、限流、降级之外，过去一年，我们在系统维稳方面做了一些精细化的工作。
\u0026#xD;\u0026#xD;
- \u0026#xD;\t
核心调用链监控。在黄金交易流程中的各个服务入口点和服务相关依赖、调用方等进行联合监控。当服务性能下降、可用率下降时，可以快速的定位到故障点。把监控和故障解决方案联动起来，比如一键切换、服务降级、限流等，可以快速的发现和解决问题。
\u0026#xD;\t\u0026#xD;\t- \u0026#xD;\t
自动切换。对于成熟的切换流程，比如数据库、缓存、服务等节点的客户端，当检测到故障时，可以根据策略自动切换到健康的节点，同时在故障节点恢复后自动切换回来，减少人工操作的错误和耗时，提高系统的可用率。
\u0026#xD;\t\u0026#xD;\t- \u0026#xD;\t
异步化编程模式。部分服务通过彻底的异步化改造来提升吞吐量，还是有一些效果。但是由于纯异步化对于现有系统的改造还是挺大的，所以目前还在尝试前行阶段。
\u0026#xD;\t\u0026#xD;\t- \u0026#xD;\t
共享资源池。提前准备一些资源共享池，各服务混用，平时设置较低的权重。当某个服务的常规资源组不足时，则增加其在共享池中的权重，这样可以快速的使用资源，而不用临时扩容。
\u0026#xD;\t\u0026#xD;\t- \u0026#xD;\t
全链路压测。从入口开始模拟用户的行为进行压测，流量通过依赖传递，从浏览、搜索，到提交订单以及最后的生产，自动覆盖到链路中的所有环节。配合上面提到的核心调用链监控，解决以往只是单服务的压测，覆盖面不全的问题。
\u0026#xD;\t\u0026#xD;随着业务的发展，功能的复杂度也在不断增加，定位故障原因变的困难了起来，很多时候线上发生故障大部分的时间都在定位问题，故障的解决只要有预案就可以很快处理。调用链监控就很重要，可以站在全局的角度，快速的定位问题，和故障预案处理结合可以解决我们的痛点。
\u0026#xD;\u0026#xD;随着服务的不断扩容，机器数量的增加，出现问题时，故障修复的速度变慢，自动化的故障切换可以使人工解放出来，处理更重要的事情，可以让大家不用总是在半夜起来处理故障。
\u0026#xD;
InfoQ：目前交易平台的服务是依据什么维度进行划分的？
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;王晓钟：目前交易平台主要依据业务能力来划分服务的：购物车、结算页、促销、价格、库存、商品、用户等，为PC，手机，微信等渠道提供高可靠的大中台服务。
\u0026#xD;\u0026#xD;这种划分模式好处在于：
\u0026#xD;\u0026#xD;
- 架构稳定，因为业务能力相对稳定和相互独立。\u0026#xD;\t
- 开发团队是自主的，围绕着交付业务价值而不是技术特性来组织。\u0026#xD;\t
- 服务之间共同合作，松耦合。\u0026#xD;
InfoQ：能否分别从业务、系统、基础设施三个层面谈谈你们的监控体系方案？
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;王晓钟：在京东这样的大规模分布式系统面前，每时每刻服务器可能都宕机，网络随时可能都在抖动，大量接口调用量日均过亿，同时具有流量聚集效应的促销每天都会有好几波，如果没有一套强大的监控体系，我们就像睁眼瞎一样。经过多年的努力，京东目前已经形成多套监控系统，建立了比较完善的监控体系，时刻监视着系统的健康状态，并在发现问题时第一时间进行预警：
\u0026#xD;\u0026#xD;1）业务层面的监控，主要是核心业务指标，比如实时订单量，并按渠道、省份、运营商、机房、品类、活动等各个维度进行细分，从而在及时发现核心业务指标变化的同时，能够快速定位、排查问题，并做出应急响应。
\u0026#xD;\u0026#xD;2）系统层面的监控，主要是方法或代码块的调用量、成功率以及响应时间。同时，不同语言平台有特定的监控指标，例如Java应用，我们也非常关心JVM GC 情况。这些指标我们会按实例、集群、机房等进行逐级汇总计算。对于响应时间，我们更关心的是TP99甚至TP999任何一指标低于预设阈值都会触发报警。在采集单一接口性能数据的基础上，我们将请求访问链经过的一系列子调用串起来，包括RPC服务之间、访问缓存、访问数据库等等，实现调用链条薄弱环节的快速发现，快速解决。
\u0026#xD;\u0026#xD;3）基础设施的监控，主要是网络质量和机器健康度的监控，像常规的带宽、丢包率、重传、连通性，CPU、内存、磁盘等等。在网络方面，除了内网，我们也非常关心公网网络质量，一旦发现运营商或者区域故障，就会做立即出预案响应，7*24小时确保用户购物体验。
\u0026#xD;\u0026#xD;在监控指标完善的同时，我们更多在解决监控自身的延时性。京东自身访问量大，所以在提高监控的延时性同时又不能影响业务自身性能，本身就是就一个挑战。目前我们在业务层面、系统层面都做到了秒级粒度，基础设施方面的重要指标也有了秒级数据。在预警方面，除了传统的邮件、短信，我们集成了京东内部IM工具，同时还有手机语音呼叫。
\u0026#xD;\u0026#xD;在这么多指标，这么精细的数据面前，传统的监控仪表盘也会让我们再度迷失，因此我们开发了天眼系统进一步将各个监控子系统进行集成，结合前述的调用链，在一个大屏上多个核心主流程的各环节、各调用层次的当前健康状况一览无遗，一旦有故障我们可以在短时间内快速响应并恢复。
\u0026#xD;
InfoQ：对于恶意的流量攻击，京东做了哪些准备工作？准备如何预防？
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;王晓钟：恶意流量攻击，是每个互联网企业都必须面对的难题。目前我们把流量攻击分为两大类：网络协议层和应用逻辑层。
\u0026#xD;\u0026#xD;网络协议层的，主要是SYNFlood、UDPFlood、DNSFlood、HTTPFlood这些4层或7层协议的各种流量攻击，主要以带宽或服务资源消耗为主。目前我们通过京东云平台自研的流量分析和清洗系统能够防御主流的恶意流量攻击。除此之外，信息安全部门也会联合外部力量进行上百G的流量攻防演练，确保合作和联动等实战能力。
\u0026#xD;\u0026#xD;应用逻辑层的恶意流量的范围和影响则比较广泛。狭义上，恶意流量利用应用系统的软件漏洞，做拒绝服务攻击；广义上，能够利用应用的实现逻辑或规则漏洞，非法实现各种商业利益的，无论流量大小，都属于恶意流量攻击。这一大类型攻击由京东的多个部门配合进行整体防御。
\u0026#xD;\u0026#xD;1）信息安全部门会通过开展安全自查和外部合作报告漏洞的方式，由各业务研发部门实施安全漏洞消除，比如SQL注入、代码执行、水平越权、信息泄露等。
\u0026#xD;
\u0026#xD;2）风控部门会通过数据分析，建立各种等级的风险控制模型，形成动态的不同风险等级的账户池，供业务系统使用。
\u0026#xD;3）业务研发部门则根据业务特性、用户风险等级、系统压力等因素，提供不同策略的限流实现。
InfoQ：以商品的实时价格为例，聊聊你们的读逻辑和写逻辑流程？
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;王晓钟：京东实时价格面临几大挑战：一是数据量大，几十亿的商品；二是调用量大，日峰值上百亿；三是实时性要求高；最后是业务复杂度高，并不是单一的京东价，不仅要综合计算各类促销规则，还要对PC、手机、第三方合作渠道以及区域进行差异化运营。这里，我们运用读写分离、异步化策略，选择支撑大并发、高性能的开源组件进行设计，确保可水平扩展、高稳定性。
\u0026#xD;
\u0026#xD;1）写逻辑流程：当采销在后端调整价格或建立促销时，同步写入MySQL数据库，然后通过异步任务更新促销主Redis数据，并同时更新价格主Redis的过期时间戳，通过Redis自身复制机制，将数据传播到从节点。
\u0026#xD;2）读逻辑流程：当用户在前端浏览商品列表、详情等页面时，异步访问价格实时服务，此时内嵌Nginx 的Lua程序直接读取本地Redis（从）中的价格数据，无过期则直接返回用户；若过期或不存在，则回源访问价格实时计算服务，即刻返回最新价格给用户。
\u0026#xD;3）回源写逻辑：价格实时计算服务读取促销主Redis，在返回最新价格给用户的同时，异步写价格主Redis集群，价格主Redis同步数据至前置Nginx节点的从Redis节点。
InfoQ：今年618京东的交易平台都做了哪些技术上的改进或者创新，以及未来将会考虑哪些优化和升级方向？
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;王晓钟：除了上面提到的主要用来维护系统稳定的技术改造之外，今年交易平台也投入了更多的精力在做提升用户体验、提升GMV的改进和创新工作。比如利用大数据技术和机器学习模型，来提供千人千价、千人千促的体验。
\u0026#xD;\u0026#xD;我们也在尝试利用大数据和机器学习等在系统维稳上做一些工作，比如：
\u0026#xD;\u0026#xD;1）SQL注入和恶意代码执行方面引入了机器学习模型，通过对已有的攻击行为进行学习，训练特征。引入半监督学习，让模型可以通过学习，自动发现新型的攻击。大大提高了攻击的发现效率和新攻击的识别能力。各项指标已经完全超越传统的规则识别。
\u0026#xD;\u0026#xD;2）使用有向图模型对恶意攻击进行溯源检测，更加准确快速的进行溯源分析，并且得到了非常好的效果。
\u0026#xD;\u0026#xD;下一步，我们会继续尝试在这个方向上做一些创新，比如：
\u0026#xD;\u0026#xD;1）在人机行为检测方面进行优化。使用聚类和nlp模型对恶意刷单行为进行识别，提高恶意刷单行为的验证级别，从而极大地降低后台接口压力。
\u0026#xD;\u0026#xD;2）评论价值评定模型，识别真实评论和刷出来的评论。让评论产生更大的价值。
\u0026#xD;\u0026#xD;3）我们将在故障智能预测上进行探索。目前很多监控和预警都是事后的，我们希望能做到事前。通过分析历史性、周期性故障数据，结合当前实时健康度，快速识别出“濒死”的机器、实例，真正做到监控预警智慧化。
\u0026#xD;