伴鱼技术团队

Technology changes the world

前言

随着伴鱼业务和用户的快速增长,公司运营活动的形式也越来越丰富,从活动的大类上总结有(包括但不限于):团购活动、排行榜&拉票活动、红包雨活动、预售秒杀活动、抽奖活动等,这些运营活动对于提升转化、用户留存和高用户活跃度等会起到重要作用,因而运营活动占用了增长部门非常多的研发资源。

其中,形如:“用户 A 完成了 W 动作发放 X 奖励(或者触发某种逻辑)”这样形式的需求会比较常见。在初期承接的过程中,各自活动独立开发,有许多重复的开发量,并且即使是重复的部分仍然需要测试同学的介入,各方都有很大的资源投入,并且还会导致整体流程会很长,通常一个活动开发联调和测试时间需要两周左右。所以,高效可复用地进行运营活动是 ROI 非常高的一件事情。

初探

前言中提到了活动中经常出现形如:“用户 A 完成了 W 动作发放 X 奖励”这样形式的需求,如下图所示,我们将满足这种语法的需求定义为一个任务:

...

阅读全文 »

理论篇 中,我们介绍了伴鱼在调用链追踪领域的调研工作,本篇继续介绍伴鱼的调用链追踪实践。在正式介绍前,简单交代一下背景:2015 年,在伴鱼服务端起步之时,技术团队就做出统一使用 Go 语言的决定。这个决定的影响主要体现在:

  1. 内部基础设施无需做跨语言支持
  2. 技术选型会有轻微的语言倾向

1. 早期实践

1.1 对接 Jaeger

2019 年,公司内部的微服务数量逐步增加,调用关系日趋复杂,工程师做性能分析、问题排查的难度变大。这时亟需一套调用链追踪系统帮助我们增强对服务端全貌的了解。经过调研后,我们决定采用同样基于 Go 语言搭建的、由 CNCF 孵化的项目 Jaeger。当时,服务的开发和治理都尚未引入 context,不论进程内部调用还是跨进程调用,都没有上下文传递。因此早期引入调用链追踪的工作重心就落在了服务及服务治理框架的改造,包括:

  • 在 HTTP、Thrift 和 gRPC 的服务端和客户端注入上下文信息
  • 在数据库、缓存、消息队列的接入点上埋点
  • 快速往既有项目仓库中注入 context 的命令行工具

部署方面:测试环境采用 all-in-one,线上环境采用 direct-to-storage 方案。整个过程前后大约耗时一个月,我们在 2019 年 Q3 上线了第一版调用链追踪系统。配合广泛被采用的 prometheus + grafana 以及 ELK,我们在微服务群的可观测性上终于凑齐了调用链 (traces)、日志 (logs) 和监控指标 (metrics) 三个要素。

下图是第一版调用链追踪系统的数据上报通路示意图。服务运行在容器中,通过 opentracing 的 sdk 埋点,Jaeger 的 go-sdk 上报到宿主机上的 Jaeger-agent,后者再将数据进一步上报到 Jaeger-collector,最终将调用链数据写入 ES,建立索引,即图中的 Jaeger backends。

distributed-tracing-v1

...

阅读全文 »

引言

中台架构是最近一两年最火热的话题之一,其承诺提供的企业级复用能力对所有公司都是非常具有吸引力的,因而一批又一批企业先后进行中台化改造,然而成功的案例不多,失败的案例却隔三差五地出现,为什么出现这样的问题呢?本文从伴鱼技术 & 数据中台对中台化组织架构的目标愿景的探索过程中,给出伴鱼技术团队对这一问题的思考。

做中台架构,是在追潮流,还是真的想清楚了?

技术潮流和时尚潮流一样,都是代表了人们当前主流的选择,同时,技术潮流也和时尚潮流一样,并不一定适合每一个人和公司,气质匹配才能相得益彰。伴鱼技术团队是在 2018 年开始进行中台化架构调整的,当时伴鱼技术团队的决定基于对下面两个方面的思考:

