如何选择可以搞钱的技术栈

Posted on 2024-11-26 In OB Views: Views: Disqus:

前言

之前在公司主要负责可观测性和 Pulsar 消息队列相关的内容，最近系统比较稳定，只需要做日常运维，所以就抽出时间逐步在接触 OLAP 相关的技术栈。

我们用的是 StarRocks，也是目前比较流行的 OLAP 数据库；在接触的这段时间以来，让我越发感觉到选对一个靠谱的技术方向的重要性。

这里以 Pulsar 举例，Pulsar 也是 Apache 的顶级项目，有一定的技术门槛，同时也解决以往消息队列的一些问题（多租户、低延迟、存算分离等）但如果把它作为一个商业产品的话，相对来说付费能力还不够强。

其实也能想得到，就单纯的消息中间件在市场上能讲的故事不多，可以将它融入到其他的生态里，比如数据处理、业务解耦等，但总归是配角，没有它虽然没那么优雅，但也可以玩。

同理 OpenTelemetry 也是类似的，它用于可观测性系统，主要是就是拿来排查问题的，对于企业来说也谈不上刚需。

他们两个都有一个共同的特点：小公司不需要（或者自己维护开源版，量小也不容易暴露问题），大公司选择单独的团队自己维护，市场蛋糕较小。

即便是部分中厂可能选择购买云服务，一般也会选择和自己现有技术栈配套的云厂商，比如已经用了大部分阿里云的产品，这种周边服务也会尽可能的在阿里云上选择替代方案，毕竟这样的风险更小，而且国内的产品大多都写还 ALL IN。

可能更多的还是一些政企、金融等业务会选择这些开源产品的企业版，大部分因为需要私有化部署，不太方便直接使用公有云。

而更刚需的往往都是和数据相关的，比如数据库、MongoDB、ElasticSearch 、kubernetes 等，如果想要提升下非业务水平，倒是可以深入一下这些技术栈。

拿数据库来说，任何公司都需要，即便是小公司也不敢在生产环境自己维护数据库，一般也会购买云产品，或者是招一个 DBA。

同理还有云原生相关的基础技术栈，比如 kubernetes 以及围绕着 kubernetes 周边的生态。

k8s 作为云原生的基础底座，只要涉及到上云就离不开它，不管小厂选择云服务还是大厂自己托管都得需要相关技能。

即便不是直接做 kubernetes 开发也得需要了解相关的知识，对自己理解整个系统是如何运转的很大的帮助。

除此之外还有也有个简单的方法：就是看看你们公司为哪些服务买单。

以我最近接触到的 StarRocks 为例，也是和数据处理相关的公司，他们在疫情期间成立的商业化公司，这几年非但没受到影响反而还在增长。

看到他们的招聘还蛮活跃。

即便是厂商更倾向于选择云厂商的数据服务，StarRocks 这类原厂公司或多或少也会参与进去提供一些技术支持。

不过可能有人的第一反应是这些产品的技术门槛较高，上手比较困难，但其实这些往往都是自己给自己上的难度。

我之前根本就没有接触过 OLAP 相关的内容，但只要有场景，可以在本地 debug 复现，任何问题都很好解决，即便是这是你不熟的技术栈。

比如 ES 也是 Java 写的，如果你们公司为它付费了，那不如多花时间研究一下，不一定是需要改它的核心逻辑，上层也有很多东西可以参与的。

而一旦我们对这些技术栈熟悉之后，今后在换工作时就有着其他人不具备的优势，甚至可以加入这些技术背后的商业公司。

而这些公司大部分都是满足开发者的喜好：比如远程办公、技术驱动等，大家不妨从现在就可以试试。

不管是哪种技术最终都是要转换为我们到手的收入，所以选择对收入更加敏感的技术栈还是很有必要的。

以上的内容主要是针对后端开发，当然这里并不包含想要做独立开发的技术栈，主要还是用于求职。

大家可以看看自己公司以及曾经的公司有对哪些技术付费，或者是一些都需要的刚需通用的技术栈，深入这些技能对搞钱或多或少都有好处。