背景

笔者最近在维护一个基于地图数据的服务，为了给用户提供更好的服务，数据的更新频次会逐步增加。数据格式本身是基于protobuf的，鉴于其良好的格式兼容性，大多数升级中服务本身是不需要调整的。从服务角度来说，数据热更新呼之欲出。本文探讨一种解决思路，并总结下其中发现的问题。

技术栈

Java + SpringBoot

总体思路

1. 数据API（暂且叫DataAPI），定义出数据内容访问接口，从而将API与具体的实现对象分离，当然有时候其中会有ADataAPI，BDataAPI；
2. 数据API工厂（暂且叫DataAPIFactory），其中包含所有版本的数据API实例，但每次仅从中获取最新实例，历史的实例在不需要的时候销毁掉；（显然这里是问题的关键）
3. 上层服务依赖DataAPIFactory，作为统一入口；

思路落地

1. DataAPI，将数据本身依赖的内容当做一个完整的模组，其中包含依赖等内容，想到这里，这也是个小的应用上下文；
2. DataAPIFactory，其中包含多个DataAPI实现，这也是个小的应用上下文；
3. 咱们的整个服务相关的实例在一个更大的上下文中，接下来探讨下这些上下文的关系。显然，DataAPIFactory由于被上层服务直接依赖，因此与整个服务的应用上下文是一致的，于是整个服务就划分为2个应用上下文，DataAPI上下文和DataAPIFactory上下文。
4. 在SpringBoot中，以编程的方式将DataAPI作为一个独立的application启动，并将ApplicationContext实例保存在DataAPIFactory实例中便完成了上下文嵌套，销毁DataAPI实例时，直接关闭对应的ApplicationContext并删除DataAPIFactory中的实例即可；

其他问题

DataAPI上下文中metrics暴露

1. metrics注册
   在DataAPIFactory上下文初始化完成后，发布特定的ApplicationEvent，event对象中包含DataAPIFactory上下文的MeterRegistry，DataAPI上下文中的实例监听事件并注册；
2. metrics销毁
   由于DataAPI上下文可能有多个版本，MeterRegistry中meter也需要有tag区分，这样在特定的DataAPI上下文销毁时，一并销毁掉对应的meter;

版本的一致性

比如在处理一次request的整个过程中，其所使用的DataAPI对象都来自某个特定版本。比如笔者的定义是，接收request时容器中的最新版本。其他选项，如处理request时的最新版本（比如一次请求包含500条数据，分为5批处理，第0批和第4批使用的DataAPI版本可能是不同的）。此处仅供参考，具体咋选择得看业务场景。

DataAPI上下文的释放

释放时机

不再被使用

如何确定

笔者的实现是版本内部增加一把读写锁，默认都是读锁，如果该版本不是最新版本，当读锁数量为0时进行释放(笔者偷懒，直接加写锁，如果成功则进行释放）。这也意味着每次request开始前，获得锁，处理完成后释放锁。具体是在DataAPIFactory内部开启计划任务完成释放。

更新触发

这个就是一个消息的问题，可以是Apollo，或者消息队列。关键是要保证集群环境下消息的可靠送达。

潜在约束

1. DataAPI实例不能太大
   假设你在k8s容器中运行服务，当版本切换时，最少有2个版本同时存在，如果实例内部提前预热缓存，则意味着容器需要分配2倍内存才能度过高峰期。然而，当旧实例在几分钟被销毁后，腾空的内存就是资源浪费，白白增加成本。

2. 版本更新不能太频繁
   原因与太大有相似性，前者是影响乘数，这里影响被乘数，总之就是投资收益的权衡。

小结

本文介绍了基于SpringBoot的服务数据热更新思路，落地细节，后续问题以及潜在约束，作为一种热更新方案供各位看官参考，感谢阅读。