...

阅读全文 »

TL;DR

本文将调用链追踪系统的设计维度归结于以下 5 个:调用链数据模型、元数据结构、因果关系、采样策略以及数据可视化。我们可以把这 5 个维度当作一个分析框架,用它帮助我们在理论上解构市面上任意一个调用链追踪系统,在实践中根据使用场景进行技术选型和系统设计。如果你对调研相关系统很感兴趣,也欢迎参与到 Database of Tracing Systems 项目中,一起调研市面上的项目,建立起调用链追踪系统的数据库。

引言

阅读本文并不要求读者具备任何调用链追踪系统相关的理论知识或实践经验,读者具备一定的微服务架构的概念或实践经验即可。期望读者看完这篇文章以后,能掌握调用链追踪系统的核心设计维度,理解其中的设计权衡,并能使用这些维度来分析市面上的新老调用链追踪系统实现,甚至帮助到自己在生产实践中根据使用场景进行技术选型和系统设计。

解决的问题

...

阅读全文 »

本文介绍一种内存列存数据格式:Apache Arrow,它有一个非常大的愿景:提供内存数据分析 (in-memory analytics) 的开发平台,让数据在异构大数据系统间移动、处理地更快。同时,比较特别的是这个项目的启动形式与其他项目也不相同,Arrow 项目的草台班子由 5 个 Apache Members、6 个 PMC Chairs 和一些其它项目的 PMC 及 committer 构成,他们直接找到 ASF 董事会,征得同意后直接以顶级 Apache 项目身份启动。

本文从以下几个方面来介绍 Arrow 项目:

  • Arrow 项目的来源
  • Arrow 如何表示定长、变长和嵌套数据
  • 内存列存数据格式与磁盘列存数据格式的设计取舍

注:Arrow 即可以指内存列存数据格式,也可以指 Apache Arrow 项目整体,因此下文中将用 「Arrow」 表示格式本身,「Arrow 项目」表示整体项目。

...

阅读全文 »

前言

波塞冬,是伴鱼活动运营解决方案的总称,包含活动规则体系、h5 可视化开发平台等,名称来源于古希腊神话,波塞冬是海洋和所有水系的管理者,寓意为 palfish 发展提供超能力。

目前的问题

avatar

随着伴鱼业务的高速发展,大量促增长的活动接踵而来, 原有的研发模式暴漏出一系列问题,如后端逻辑混杂、复用度低、维护成本高,前端灵活性差、效率低,为了提升公司运营效率,我们急需探索一套符合公司现状的技术体系,为公司的业务高速发展提供平台支撑。

万物终有源,要解决掉面临的问题,我们从整个研发、运营链路出发寻找答案。研发链路上在前后端分离的技术大背景下,我们的目标是要最大化的实现后端服务复用、前端页面复用,对运营而言是能够快速灵活的对活动策略、展示作出修改,来查验各种活动对业务的作用效果,基于以上思考,我们抽象了波塞冬平台的业务模型。

平台概览

avatar

...

阅读全文 »

引言

PingCAP 团队的论文《TiDB: A Raft-based HTAP Database》入选 VLDB 2020,这是对 TiDB 数据库阶段性成果的肯定,非常为国内数据库技术的快速发展而感到高兴。由于关于 TiDB 数据库在高可用、水平扩展和 ACID 事务的实现方案很久以前就已经公布出来了,对于这些主题大家都比较熟悉,所以就不再赘述了,下面主要谈谈论文中关于如何实现数据强一致性且资源隔离的 HTAP 数据库的一些启发和感想。

OLTP or OLAP

大家都知道数据库分为 OLTP 和 OLAP 类型,那么数据库为什么要分成这两类型呢?

