第三届数据库大赛 ADB 性能挑战赛赛题总结

前言

之前在分享《海量无序数据寻找第 K 大的数》这篇文章时,就已经提到过我参加了阿里云举办的《第三届数据库大赛创新上云性能挑战赛–高性能分析型查询引擎赛道》,传送门:https://tianchi.aliyun.com/competition/entrance/531895/introduction。 截止到 8 月 20 日,终于结束了漫长的赛程。作为阿里云员工的我,按照赛题规定,只能参加初赛,不能参加复赛,出于不影响比赛的目的,终于等到了比赛完全结束,才动笔写下了这篇参赛总结。

照例先说成绩,这里贴一下排行榜,总共有 1446 只队伍,可以看到不少学生和其他公司的员工都参赛了。

排名

我的成绩是第 14 名(普哥忙于 KPI,没有能带飞我,diss 一下嘿嘿),内部排名也是进入了前五,虽然被剥夺了参加复赛的资格,但是也给了内部的奖励作为补偿,奖品是啥呢?


Dubbo 支持的几个主流序列化框架评测

前言

今天要聊的技术是序列化,这不是我第一次写序列化相关的文章了,今天动笔之前,我还特地去博客翻了下我博客早期的一篇序列化文章(如下图),竟然都过去 4 年了。

历史记录

为什么又想聊序列化了呢?因为最近的工作用到了序列化相关的内容,其次,这几年 Dubbo 也发生了翻天覆地的变化,其中 Dubbo 3.0 主推的 Tripple 协议,更是打着下一代 RPC 通信协议的旗号,有取代 Dubbo 协议的势头。而 Tripple 协议使用的便是 Protobuf 序列化方案。

另外,Dubbo 社区也专门搞了一个序列化压测的项目:https://github.com/apache/dubbo-benchmark.git ,本文也将围绕这个项目,从性能维度展开对 Dubbo 支持的各个序列化框架的讨论。

当我们聊序列化的时候,我们关注什么?

最近几年,各种新的高效序列化方式层出不穷,最典型的包括:

  • 专门针对 Java 语言的:JDK 序列化、Kryo、FST
  • 跨语言的:Protostuff,ProtoBuf,Thrift,Avro,MsgPack 等等

为什么开源社区涌现了这么多的序列化框架,Dubbo 也扩展了这么多的序列化实现呢?主要还是为了满足不同的需求。

序列化框架的选择主要有以下几个方面:

  1. 跨语言。是否只能用于 java 间序列化 / 反序列化,是否跨语言,跨平台。
  2. 性能。分为空间开销和时间开销。序列化后的数据一般用于存储或网络传输,其大小是很重要的一个参数;解析的时间也影响了序列化协议的选择,如今的系统都在追求极致的性能。
  3. 兼容性。系统升级不可避免,某一实体的属性变更,会不会导致反序列化异常,也应该纳入序列化协议的考量范围。

和 CAP 理论有点类似,目前市面上很少有一款序列化框架能够同时在三个方面做到突出,例如 Hessian2 在兼容性方面的表现十分优秀,性能也尚可,Dubbo 便使用了其作为默认序列化实现,而性能方面它其实是不如 Kryo 和 FST 的,在跨语言这一层面,它表现的也远不如 ProtoBuf,JSON。

其实反过来想想,要是有一个序列化方案既是跨语言的,又有超高的性能,又有很好的兼容性,那不早就成为分布式领域的标准了?其他框架早就被干趴了。

大多数时候,我们是挑选自己关注的点,找到合适的框架,满足我们的诉求,这才导致了序列化框架百花齐放的局面。

性能测试

很多序列化框架都宣称自己是“高性能”的,光他们说不行呀,我还是比较笃信“benchmark everything”的箴言,这样得出的结论,更能让我对各个技术有自己的认知,避免人云亦云,避免被不是很权威的博文误导。

怎么做性能测试呢?例如像这样?

