京东花费充值架构

京东花费充值架构

1、应用层面

引入缓存

在应用层和数据库层增加缓存层，热点数据放入缓存。如系统中常用的开关、白名单等数据，读取频率高写入频率低，针对这部分数据就可以在JimDB(Redis)中存储一份，JimDB (Redis)会把高频数据存储在内存中，读写性能很高。数据写入缓存时设置一个有效期，更新数据库成功后，异步更新缓存数据。如果实时性要求不高，也可以等缓存失效后，主动更新缓存。引入缓存层，降低数据库压力，提升系统响应速度。

编写并发处理程序

多任务并发处理，充分利用CPU资源。无依赖关系的多条任务可以并行处理，提高系统处理能力。如结算任务，每笔订单之间的结算操作没有依赖关系，可以同时执行多条结算任务

系统结构优化

核心生成流程异步处理，接收用户订单和给用户充值两个流程异步化处理，提高系统处理能力。对用户来说，用户付款成功，等待充值即可。系统可通过worker触发充值动作，设置合理的重试次数，间隔一定的时间进行重试。在到达最终状态前，给用户显示中间状态。

从功能上进行微服务化以后，应用拆解为PC端、Server端、MQ消息处理端、后台管理端、worker端等五个应用，应用之间功能独立，依赖公司的RPC框架（JSF）和消息框架（JMQ）进行通信。单个应用的内聚性更高，应用之间的耦合度更低。再实现一个后台的需求时，开发、测试、部署都只需要关注后台管理端系统即可，无需再关注其他四个系统。

系统微服务化设计，关键点是如何寻找限界。

除了可以从功能上进行切分还可以根据关注点上进行拆解为生产端和支撑端，业务场景不同，寻找限界的方法也不相同，关键是微服务后单个应用的内聚性更高，应用之间的耦合度更低。

使大系统微服务化的方案有很多种，重点是制定好目标，逐步向目标靠拢。在服务粒度方面，如话费充值应用的MQ消息处理端，在功能上保持职责单一，只负责接收、解析MQ消息内容，具体业务逻辑处理交由相应的Server端处理。在技术选择上，公司有成熟的技术框架，如RPC框架JSF，消息框架JMQ等，这些框架都有对应的服务治理和监控等相关服务和团队。

数据库层面

当业务量发展到一定程度后，数据库就会成为系统的瓶颈。话费充值应用包含企业订单业务和普通用户订单业务，正是由于其业务的特殊性，采用了垂直+水平分库方案。根据业务类型进行垂直切分，不同业务类型订单数据独立存储，同一种业务类型在水平上由多个库保存。垂直+水平的分库方案能够最大限度的降低不同业务类型订单数据之间的相互影响，提高数据读写并发量。

普通用户订单业务，根据账户PIN进行hash打散可以均匀的分布到每个库中，sharding规则就是hash(pin)值，同时这个hash(pin）值还做为本地订单号的前缀，这样就可以通过账户PIN和本地订单号两个维度中任一维度都可以路由到数据库。创建ERP订单成功后，把本地订单号和ERP订单的映射关系保存到JmiDB中，对于只有ERP订单号的业务流程，可以通过映射关系找到本地订单号，有了本地订单号也就可以路由到数据库了。而企业订单业务，每个企业账户的订单量不均，差别能达到三个数量级，如果再根据账户PIN进行hash打散分布到每个书库中的订单就会不均匀，不能使用这种sharding规则。根据本地订单号进行hash，然后再作为本地订单号的前缀。创建ERP订单成功后，同样需要保存本地订单号和ERP订单号的映射关系到JmiDB中，以保证在后续的业务流程中，能够根据ERP订单号路由到数据库。

应用部署

计算机的CPU、线程、IO等资源都是宝贵且有上限的，当某一个资源耗尽时，那这台计算机上所有的服务都将停止服务。例如某一个服务依赖的第三方服务性能低，响应缓慢，这时如果客户端的继续请求，会导致该服务持续创建线程等资源，最终导致服务宕机。此时，计算机资源的隔离显得尤为重要。

在JVM内部隔离分为信号量隔离和线程池隔离，Netflix Hystrix插件提供了完美的支持。JD-Peer（多机房公网出口路由系统）中使用了Hystrix对每一个商家进行了隔离。话费充值应用对接了几十个商家，通过JD-Peer系统跟商家进行交互。由于某些网络原因导致其中一个商家A响应慢，持续的调用，所有资源都会被这一个商家占用，导致其他商家服务也不可用，最终宕掉。

经过上面一系列的改造升级，话费充值应用的吞吐量、运行稳定性都达到了最优的状态，历经数次的618和双11冲击，各项运行指标保持稳定，面对流量洪峰，岿然不动。