首先,OLTP 和 OLAP 是定义数据处理方式的,这是两个差异特别明显的工作负载,OLTP 操作是涉及数据少,但是实时性和事务要求高,并发量大;OLAP 操作是实时性和事务要求低,但是涉及数据量大,并且查询模式不固定,很难通过索引来覆盖。其次,早期的数据库是没有 OLTP 和 OLAP 类型之分的,在一个数据库(主要为关系数据库)里进行 OLTP 和 OLAP 类型的数据相关的操作,后来数据量慢慢变大,直接在关系数据库中同时处理 OLTP 和 OLAP 类型的请求开始力不从心,更坏的情况可能还会影响到 OLTP 类型的请求,所以针对 OLAP 场景设计了更符合其工作负载的 OLAP 类型数据库,通过将 OLTP 类型的数据同步到 OLAP 类型的数据库,然后再进行 OLAP 类型的操作。

...

阅读全文 »

前言

可视化埋点,也称圈选埋点,是建立在全埋点技术基础上的一种数据埋点机制。通过全埋点技术,尽可能地将用户的所有交互行为进行采集上报,然后通过可视化圈选的方式筛选出感兴趣的行为统计数据,为产品运营提供决策支持。可视化埋点具有“全面、便捷、低技术门槛”的特点,能够有效降低研发、运营成本,是对传统代码埋点技术的有力补充。

本文结合伴鱼iOS端在圈选埋点技术上的一些实践经验,对圈选埋点方案的设计和实现进行探讨。

总体思路

从数据采集到生成统计报表,一般需要经过三个步骤,如下图所示

main frame

...

阅读全文 »

本文的缘起是回答知乎圆桌会议「分布式系统之美」的问题「如何系统性地学习分布式系统?」,后面稍微整理了一下,形成了这一篇文章(知乎 ID:kylin)。

前言

学习一个知识之前,我觉得比较好的方式是先理解它的来龙去脉:即这个知识产生的过程,它解决了什么问题,它是怎么样解决的,还有它引入了哪些新的问题(没有银弹),这样我们才能比较好的抓到它的脉络和关键点,不会一开始就迷失在细节中。

所以,在学习分布式系统之前,我们需要解决的第一个问题是:分布式系统解决了什么问题?

分布式系统解决了什么问题?

第一个是单机性能瓶颈导致的成本问题,由于摩尔定律失效,廉价 PC 机性能的瓶颈无法继续突破,小型机和大型机能提高更高的单机性能,但是成本太大高,一般的公司很难承受;

第二个是用户量和数据量爆炸性的增大导致的成本问题,进入互联网时代,用户量爆炸性的增大,用户产生的数据量也在爆炸性的增大,但是单个用户或者单条数据的价值其实比软件时代(比如银行用户)的价值是只低不高,所以必须寻找更经济的方案;

...

阅读全文 »

概念:熔断与限流

微服务架构中,服务数量大大增加,调用关系变得复杂。用户的一个请求,会放大为内部服务间的若干次调用,依赖实际上变多了。而一个服务的故障,沿着调用链传播,也可能造成难以预料的影响。更糟糕的是,在服务数量很多的时候,故障是无可避免的。不论单个服务可用性达到几个 9,在服务数量 N 很大时,它的乘方一定会离 0 越来越近。在这种现状下,增强整体容错性就成为一项重要的工作。

一方面当下游服务挂掉时,上游服务作为调用方,需要有一定容错能力,设置一些兜底逻辑,尽量避免直接随之也挂掉。同时,也应避免无脑多次重试,降低下游服务的负载,使其有恢复的机会。
另一方面,作为服务本身,其资源是有限的,服务能力也是有上限的。对于超出上限的流量,只能忍痛丢弃。毕竟只服务部分请求,总比接收所有请求然后拖死整个系统要好得多

这两方面的考量,正是我们稳定性平台的主题:熔断与限流。网络上流传着一句话,熔断、限流、降级是分布式架构的三板斧,可见其重要性。

...

阅读全文 »