软件中间层魔法
计算机领域有句名言
计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决
最近在工作中我就通过增加中间层来解决了看似需要换方案或推倒重来的问题。
监控告警
因为前司的监控告警方案是我拟定并实现的，用的是Prometheus生态那一套，基本上是以下思路
- prometheus：数据收集
- alertmanager：接收告警
- webhook：告警通道分发
- exporter：指标采集
- grafana：可视化
想的很美好，遇到的第一个问题可把我愣住了：
- 公司近期做降本增效，这些服务的虚拟机申请不给批；
- 公司有人在用prometheus,但都是历史原因自已用，没专人维护
- 因为开源时序数据库性能不能满足需求，公司开发了独立的数据采集方案：tracer(不同于prometheus的exporter）
- 团队监控业务与公司数据采集服务不在同一网络
根据与运维部门的沟通，我得到的结果：
- 你不能自己玩prometheus那一套，我们不会给资源的
- 你可以用公司的数据采集方案，但是需要你自己将监控指标数据转成tracer的格式
- 你可以等待运维部门出兼容方案，因为人员有限，这一季度调研，下季度落地
此处必须引用老玩家C的一条微博
什么是工程思维？——永远以资源有限、条件不足为前提，去实现现实世界的目标。
这不正是资源有限，条件不足的现实场景吗？prometheus这一套体系我是熟悉的，必须接入公司的tracer，加一个中间层？
- prometheus配置remote write到数据转换服务S
- 服务S将prometheus数据转换成tracer格式，并上传到公司的数据采集服务
- 由于接入公司监控系统，所以很自然可以借力公司的告警系统，不必自己写webhook了
所以你看，通过使用中间层服务S，我使用了自己熟悉的技术，又可以借力公司现有的能力，其实问题并没有想像中那么难，不是吗？
网关配置
之前吐槽过目前我正在使用的网关：krakend,原因就在于它的配置复杂且繁琐，不支持正则，模板难用，以至于随着组内微服务规模的扩张，配置成了一个不小的负担，因为团队只有我懂，只有我会配。我想换网关，以解决配置繁琐的问题，但由于手头业务重，暂时也抽不出大量时间换其它网关，况且换也是有成本和风险的，痛定思痛，我整理了一下所谓的“痛点”问题：
- URI参数配置过长，且有顺序要求；
- URI的不同Method需要分别配置；
针对这两个问题，其实很容易想到简化配置的方案，在配置文件和网关真正载入配置中间加一个中间层，将简化的配置转化成网关的繁杂配置，于是问题就变成写正则了
- 将
{param1}/{param2}写法统一成{param}/{param}，{param}只是作为占位符 - Method支持多个同时配置，如
POST,GET,PUT - 支持连续参数的简化语法，如
{param@num}，num为3，则最后转换成{param1}/{param2}/{param3}的形式
而且兼容新老写法，于是配置不再是一个令人头疼的问题，而且我发现这种相对严格的配置方式其实挺好的，至少是明确的，如果使用正则，很容易会将内部不应暴露出的资源暴露出去。
这两件事情若放在以前，我大概率会使用推倒换方案的路数，但是现如今资源有限，要解决从0到1的问题，还要兼顾历史，我认为加中间层这个思路非常合适当下，既增加了灵活性，又保留了换方案的可能性，而且团队借力后，能更专注于核心业务，这或许就是成长吧。道理，都懂，只是，这一次从实践中第一次较为深刻的理解了，我相信，这对我之后的工作大有裨益。