项目的迭代升级
只是写自己接手的项目迭代过程，单纯的记录。 这个项目的目的是为了控制电话营销的投诉率，前前后后搞了也有小一年了，大的迭代基本上有三次，这篇文章主要就是记录一下迭代的过程以及自己的想法。 项目伊始 需求：获取 SIP 协议中的手机号信息，去特定的网站查询该手机号在不在投诉黑名单中，并将命中的手机号缓存。 开始的需求很简单，但是本身并不是这个行业的，对 SIP 协议也不是很了解，看了看资料用了最简单的方法实现了他的需求。 实现后的流程如下： 遇到的问题： 由于对 SIP 不了解，所以代码只是单纯的对 SIP 协议做转发，导致中间层只能和前端在同一台机子上。 由于他的前端是破解版本，所以导致系统版本特别低（Centos5）都已经被弃用了，所以最开始设想的中间层运行在 docker 中也随之破灭。 以上问题间接的导致了我需要在他出问题的时候排查和我无关的错误，极大的浪费了个人时间。 第二阶段 由于运行期间间接产生的数据，如自己被投诉的号码，以及明确不愿意在接听到类似电话的人，以及低素质的人。 所以他有了自己的私有数据，但是项目的第一阶段并没有这部分的功能，于是有了第二期的需求。 需求如下： 可以上传自己的黑名单。 可以上传自己的白名单。 可以设定拦截时间（请求过的数据在规定的时间不允许第二次请求）。 第二期的需求本质就是添加自己的黑名单数据，对 SIP 这快的逻辑改动并不大，所以第二期从简实现。 实现后流程如下： 可以看出私有数据服务被单独放到了一台机子，以 RESTful API 的形式给原中间层提供数据拦截状态。 所以阶段二对中间层还是有稍微细小的改动的，但是并没有解决阶段一导致的问题。 阶段二中的片段，由于他的需求一直在增加，导致阶段二变的异常复杂，以下是架构图： 由于配置的繁琐，以及加入了一些新的脱敏数据，出现了一些新的需求，如，满足特定规则后才转发。 介于阶段一，二的复杂程度实在不想基于原先的设计思想继续追加了，所以重新设计了现有的架构。 新设计的架构解决了原先的问题。 必须部署在一台机子上。 由于不完善的 SIP 实现导致处理流程异常耗时（前端的 3 秒 Timeout，3次重试机制）。 无限的堆叠原有服务导致项目结构异常复杂，难以维护。 中间层和和前端必须部署在一起，任何问题都需要登录机器查看，排查问题麻烦（前端属于破解版，系统又是 CentOS 5）。 以下是第三阶段的架构图： 以上架构的优势： 完全基于 K8S 部署，横向扩容，高可用。 我负责的模块完全独立于他的前后端，再也不需要因为前后端的机子出现问题，导致的被迫介入。 规则可配，插件可扩展，基本满足后续的需求。 前后端可 一对多，多对多，多对一，SIP 转发层基本实现了 SIP 协议的真正转发。 第四阶段（规划） 基于 TensorFlow 替换规则的手动设置！！！！ 以上 以上算是对接手这个项目的总结，在项目期间也确实接触了好多新的知识。 如 GRPC 并不能在 K8S Service 层做到负载均衡，需要 Service Mesh 的介入（Linkerd2 等）。...