H项目心路历程记 (二)
(书接上文)
前文已经吐槽了产品设计以及中间件上的相关问题。接下来讨论一下技术上的一些问题。
关于配置
对于一个Spring的应用来说，应用配置怎么存取其实并不能说是一个技术问题。更应该算是设计或是架构问题。哪些配置应该进入配置文件，通过微服务配置中心(例如Nacos, Apollo，Kubernetes ConfigMap等)来进行在线配置，哪些配置应该通过其他方式来配置，亦或者哪些配置项目看似是配置项其实本质上就是常量。实际上截止现在H项目的确在有些微服务上是完全没有厘清三者之间的区别，以及界限。以至于现在堆积在配置文件中的内容实在太多。多个运行环境需要统一维护的难度实在太大。
对于配置来说，理想的状态应该是下面这样的。
通过微服务配置中心来影响Spring的配置文件来实现动态配置的方案，通常会伴随Spring容器的重启(有些情况下甚至需要整个Docker容器)，所以存在这里的配置项应该是随着运行环境改变才会需要改动的配置。例如:
- 外部系统的链接信息(比如MySQL， Redis的连接信息)
- 外部系统的认证凭证(数据库用户密码，第三方系统的密钥等)
- 因为运行环境不同导致的不同变量 (例如消息队列的Topic,Group需要根据运行环境使用不同的名称)
通过数据库或是Redis存储的配置信息，这类配置主要是应该以业务级别的配置，可以通过页面进行修改，瞬间或是几分钟内生效，且不会造成微服务重启(无论是Spring或是Docker容器的重启)。对于这类配置有几个问题还是需要注意的。
- 配置是否需要集中管理，每个微服务，都有自己独特的业务配置，这些业务配置是否需要集中到一个微服务统一管理，还是分散到各自的微服务进行单独管理。
- 全局性统一管理的业务配置对外保留接口应该利用缓存有效的减少数据库访问的频次。甚至可以只使用内存而不是Redis来缓存这部分内容。如果使用内存的话则需要考虑失效时效和重新装载的机制。
无效配置，实际上很多配置说是可以修改，其实自从开始使用的那天开始就没有修改过。比如用来做分布式锁的键值。这部分需要梳理出来直接以常量的形式做在代码里。
数据清理以及归档
对于电商行业的零售业务来说每天产生的单据比如订单少做200，300条，多的是上千条。加上明细数据。几个月以后这些数据就会给MySQL的库表增加检索压力。整个H项目在这块是相当薄弱的。只依靠云平台的能力，对一些不需要留档的数据进行清理。远远没有能定期归档。
对于数据清理这块大致可以分为这几类
- 定期可以无脑物理删除的数据，比如一些日志类数据。
- 定期直接归档的数据，归档后即可清理的数据。
- 业务必须处理完成后才能归档并清理的数据。例如订单数据等。
对于数据归档的时候，还需要考虑一些相关联单据数据一并归档。比如订单归档时，同时需要归档相关联的退换货单，发货单，以及操作日志等等。 归档格式基本上就是考虑单条数据以JSON格式存储，然后一个时间段的数据做成压缩包存储在OSS上，然后提供给客户下载。
而对于归档数据的检索功能，客户选择需要归档的数据，我们可以将归档的数据(每个压缩包内的所有数据)导入到一个主数据库以外的，临时文档数据库(例如MongoDB)，然后针对这个临时的文档数据库进行检索。当然提供的检索项目也会远少于热数据的检索项目。这个临时文档数据库基本上保持一两天数据，定期就全部回收。
未完待续