1
2
3
long start = System.currentTimeMillis();
measure();
System.out.println(System.currentTimeMillis()-start);

貌似不太高大上,但又说不上有什么问题。如果你这么想,那我推荐你了解下 JMH 基准测试框架,我之前写过的一篇文章《JAVA 拾遗 — JMH 与 8 个测试陷阱》推荐你先阅读以下。

事实上,Dubbo 社区的贡献者们早就搭建了一个比较完备的 Dubbo 序列化基础测试工程:https://github.com/apache/dubbo-benchmark.git。

dubbo-benchmark

你只要具备基本的 JMH 和 Dubbo 的知识,就可以测试出在 Dubbo 场景下各个序列化框架的表现。

我这里也准备了一份我测试的报告,供读者们参考。如果大家准备自行测试,不建议在个人 windows/mac 上 benchmark,结论可能会不准确。我使用了两台阿里云的 ECS 来进行测试,测试环境:Aliyun Linux,4c8g,启动脚本:

1
java -server -Xmx2g -Xms2g -XX:MaxDirectMemorySize=1g -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/admin/

为啥选择这个配置?我手上正好有两台这样的资源,没有特殊的设置~,况且从启动脚本就可以看出来,压测程序不会占用太多资源,我都没用满。

测试工程介绍:

1
2
3
4
5
6
7
8
9
public interface UserService {
public boolean existUser(String email);

public boolean createUser(User user);

public User getUser(long id);

public Page<User> listUser(int pageNo);
}

一个 UserService 接口对业务应用中的 CRUD 操作。server 端以不同的序列化方案提供该服务,client 使用 JMH 进行多轮压测。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
@Benchmark
@BenchmarkMode({Mode.Throughput })
@OutputTimeUnit(TimeUnit.SECONDS)
@Override
public boolean existUser() throws Exception {
// ...
}

@Benchmark
@BenchmarkMode({Mode.Throughput})
@OutputTimeUnit(TimeUnit.SECONDS)
@Override
public boolean createUser() throws Exception {
// ...
}

@Benchmark
@BenchmarkMode({Mode.Throughput})
@OutputTimeUnit(TimeUnit.SECONDS)
@Override
public User getUser() throws Exception {
// ...
}

@Benchmark
@BenchmarkMode({Mode.Throughput})
@OutputTimeUnit(TimeUnit.SECONDS)
@Override
public Page<User> listUser() throws Exception {
// ...
}

整体的 benchmark 框架结构如上,详细的实现,可以参考源码。我这里只选择的一个评测指标 Throughput,即吞吐量。

省略一系列压测过程,直接给出结果:

Kryo

1
2
3
4
5
Benchmark           Mode  Cnt      Score      Error  Units
Client.createUser thrpt 3 20913.339 ± 3948.207 ops/s
Client.existUser thrpt 3 31669.871 ± 1582.723 ops/s
Client.getUser thrpt 3 29706.647 ± 3278.029 ops/s
Client.listUser thrpt 3 17234.979 ± 1818.964 ops/s

Fst

1
2
3
4
5
Benchmark           Mode  Cnt      Score       Error  Units
Client.createUser thrpt 3 15438.865 ± 4396.911 ops/s
Client.existUser thrpt 3 25197.331 ± 12116.109 ops/s
Client.getUser thrpt 3 21723.626 ± 7441.582 ops/s
Client.listUser thrpt 3 15768.321 ± 11684.183 ops/s

Hessian2

1
2
3
4
5
Benchmark           Mode  Cnt      Score      Error  Units
Client.createUser thrpt 3 22948.875 ± 2005.721 ops/s
Client.existUser thrpt 3 34735.122 ± 1477.339 ops/s
Client.getUser thrpt 3 20679.921 ± 999.129 ops/s
Client.listUser thrpt 3 3590.129 ± 673.889 ops/s

FastJson

