时间过得很快啊，一转眼已经到了 2024 年，还记得 15 年刚工作那会掌握个 SSM/H(Spring/Struts2/Mybatis/Hibernate) 框架就能应付大部分面试了。

现在 CS 专业的新同学估计都没听说过 SSM。

恰好从我刚开始工作时的移动互联网热潮到电商->共享经济->toB 大热->如今我都经历了一遍，技术栈也有由最开始的单体应用+物理机发展到现在的 kubernetes 云原生架构。

当然中途也经历了几个大的阶段：SOA服务化-> 微服务-> 云原生-> 服务网格-> 无服务等几个阶段。

最近一份工作又主要是在做基础架构，我认为了解的还算是比较全面的，所以本文我就以我的视角分享下我们在 2024 年应当使用哪些云原生技术栈，因为涉及到的技术组件比较多，就不过多讨论细节了。

但可以保证的是提到的技术栈都是我所用过的，优缺点都会提到，主打一个真实体验。

首先是操作系统，这里有别于以往我们传统的操作系统(Linux/Windows Server/MacOS)，主要指的是云原生的操作系统，没有太多可以选择的余地，那就是 kubernetes。

不过怎么维护好 kubernetes 是一个难点问题，还记得去年下半年滴滴出过一次事故，网传就是 kubernetes 升级出现的问题。

根据我们的经验来看，对于小团队更建议直接托管给云厂商，维护 kubernetes 是一个非常复杂的工作，小团队通常都是一职多能，自己维护更容易出问题。

当然大团队有专人维护最好，即便是出问题也能快速响应，前提是自己能 cover 住这个风险。

因为我们是小团队，所以考虑到成本和稳定性，我们也只使用了云厂商的 kubernetes 能力，其余的部分可控组件由我们自己维护（具体的后文会讲到）。

既然都用了云厂商的容器服务，那也要考虑到云厂商故障可能带来的问题；比如去年的阿里云故障。

所以现在一些中大厂也会选择多云方案，将同一份代码部署在多个云服务商，一旦其中一个出现问题可以快速切换。

但具体的实施过程中也有许多挑战，比如最棘手也是最关键的数据一致性如何保证？

当然我们可以采用一些支持分布式部署的数据库或中间件，他们本身是支持数据同步的；比如消息队列中的 Pulsar，它就可以跨级群部署以及消息同步。

同时多云部署对应的成本也会提升，在这个“降本增效”的大背景下也得慎重考虑；所以对此还有一个折中方案：

我们的技术架构需要具备快速迁移到其他云服务的能力，比如我们内部有一些工具可以定期备份资源，比如 MySQL 的 binlog，一些中间件的元数据，同时可以基于这些元数据快速恢复业务。

一般遇到需要切换云服务时都是一些极端情况，所以允许部分运行时的数据丢失也是能接受的，我们只要保证最核心的数据不会丢失从而不影响业务即可。

这个说起来简单，但也需要我们花时间进行模拟演练；具体是否实施就得看公司是否接受云服务宕机带来的损失以及演练所花的成本了。

我们是具备恢复元数据能力的，但会丢失部分运行时的数据。

既然我们已经选择 kubernetes 作为我们云原生的操作系统，那我们的持续集成与发布也得围绕着 kubernetes 来做。

上图是一张使用 Git 配合 gitlab+ArgoCD 的流程图，我们使用 gitlab 来管理源码，同时也可以利用他的 Pipline 帮我们做持续集成，最终使用 Argo 帮我们打通 kubernetes 的流程。

也就是我们常说的 GitOps。

同时我们的回滚历史版本，扩缩容都由 kubernetes 提供能力，我们的 DevOps 平台只需要调用 kubernetes 的 API 即可。

当然还有现在流行 FinOps，我的理解主要是做云成本的管理和优化，对应到我的工作就是回收一些不用的资源，在不影响业务的情况下适当降低一些配置