一、背景 当下，直播带货已经成为一种重要的消费场景。它重构了传统商场乃至电商的人货场关系，打造了一种即时的、沉浸式的消费体验。有赞做为一个商家 SaaS 服务公司，为商家提供了商品管理，售卖的全流程服务，其中就对接了许多直播带货的渠道，例如快手、陌陌、微博、虎牙等等。有赞的商家可以在上述的渠道直播卖货。但是不同于 SaaS 服务，直播带货属于平台级的业务，平台有义务对平台商家的商品进行审核，剔除部分因为资质或者商品类目不满足平台要求等等原因而不允许售卖的商品。然而，…
Read More一、引言 1.1 背景 年初，一个月黑风高的夜晚，数据中台的TL独自坐在工位上，左手托着下巴，右手搭着键盘，指尖缓动，眉头紧锁。面对下边这张图，本可以下班的他，迟迟不愿离开。 过去的半年，有赞的业务高速增长，可喜可贺。但是数据中台的计算资源消耗也水涨船高，半年翻一番，甚至超过业务涨幅。再这么下去，部门恐怕要凉凉，想到这，不禁打了个寒颤。…
Read More一、背景 2020H1我们开展数据中台-离线数据成本治理并取得了一定的成效(详情可以参考往期文章：从量化到优化，详解有赞离线降本之路)。文中预告了下半年会拓展成本治理的范围，H2我们便开始思考并投入有赞数据的全局管理。不限于离线数据，实时数据、内部的平台工具均需要做到可管理、可治理。 此外，数据成本透明度同样需要提升。目前成本只能覆盖至数据中台内部，和前台业务关联度低的问题需要解决。用户层面，我们也收到了诸多需求，例如需要相对灵活的成本分析功能、可满足多种角色的分析视角等。 带着这些问题和用户需求，我们开始构建数据中台的全域成本账单，力求达成如下几个目标： 成本多类型支持 成本全业务覆盖…
Read More一、问题背景 线上监控到大量接口报错，定位到异常机器，将异常机器隔离后，线上服务恢复正常。 拿到业务报错日志如下 异常信息显示Dubbo线程池活跃线程数已经达到最大线程数200，说明线程池资源已经耗尽。 二、问题排查 线程池资源耗尽，猜测Dubbo线程都被某个耗时方法阻塞了，或者线上有异常突发流量。 查看线上监控，发现服务请求流量正常，猜测Dubbo线程是被阻塞住了。 2.1 Dubbo线程为何被阻塞？ 通过jstack获取Dubbo线程堆栈信息，发现大量Dubbo线程的线程状态都为WAITING状态，阻塞在CompletableFuture#join。 找到相关代码行，…
Read More