1
2
3
4
5
Benchmark           Mode  Cnt      Score      Error  Units
Client.createUser thrpt 3 26269.487 ± 1667.895 ops/s
Client.existUser thrpt 3 29468.687 ± 5152.944 ops/s
Client.getUser thrpt 3 25204.239 ± 4326.485 ops/s
Client.listUser thrpt 3 9823.574 ± 2087.110 ops/s

Tripple

1
2
3
4
5
Benchmark           Mode  Cnt      Score       Error  Units
Client.createUser thrpt 3 19721.871 ± 5121.444 ops/s
Client.existUser thrpt 3 35350.031 ± 20801.169 ops/s
Client.getUser thrpt 3 20841.078 ± 8583.225 ops/s
Client.listUser thrpt 3 4655.687 ± 207.503 ops/s

怎么看到这个测试结果呢?createUser、existUser、getUser 这几个方法测试下来,效果是参差不齐的,不能完全得出哪个框架性能最优,我的推测是因为序列化的数据量比较简单,量也不大,就是一个简单的 User 对象;而 listUser 的实现是返回了一个较大的 List<User> ,可以发现,Kryo 和 Fst 序列化的确表现优秀,处于第一梯队;令我意外的是 FastJson 竟然比 Hessian 还要优秀,位列第二梯队;Tripple(背后是 ProtoBuf)和 Hessian2 位列第三梯队。

当然,这样的结论一定受限于 benchmark 的模型,测试用例中模拟的 CRUD 也不一定完全贴近业务场景,毕竟业务是复杂的。

怎么样,这样的结果是不是也符合你的预期呢?

Dubbo 序列化二三事

最后,聊聊你可能知道也可能不知道的一些序列化知识。

hession-lite

Dubbo 使用的 Hessian2 其实并不是原生的 Hessian2 方案。注意看源码中的依赖:

1
2
3
4
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>hessian-lite</artifactId>
</dependency>

最早是阿里开源的 hessian-lite,后来随着 Dubbo 贡献给了 Apache,该项目也一并进入了 Apache,github 地址:https://github.com/apache/dubbo-hessian-lite。相比原生 Hessian2,Dubbo 独立了一个仓库致力于在 RPC 场景下,发挥出更高的性能以及满足一些定制化的需求。

在 IO 线程中进行序列化

Dubbo 客户端在高版本中默认是在业务线程中进行序列化的,而不是 IO 线程,你可以通过 decode.in.io 控制序列化与哪个线程绑定

1
2
3
4
5
<dubbo:reference id="userService" check="false"
interface="org.apache.dubbo.benchmark.service.UserService"
url="dubbo://${server.host}:${server.port}">
<dubbo:parameter key="decode.in.io" value="true" />
</dubbo:reference>

在 benchmark 时,我发现 IO 线程中进行序列化,性能会更好,这可能和序列化本身是一个耗费 CPU 的操作,多线程无法加速反而会导致更多的竞争有关。

SerializationOptimizer

某些序列化实现,例如 Kryo 和 Fst 可以通过显示注册序列化的类来进行加速,如果想利用该特性来提升序列化性能,可以实现 org.apache.dubbo.common.serialize.support.SerializationOptimizer 接口。一个示例:

1
2
3
4
5
6
public class SerializationOptimizerImpl implements SerializationOptimizer {
@Override
public Collection<Class<?>> getSerializableClasses() {
return Arrays.asList(User.class, Page.class, UserService.class);
}
}

按照大多数人的习惯,可能会觉得这很麻烦,估计很少有用户这么用。注意客户端和服务端需要同时开启这一优化。

别忘了在 protocol 上配置指定这一优化器:

1
<dubbo:protocol name="dubbo" host="${server.host}" server="netty4" port="${server.port}" serialization="kryo" optimizer="org.apache.dubbo.benchmark.serialize.SerializationOptimizerImpl"/>

序列化方式由服务端指定

一般而言,Dubbo 框架使用的协议(默认是 dubbo)和序列化方式(默认是 hessian2)是由服务端指定的,不需要在消费端指定。因为服务端是服务的提供者,拥有对服务的定义权,消费者在订阅服务收到服务地址通知时,服务地址会包含序列化的实现方式,Dubbo 以这样的契约方式从而实现 consumer 和 provider 的协同通信。

