计算速度提升2.5倍，ATP减小4.9倍
|
现在接口的“雏形”已经出现了，到这里我们实现了消息管理平台最基本的功能：发消息 我们先不管内部的实现是如何，假设我们已经适配好调通好对应的API了，现在我们的接口在发消息层面上已经有充分必要的条件了：只要你传入接收者和发送内容，我就可以给你发消息。 但我们对外称可是一个平台啊，怎么能搞得像是只封装了几个方法似的，平台就该有平台的样子。
我举个日常最最最基本的功能：有人调用了我的接口发了条短信，这条短信的文案是一条内容为验证码类型，他问我这条短信到底下发到用户手上了没有。 现在还有个场景，不同的文案发给不同的人怎么办?有的人就说，这不已经实现了吗?直接调用上面的接口就完事了啊。你又不是不能重复调用，比如说：
确实如此，本来就可以这样做的。但不够好 举个真实的场景：现在有一个主播开播了，得发送一条消息告诉订阅该主播的人赶紧去看。为了提高该条通知的效果 ，在文案上我们是这样设计的：{用户昵称}，你订阅的主播三歪已经开播了，赶紧去看吧! 这种消息我们肯定是要求实时性的(假设推送消息的速度太慢了，等到用户收到消息了，主播都下播了，那用户不得锤死你?) 画外音：显然这种情况属于不同的文案发给不同的人 这种消息在业务层是怎么做的呢?可能是扫DB表，遍历出订阅该主播的粉丝，然后给他们推送消息。 那现在我们只能每扫出一个订阅该主播的粉丝，就得调用send()接口发送消息。如果该主播有500W的粉丝，那就得调用500W次send接口，这不是很可怕?这调用次数，这网络开销...
于是乎，我们得提供一个“批量”接口，可以让调用方一次传入不同文案所携带不同的人。那怎么做呢?也很简单，实际上就是上面接口再封装一层，让调用方能“批量”传进来就好了。所以代码可以是这样的： 这样实现好像也不是不可以，反正每个接口都挺清晰的，要发什么类型的消息，你调用哪个接口就好了。 假设我们定义了如上的接口，现在我们要发消息了，我们会有以下的场景：
假如你是新手，你可能会想：这简单，我每种类型分开两个接口，分别是单发和批量接口 嗯，从规模上来看，这真的是一个超级大的项目，接近 700 万行的规模。所以，我第一次看到的时候，也不知道从哪里下手，于是我便想着是不是从包(目录)结构能解决这个问题。 PS：Coca 当前只支持单体分析，考虑有多模块和微服务系统的存在，我会在未来必要的时候，添加对应的实现。 按目录分析 简单来说就是，我们可以按目录执行 cloc，然后汇总结构即可。
所以，进一步地我们就可以执行 coca cloc . --by-directory，得到一个 CSV 数据，根据自己的需要进行编辑： （编辑：盐城站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
