系统整体介绍
环路监控系统，是以用户行为为维度，对系统和整个业务流程进行链路监控的平台。避免系统问题被运营客诉反馈，被动应对，它帮助我们主动发现业务异常。每一个流程内的节点在发生挤压、停留、重试时，提供精准监控并实时报警，给我们争取解决问题的时间。并且可以对业务发生的金额进行把控，在业务发生资损时第一时间控制住，在金额上提供日、周、月各维度全景图展示，同时可在高风险金额节点重点把控。后续，系统可在监控到节点异常时向外部系统发送消息，收到消息的系统可自动进行降级、锁定、追损、拦截等操作。主要有以下五个亮点：
一、清晰展示业务流程链路，业务链路中的每一个核心节点都有完整的数据展示，流量、重试量、流转方向、红绿灯等。
二、精准定位数据滞留节点，数据通透性、流转性都清晰的展示在链路节点上，当发生滞留时能马上实时知道数据走向与滞留数量，并可以下钻到具体滞留用户。
三、快速抽取异常流程数据，当发生异常需要紧急对用户进行处理时，可以将异常数据快速定位，查出具体哪些人受到影响，以及影响范围，事态严重程度等信息。
四、准确溯源所属服务实例，业务异常最终可定位到具体的运行机器，方便底层研发查询使用，快速做出判断，同时找到根本原因是研发、运营、还是外部问题等。
五、灵活监控运算公式配置，系统内公式引擎支持用户自主配置监控公式，可监控到：滞留、重试、比率、数量、金额等，同时可以跨业务模版进行金额出入比对监控，为后续资金对账做准备。
页面展示
下面介绍一下两个重点页面：
一、数据监测
页面清晰地展示需要监控的每个流程：整体指标、节点数据等，每个绿色方块表示流程中的节点，里面有节点信息和数据，当方块颜色变黄（如下图）就表示此节点有数据滞留，里面数据也将精确展示滞留值，非常直观易懂。
二、数据趋势
数据趋势可以查看各个时间节点数据量变化，对于急速出现的波峰波谷有据可查。同时自定义的公式配置也同样可以展示数量变化的一个走势图，这样能更加方便用户查询问题。
系统架构
一、环路监控系统架构 V1.1.0
被监控的业务系统通过接入数据采集中间件，进行收揽业务数据，系统按照定义的业务链路进行存储，同时为了保证数据不会错位记录，每一个业务节点都采用主辅串联结构方式进行存储。
二、扩展架构
为了能让系统更加安全可靠且扩展性强，我们还独立开发了工具型中间件：
1、缓存多读多写中间件，融合 JimDB、R2M，可通过实现 RwxExtAuto 类进行更多控制，包括：配置主读、同步写、异步写、写关闭、读开启、读关闭 (用于刷新缓存)、配置监控等。
2、RPC 路由，可以进行 JSF 接口路由，将数据库路由前置，减少数据库连接数，支持横向扩展。
- 应用场景一：拆分数据库连接数
目前我们所有分库分表的应用，每一台数据库都被所有机器实例链接，每一个被路由的用户每次都可能被不同的实例链路引入到所属该用户的指定库表上。但在 618 和双 11 大促在进行机器扩容时，每一台数据库都将要被更多的机器实例进行链接，在达到系统瓶颈后很难再进行扩展。
环路监控开始接入约 5 个月时间，累计进入数据量约有 20+ 亿数据，为了能保证后续接入更多的业务流程而不影响系统性能，我们在 RPC 端进行路由，将数据库路由前置，减少数据库连接数，提升系统性能。下图为拆分前后的对照图：
- 应用场景二，拆分内存横纵扩展
在业务系统中，有很多应用到系统内存的地方，例如环路监控、营销活动、营销文案等，在系统启动时需将信息加载到内存，通过调用内存数据提升系统性能。但单台机器可加内存有限，当达到一定数据容量后会出现性能下降情况。这时就可使用 RPC 路由，将内存进行分组，把数据按照一定的路由方式存放到不同的分组模块内，大大降低单台机器的内存占用。
由原来的 N 台机器，每个机器都存放 200M（假设）拆分为 Y 组机器，每组里有 M 台机器，每组机器拆分内存为 200M/Y，减轻单台机器内存压力，提高内存可用率。下图为拆分前后的对照图：
后续规划
接下来我们团队会持续提升系统易用性，让使用者更加方便的查询问题；并将数据逐步接入量化部门，最终找到用户为什么滞留到此？如何去引导解决问题等优化。
后续还将努力把系统共享出来，推广给需要的人。期待环路监控能成为使用者手中的利器，达到将风险控制在客诉之前，将资损控制在最低的目标，为客户提供更好的体验。欢迎感兴趣的京东同事一起沟通，可联系邮箱：ringroad@jd.com ，或直接咚咚付政委、乔瑞刚。
评论