在大多数业务应用,应用可能既是服务 A 的提供者,同时也是服务 B 的消费者,所以建议在架构决策者层面协商固定出统一的协议,如果没有特殊需求,保持默认值即可。

但如果应用仅仅作为消费者,而又想指定序列化协议或者优化器(某些特殊场景),注意这时候配置 protolcol 是不生效的,因为没有服务提供者是不会触发 protocol 的配置流程的。可以像下面这样指定消费者的配置:

1
2
3
4
5
<dubbo:reference id="userService" check="false"
interface="org.apache.dubbo.benchmark.service.UserService"
url="dubbo://${server.host}:${server.port}?optimizer=org.apache.dubbo.benchmark.serialize.SerializationOptimizerImpl&amp;serialization=kryo">
<dubbo:parameter key="decode.in.io" value="true" />
</dubbo:reference>

&amp; 代表 &,避免 xml 中的转义问题

总结

借 Dubbo 中各个序列化框架的实现,本文探讨了选择序列化框架时我们的关注点,并探讨了各个序列化实现在 Dubbo 中具体的性能表现, 给出了详细的测试报告,同时,也给出了一些序列化的小技巧,如果在 Dubbo 中修改默认的序列化行为,你可能需要关注这些细节。

最后再借 Dubbo3 支持的 Tripple 协议来聊一下技术发展趋势的问题。我们知道 json 能替代 xml 作为众多前后端开发者耳熟能详的一个技术,并不是因为其性能如何如何,而是在于其恰如其分的解决了大家的问题。一个技术能否流行,也是如此,一定在于其帮助用户解决了痛点。至于解决了什么问题,在各个历史发展阶段又是不同的,曾经,Dubbo2.x 凭借着其丰富的扩展能力,强大的性能,活跃度高的社区等优势帮助用户解决一系列的难题,也获得了非常多用户的亲来;现在,Dubbo3.x 提出的应用级服务发现、统一治理规则、Tripple 协议,也是在尝试解决云原生时代下的难题,如多语言,适配云原生基础设施等,追赶时代,帮助用户。


不会吧?不会还有人不知道 Arthas 可以条件过滤进行 watch 吧?

前言

Arthas 的 watch 指令一直是我排查线上问题时使用最多的指令,没有之一。而按照条件进行 watch 也是很常见的一个需求,例如线上一个方法会有大量的调用,而我们可以按照指定的条件,watch 到我们希望观察的那一次调用。

说实话,我对 Arthas 也没有什么研究,一开始还真不清楚原来 Arthas watch 可以按条件过滤,翻看一下官方文档:https://arthas.aliyun.com/doc/watch#id6

条件表达式的例子

1
2
3
4
5
6
7
$ watch demo.MathGame primeFactors "{params[0],target}" "params[0]<0"
Press Ctrl+C to abort.
Affect(class-cnt:1 , method-cnt:1) cost in 68 ms.
ts=2018-12-03 19:36:04; [cost=0.530255ms] result=@ArrayList[
@Integer[-18178089],
@MathGame[demo.MathGame@41cf53f9],
]

浅析 SpringMVC 中返回对象的循环引用问题

问题发现

@RestController、@ResponseBody 等注解是我们在写 Web 应用时打交道最多的注解了,我们经常有这样的需求:返回一个对象给前端,SpringMVC 帮助我们序列化成 JSON 对象。而今天我要分享的话题也不是什么高深的内容,可能大家多多少少也都遇到过,那就是返回对象中存在循环引用时的问题,分享我的一些思考。

该问题非常简单容易复现,直接上代码。

准备两个循环引用的对象:

1
2
3
4
5
6
7
8
9
10
11
@Data
public class Person {
private String name;
private IdCard idCard;
}

@Data
public class IdCard {
private String id;
private Person person;
}

