2023年总结
2023年总结
前言
2023年过得很快，以至于现在我才想起，现在已经是2024年。在22年除放弃了一次 offer 后，22年底再一次拿到机会后我还是耐不住安逸加入了某厂，回过头一看满打满算居然已过一年。自己的见识和视野拓展了不少，可以说有很多问题是以前根本不会考虑的，也可能是流量小业务不复杂的场景下确实是不太需要考虑的，但是现在面对一个问题都得挖空心思去想，这么做会有什么问题，不这么做会有什么问题，有没有更好的做法。同样的也认识到了很多人，同事中基本上都是佼佼者，技术能力以及技术判断力，对问题的思考，都让我完全刷新自己的认知。原来还能这么细节，为什么可以这么强。
说句玩笑话，强得有点让我绝望，但是更让人绝望的是，他们每一个都这么强，可能我学到头秃都学不到皮毛，还得好好努力。
工作以及思考
前面唠了几句家常，那下面简单说一下这段时间以来做了什么以及我的一些思考吧，也算是回顾了这一年。这一年我主要在做多租户以及单元化架构，我在里面主要负责的是存储层的实现，主要是在原生的存储层上想方设法套上一些我们的逻辑，目前存储层除了 RDS、Redis等场景存储外，还有其余十余种存储，比如一些 nosql、图数据库、强一致性KV存储等，还是有些挑战性的。
多租户系统
简介
相信多租户大家也很熟悉了，无非就是在一些特定的场景下需要做计算资源的隔离或者存储资源的隔离，一般来说会同时对计算资源和存储资源同时进行隔离，以达到满足不同租户间独立使用的需求。
什么情况下会需要多租户隔离的能力呢？简单举几个例子：
- 业务发展流量规模已经到达一定瓶颈。比如在业务起步阶段，单租户就能处理所有的数据，随着业务逐步发展，数据量增加后单租户性能和稳定性都会面临一定的挑战，此时可以引入多租户进行数据拆分，缓解单租户的压力。
- 隔离公共的中台服务以满足不同业务的场景。比如某些公共中台的服务同时供不同上游的业务调用，可能存在 tob、toc、tod 等场景，面对形态不一的业务，需要提供的服务质量也不一样，同时不同业务的量级差别较大，因此需要对不同的调用方进行流量隔离，避免业务间的相互影响，因此可以引入多租户解决该问题。
- 数据需要满足合规安全需求。比如有中台业务为多个上游提供服务时，不同的上游间理论上需要做好数据隔离，如果一个上游对应一个租户，要处理出现的非预期的跨租户数据访问等行为，同时需要有手段做好租户间数据的审计和管控。
简要设计
多租户其实核心的能力就是计算资源隔离和存储资源隔离，围绕不同的业务场景的关键问题都是按什么维度进行隔离以及如何隔离。一般来说会以集群维度划分租户，比如 clusterA 为 A 租户的服务，clusterB 为 B 租户的服务。
确定按照什么维度进行隔离后即可形成一套多租户配置，以此配置生成一套流量调度规则，依赖一些基础建设把流量调度到对应的集群上即可完成计算资源的隔离或存储资源的隔离。当然这只是能力建设，还有非常关键的容灾和稳定性建设。在一个流量的完整生命周期里，我可以观测到整个流转状态，如果出现不符合预期的流量访问行为，需要有相应的监控以及告警。容灾建设能力也类似，主要分为平台能力容灾以及业务容灾，前期需要进行一些混沌测试以及业务会进行一些线上的容灾演练。
计算层隔离
流量染色
对于引入多租户的服务，要将流量调度到不同的租户，首先要识别流量携带的标识，这些标识通常包括 AppID、UID、tenant 等信息，这些标识需要能够在流量全链路透传并且要保障标识是可信的，需要有加密、验签等行为保障票据不被伪造篡改，同时还需要有票据丢失观测和定位等响应能力的建设。一般来说在流量进入服务前需要完成流量的染色，大部分情况下流量标识会在网关层统一注入，当然也可以在其他点位注入，只要在调用多租户的服务前能正确地把流量染色，多租户能力就会把流量调度到对应租户的集群上。
流量动态路由
上一节的流量染色的效果已经可以达到把流量调度到对应的租户上，但是实际使用中，流量的调度规则是会变的，可能根据标识的不同，需要支持通过规则表达式的形式实现条件化调度，这一步依赖了类似于 mesh 的能力以及控制面的规则配置。简而言之，就是控制面配置了相应的流量规则，比如 UID1 -> A 集群，UID2 -> B 集群，随后把规则下发到 mesh proxy 或其他能实现流量调度的位置，比如可以通过一个网关插件来生效路由规则，根据请求中的 UID 去计算，实时注入流量标识。
动态路由可以实现的位置有很多，一般来说会在 loadbalance 层、gateway 层或者 rpc 层 去实现，当然也可以层层分类把流量均摊到不同的点位继续不同维度的路由。
存储层隔离
流量路由
上面计算层的隔离只涉及流量调度，存储层的隔离则需要配合一些代码改造，比如服务启动时会与对应的存储进行建联，此时如何识别出当前服务需要访问的是哪个租户？当前服务涉及到十个甚至百个租户的时候，怎么样改动代码量最少？最差的办法就是代码里写一套 if else 逻辑，通过判断一些租户配置，去访问对应的存储，这样能运行，但是每新增一个租户就得改代码，显然不可行。
最理想的办法是只需要进行一次代码改造，后续部署不同的租户时同时多租户平台的一些配置即可一键拉起新租户的服务。这个改起来也不难，无非是将代码改造变成配置能力，简单点在多租户平台维护一套租户与存储服务间 1 ：1的映射关系，服务启动时通过环境变量配置等信息，获取到对应的存储信息，建联的时候去访问对应的存储即可。思路是比较简单，实现起来会有较多问题，比如租户与存储间没有那么干净的一对一关系，有时候会混用，这个时候怎么解。再比如，业务运行时需要切租户，怎么切。再比如我需要对租户间数据的访问进行管控，怎么识别出当前流量是否可以访问该租户，是否有一些默认的策略对流量进行拦截或者擦除结果或者进行数据脱敏等等。
对于上面业务怎么切租户，需要有些简单的流程去保证。比如一些计算资源存储资源的准备就不多说了，在开始迁移流程后，需要设定迁移数据的比例、数据冲突处理策略等信息，然后会启动数据同步，将原有的数据迁移到新租户的存储上，数据迁移完成后会有数据一致性观测和校验，随后会启用双写放量，逐步灰度比例，然后启动双读放量，在这个流程中需要观测数据的一致性是否符合预期，随后在原服务上关闭读，关闭写，观测通过后流量全部迁移到新租户的存储上。简单的流程大体如下，但是其中还涉及到很多细节， 比如怎么实现双写，一边写失败了一边写成功了怎么处理等。
小结
上面简单理了一下多租户的一些能力和建设思路，比较粗糙。这里也不好展开，有机会再展开说说细节吧，太细的我也不会，毕竟我是个菜逼。
单元化架构
简介
单元化架构解决的是异地多活的典型解决方案，国内的大厂很多都早早就已经在建设单元化，比如阿里、腾讯等都已经经历过实践。
为什么需要单元化？总的来讲就是业务增长上来后，单个机房资源已经见底，无法再支撑业务的规模，此时就需要建设新机房，一般来说会先建设同城多机房，但是业务量再增大，数据库的连接会成为瓶颈，计算层的资源可以通过扩容拉起服务来支撑更大的 QPS，但是存储的写没有办法通过堆积机器来获取更多的连接数，连接在非单元化下最终会成为无法解决的问题。再者一个机房即使只是计算层也不能无限扩容，会有建筑、电力、政策等因素影响，因此在这种情况下，需要一个解决方案，而引入单元化则可以解决该问题。关于单元化架构的一些基本介绍可以看下别的文章，这里不展开。
单元化的基本理念是根据一定的维度对流量进行圈选，对于满足条件的流量，可以在一个单元完成闭环，也就是可以把对外提供服务进行单元拆分，不同的单元提供一样的服务，这样理论上就可以通过增加单元来弥补数据连接上的缺陷。当然这只是一个简单的思路，实际的实现上会有非常非常多的问题。比如服务可能没法拆分干净，比如存在中心服务，此时本地服务会存在跨单元访问的行为，数据同步怎么做，一个单元挂了怎么处理，怎么进行单元间切流，怎么做好容灾和观测等稳定性建设，每一个都是非常棘手的问题。
简要设计
这里不对细节做过多的描述，只对架构进行一些简单的梳理。主要从三个视角来看单元化做了什么，描述就不过多展开了。
从单元划分的视角来看
这里可能需要对名词进行一些解释，本地服务是指可以在独立单元完成闭环的的服务，中心服务是指一些公共用服务，无法在某一单元闭环，需要部署在中心单元，其他本地单元可以跨单元访问中心服务。
下图简单展示了单元间的工作，在进行流量划分后，对于本地服务可以在本单元完成读写，不同的本地服务之间完成数据的双向同步。中心服务只能在中心单元进行写，可以在本地单元部署中心服务本地只读副本，由中心单元的中心服务进行单向的数据同步。
从机房的视角
机房的视角对比单元视角更具体了一些，可以看到不同的机房可以部署本地服务，但是中心服务可写依然只存在于一点，在中心单元内的其他机房可以部署中心服务，在本机房只读，需要跨机房写。同时，在本地单元，可以部署本地服务，本地服务的数据进行双向全量数据同步，中心服务需要在本地单元部署中心服务本地只读副本，由中心单元进行单向数据同步。
从流量的视角
对于一个流量，可能会同时存在访问中心服务和本地服务的情况，因此会在涉及到流量的转发，同时可能会有些走错单元的异常流量，此时需要路由该流量到正确的单元或者对流量进行重定向。
单元化相关的知识非常多，具体涉及到不同业务的细节也有所差别，这里不展开讨论了。
小结
以上就是我现在所在进行的单元化架构的一些事情大致的框架和脉络，这里理得比较简单，基本不涉及太多细节，我有幸完整地参与了具体方案设计和最终落地整个过程。目前的接入规模大概有几千个服务，上万个存储和MQ，规模还是比较大。昨天看到一个服务流量达到了 700万 QPS，这种流量出事故分分钟就得喜提大礼包。
个人思考
我的不足
从现在回看，我这一年有很多做得不好的事情。
- 不够积极主动。其实这一年我过得很糟糕，我对自己的表现相当不满意。首先是前期适应阶段，非常消极，一来是突然换到一个压力非常大的环境，一下子适应不过来，二来是自己没认真对待手上的事情，心里还是不够重视，最终导致的我的适应和融入没达到比较好的状态。
- 没有持续学习。由于问题一，导致个人状态不是很稳，而且有些懈怠，工作上和个人提升上都没有继续投入额外的精力，有空就想着躺平刷刷手机，越这样逃避越不会，形成一个负反馈。
- 办事效率不高。这个可能就是纯个人能力的问题了，做事情速度不快，经常延期而且质量不高...
- 不会时间管理。时间管理或者说精力管理，我对自己的每一段时间没有清楚的规划，做事情没有紧迫感，做到哪算哪，经常导致的问题就是做不完，而且也没有往外反馈，做事情没有优先级，不会识别关键问题，容易在次要问题上浪费时间。
- 沟通效率不高。很多时候言不达意，比如一个问题想去问相关同事，但是表达的不是很清晰，同事误解或者直接听不懂我在讲啥，二脸懵逼有点尴尬...
我的优点
- 还算有点毅力。虽然比较菜，但是也能熬，最终也是在一片悲观的情绪下熬了下来。
- 其他的想不到了...
未来的 2024
好吧，唠唠叨叨了这么多，以上就是我这一年的工作上的经历和思考了。希望 2024 年目标更清晰，更有动力去追求自己想要的。希望自己能看清前路，不要被眼前的迷雾笼罩。
现在大家都追求躺平，可是又真的有几个人又躺平的资本。每天都裹挟在这种情绪中，工作与生活均不能一心一意，最终两头不到岸，终是一场空。最怕，最怕年轻的时候做错了选择，走错了路。
希望 2024 年大家都身体健康，工作顺利！
