从我离开公司算起，整整在国内 SaaS 行业待了5年，从2017年开始几乎每年都被称为“SaaS元年”，但是中国的 salesforce 一直都没有出现。究其原因，内因外因皆有，每个人的答案也不尽相同。所以我想从我的角度去聊一聊 SaaS 到底是在做什么。

人生如逆旅，我亦是行人

这是3月的最后一天发给下属的告别信的标题。

创业五年，从上海西站的一个出租屋到三地办公室，百人规模的公司，经历了太多太多，休息了一个月之后我打算把这些故事写下来。今天是开篇，总结一下过去五年的得失。

2021不算好，2022需要重启

这是我在2021年最后的几分钟发的Twitter。大概也代表了对去年一年的基本看法，但是从内心上一定是希望未来会好。

本文已在Apache Hudi中文公众号发布 原文链接

可变数据的处理一直以来都是大数据系统，尤其是实时系统的一大难点。在调研多种方案后，我们选择了 CDC to Hudi 的数据摄入方案，目前在生产环境可实现分钟级的数据实时性，希望本文所述对大家的生产实践有所启发。

起源

Linkflow 作为客户数据平台（CDP），为企业提供从客户数据采集、分析到执行的运营闭环。每天都会通过一方数据采集端点（SDK）和三方数据源，如微信，微博等，收集大量的数据。这些数据都会经过清洗，计算，整合后写入存储。使用者可以通过灵活的报表或标签对持久化的数据进行分析和计算，结果又会作为MA (Marketing Automation) 系统的数据源，从而实现对特定人群的精准营销。

MySQL到其他异构数据库之间的同步，一般来说都是通过binlog + canal的方式，现在比较流行的说法称其为 change data capture (CDC)，其实canal的诞生可以追溯到2014年，那会儿CDC的概念可能还没有，可见业界造词能力有越来越强的趋势。

遇到canal的这个问题说来也是诡异，异构数据库间同步的模块已经半年多没有变化。但是问题突然在一次upgrade后出现，所以一直在upgrade有关的模块排查，甚至一度想要rollback。

MySQL死锁从产品之初就偶有发生，算是萦绕在心中的噩梦之一。由于死锁大都伴随着锁等待，所以一般都会拉低服务QPS，在死锁发生时肯定会出现各种意料不到的问题。前期一直采用“指标不治本”的办法，对特别容易产生死锁的方法增加retry。但当retry和事务嵌套在一起时也会出现不可预知的错误。

对于数据库死锁这个万恶之源，真可谓深恶痛绝，所以这次在解决retry和事务嵌套问题时，将这个元凶也一并解决。

距离上次博文已经有快半年了。原本打算在过年期间写一篇2019年的回顾和总结。但也被这突如其来的疫情打乱。放假期间一直关注相关新闻导致信息过载，一度非常沮丧。

2月复工以后，停止了疫情信息的摄取，反倒心理上轻松不少。人都是健忘的，可不是吗？

言归正传，上篇博文说遇到一个服务假死的问题，具体现象就是服务不再接收任何请求，客户端会抛出Broken Pipe。正好最近又重现了，并且找到了root cause。

这两天遇到一个服务假死的问题，具体现象就是服务不再接收任何请求，客户端会抛出Broken Pipe。

配置其实分为结构和内容两个方面，结构对应的是代码，比如1.0.0新开发的代码上有一个功能开关${feature.switchA}，但master上还没有，这就是结构的变化。另一方面是内容，1.0.0的开发分支有两个测试环境，连着不同的数据库，那么对应的${mysql.url}的内容肯定不同。

内容的类别上也可以分为三种：业务配置，功能开关，服务配置。

Spring Cloud的配置中心是Spring Config，经过两年的使用，发现了其中不少的问题，有些是使用问题，有些是Spring Config本身的管理能力导致的问题。

Spring Config首推基于git的管理方式，提供了两个管理维度，一个是label(即branch)，一个是profile。当服务foo在一套代码下要安装多套环境，比如预发布环境有2套，一套在shanghai机房，一套在beijing机房。那么比较自然的管理维度就是利用profile，foo-shanghai.yaml以及foo-beijing.yaml。当生产环境也依然需要2台时，怎么处理呢？这时候就会有两种做法，一种利用增加label维度做区分，一种依然只用profile。

Webhook是一种非常强大的推送机制，如果熟悉WordPress的同学可以类比构建WP生态的各类钩子函数。Githubt通过webhook让开发人员可以监听仓库的变化触发持续集成工具的运作，比如Travis CI。