海量无序数据寻找第 K 大的数

前言

最近在参加阿里云举办的《第三届数据库大赛创新上云性能挑战赛–高性能分析型查询引擎赛道》,传送门:https://tianchi.aliyun.com/competition/entrance/531895/introduction

好久没有打比赛了,也是突然来了兴致,参加性能挑战赛总有一种自己还年轻的感觉。因为比赛还没有结束,所以赛题解析还不方便这时候就写出来,但是其中一个优化点,倒是可以拿出来跟大家分享下。

简单抽象一下问题,便是今天的主题:在一个百万级无序的 long 数组中,寻找第 K 大的数值。要求当然是越快找到越好。


Nacos Client 1.4.1 版本踩坑记录

问题发现

就在这周,我接到 MSE Nacos 用户的反馈,说线上 Nacos 不可用,服务都下线了,日志里面也是一堆报错,我下意识以为线上炸了,赶紧上线排查。本文主要记录这次问题的排查过程,以及解决方案。

首先看用户反馈的报错,日志如下:

并且用户反馈业务日志也出现了大量的服务地址找不到的报错,说明 Nacos 服务都下线了。

我立刻查看了服务端的监控,发现用户的 MSE Nacos 集群并无异常,cpu/内存等指标有下降,并没有异常行为,排除了服务端异常的可能性。

随即将视线聚焦在了客户端。老实说,这个报错我第一次见,看异常堆栈,字面意思便是域名解析出问题了。这个报错大概持续了 10 分钟,立刻让用户在业务节点上使用 ping、dig 等工具确认域名解析是否正常,测试发现均无异常。继续让用户 telnet mse-xx.com 8848,发现也能够 telnet 通。

根据这些现象,大概能得出结论:用户的机器上出现了短暂的域名解析问题,导致短时间访问不通 MSE Nacos。但用户继续反馈说,一部分重启以后的机器已经恢复了,但没有重启的机器,竟然还会出现调用报错。不然怎么说重启大法好呢,但也加深了问题的诡异性。

正当一筹莫展时,另一用户也找上来了,竟然也是一样的问题,并且由于第二个用户还同时使用了 redis,报错日志中除了出现 nacos 的域名解析问题,还报了 redis 的域名解析报错。至此,更加坚定了我之前推测,根因肯定是域名解析出现了故障,导致这两个用户收到了影响。但问题在于,为什么短暂的域名解析失败(大概 10 分钟),会导致持续性的 Nacos 问题呢?并且只有重启才能恢复。

分析两个用户的共性,最终我和同事将可疑点锁定在了 Nacos 客户端版本上,对比发现,用户都是同一个报错,并且竟然都是 nacos-client 1.4.1 版本。

##Nacos 1.4.1 版本引入的 bug

在问题发生时,Nacos 1.x 最新的版本已经是 Nacos 1.4.2 了,将源码 checkout 到 1.4.1 版本,追踪堆栈附近的问题,

上述这段代码是 Nacos 访问服务端的一段代码,进入 595 行,一探究竟。

我们成功找到了堆栈中的直接报错,就是这段 IsIPv4 的判断触发。splitIPPortStr 这个方法的主要逻辑是从 Nacos 的连接串筛选出连接地址,主要是为了做默认端口号的判断,如果用户没有携带 8848,会默认带上 8848。

但问题恰恰便是出现在这儿:

InetAddress.getByName(addr) 是一个内置的方法,描述如下:

1
Given the name of a host, returns an array of its IP addresses, based on the configured name service on the system.

意思是把一个域名传给操作系统,返回一串 IP,这不就是域名解析吗!我当时就很好奇,你说你判断 IPv4 格式,为啥要这么判断呢?直接判断 IPv4 的 pattern 不行吗?而这段代码,恰恰是导致问题的凶手之一。

我们看看 1.4.2,已经修复了这个逻辑了,直接改成了正则判断。

但疑问还是存在的,域名解析短暂失败了,为啥会导致服务全都下线了,并且解析恢复后,服务依旧没有上线呢?

继续追踪这段代码,发现 callServer 这段代码会被 com.alibaba.nacos.client.naming.beat.BeatReactor 持有,用于维持自身和 Nacos 的心跳。

而由于上述域名解析失败,抛出的异常是 IllegalArgumentException,并没有被里层方法转换成 NacosException,从而导致心跳线程没有 catch 住异常,彻底停止发送心跳了!

这也就成功解释了,为什么短暂的域名解析失败,会导致服务全部下线了。(Nacos 是利用心跳维护和 server 端的存活状态的)

改进建议

  1. 修改 isIPv6 和 isIPv4 的判断方式,改为正则匹配。上文提及,这点已经在 1.4.2 修复了。
  2. 心跳线程要保证不被异常中断下一次心跳的提交。

第二点,也已经被修复了。

总结

nacos-client 1.4.1 存在严重的 bug,客户端与 Nacos Server 如果发生短暂的域名解析问题,会导致心跳永久丢失,进而引发服务全量下线,即使网络恢复,也不会自动恢复心跳。

域名解析失败常见于网络抖动或者 K8s 环境下的 coreDNS 访问超时等场景,为避免域名解析对 Nacos 造成的重大影响,请务必自查应用代码中使用的 nacos-client 的版本。

该问题仅存在于 1.4.1 版本,低于此版本不受此问题的影响,使用 1.4.1 的用户建议升级至 1.4.2 以避免此问题。

使用 SpringCloud/Dubbo 的用户,需要确认实际框架使用的 nacos-client 版本,可以通过显式指定 nacos-client 的版本以覆盖框架默认的版本。其中 Dubbo 用户要格外小心,Dubbo 的 2.7.11 版本默认使用了 nacos-client 1.4.1,务必显式指定 nacos-client 的版本到 1.4.2,Dubbo 也将在下个 release 版本替换 Nacos 的默认版本。


警惕 Spring Boot Actuator 引发的安全漏洞

前言

一年一度的 HW 行动开始了,最近也是被各种安全漏洞搞的特别闹心,一周能收到几十封安全团队扫描出来的漏洞邮件,这其中有一类漏洞很容易被人忽视,但影响面却极广,危害也极大,我说出它的名字你应该也不会感到陌生,正是 Spring Boot Actuator

写这篇文章前,我跟我的朋友做了一个小调查,问他们对 Spring Boot Actuator 的了解,结果惊人的一致,大家都知道 Spring Boot 提供了 spring-boot-starter-actuator 的自动配置,但却很少有人真正用到它相关的特性。在继续往下面看这篇文章时,大家也可以先思考下几个问题:

  1. 检查下你开发的项目中有引入 spring-boot-starter-actuator 依赖吗?
  2. 你在项目中有真正用到 spring-boot-starter-actuator 的有关功能吗?
  3. 你知道 spring-boot-starter-actuator 的安全风险和正确配置方式吗?

Netty实现长连接服务的难点和优化点

转载自:https://www.dozer.cc/2014/12/netty-long-connection.html

原文作者:dozer

推送服务

还记得一年半前,做的一个项目需要用到 Android 推送服务。和 iOS 不同,Android 生态中没有统一的推送服务。Google 虽然有 Google Cloud Messaging ,但是连国外都没统一,更别说国内了,直接被墙。

所以之前在 Android 上做推送大部分只能靠轮询。而我们之前在技术调研的时候,搜到了 jPush 的博客,上面介绍了一些他们的技术特点,他们主要做的其实就是移动网络下的长连接服务。单机 50W-100W 的连接的确是吓我一跳!后来我们也采用了他们的免费方案,因为是一个受众面很小的产品,所以他们的免费版够我们用了。一年多下来,运作稳定,非常不错!

时隔两年,换了部门后,竟然接到了一项任务,优化公司自己的长连接服务端。

再次搜索网上技术资料后才发现,相关的很多难点都被攻破,网上也有了很多的总结文章,单机 50W-100W 的连接完全不是梦,其实人人都可以做到。但是光有连接还不够,QPS 也要一起上去。

所以,这篇文章就是汇总一下利用 Netty 实现长连接服务过程中的各种难点和可优化点。


小白也能懂的 Nacos 服务模型介绍

前言

按照目前市场上的主流使用场景,Nacos 被分成了两块功能:服务注册发现(Naming)和配置中心(Config)。在之前的文章中我介绍了 Nacos 配置中心的实现原理,今天这篇文章所介绍的内容则是与 Nacos 服务注册发现功能相关,来聊一聊 Nacos 的服务模型。

说到服务模型,其实需要区分视角,一是用户视角,一个内核视角。即 Nacos 用户视角看到的服务模型和 Nacos 开发者设计的内核模型可能是完全不一样的,而今天的文章,是站在用户视角观察的,旨在探讨 Nacos 服务发现的最佳实践。


谈谈中间件开发

最近频繁地在跟实习生候选人打交道,每次新接触一个候选人,都要花上一定的时间去介绍我们团队,候选人问的最多的一个问题就是「中间件部门一般是干嘛的?」,恰好我之前也接触过一些想从事中间件开发的小伙伴,问过我「现在转行做中间件开发还来得及吗?」诸如此类的问题,索性就写一篇文章,聊聊我个人这些年做中间件开发的感受吧。

什么是中间件开发?

我大四实习时,在一个 20 多人的软件开发团队第一次接触了中间件,当时项目的架构师引入了微博开源的 RPC 框架 Motan,借助于这个框架,我们迅速构建起了一个基于微服务架构的内部电商系统。接着在项目中,由于业务需求,我们又引入了 ActiveMQ…在这个阶段,我已经在使用中间件了,但似乎没有接触到中间件开发,更多的是使用层面上的接触。

我毕业后的第一份工作,公司有几百号研发,当时的 leader 看我对中间件比较感兴趣,有意把我分配在了基础架构团队,我第一次真正意义上成为了一名”中间件研发“,平时主要的工作,是基于开源的 Kong 和 Dubbo,进行一些内部的改造,以提供给业务团队更好地使用。这个阶段,做的事还是比较杂的,业务团队对某些中间件有定制化的需求,都需要去了解这个中间件,熟悉源码。这段时间,也是我成长最快的一个时期,我是在这个期间学会了 Docker、Neo4j、Kong 等以前从来没接触过的技术,并且更加深入地了解 Dubbo 这类 RPC 框架的原理。可能坐在我旁边的就是一个订单部门的同学,抛了一个功能点让我来改造。

现在,我供职于阿里云云原生中间件,相较于上一份中间件研发工作,阿里云这类互联网大公司,任意一个中间件都有少则数人,多则数十人负责,中间件部门和业务部门之间也有着明确的界限。在这里,中间件团队的职责可以细分为三个方向:

  1. 中间件团队会被业务团队的需求所驱动,为集团内部提供定制化的解决方案,俗称「自研」。所以你可能并不了解到 HSF、Diamond 这些阿里内部的中间件。
  2. 中间件团队会从事开源,花费大量的精力提升中间件的极致性能,提升开源影响力,引领技术先进性。这部分中间件则比较为人所熟知,例如 Dubbo、Spring Cloud Alibaba、RocketMQ、Nacos。
  3. 中间件会在阿里云输出商业化产品,相比开源产品,提供更高的 SLA、更强大的功能、更友好的交互。这部分商业化产品诸如:微服务引擎 MSE、消息队列 RocketMQ、分布式应用链路追踪 ARMS。

我的这三段经历,正好反应了不同规模的公司对中间件开发的不同需求。小公司使用中间件,例如 RPC、MQ、缓存等,基本是由业务开发人员自己维护的。但如果后台研发达到数百人,基本就会组建自己的中间件团队,或者选择使用阿里云等云厂商提供的中间件产品。


Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×