1，说明

互联网产品，最常见的一个功能就是红点。下面举一个简单需求场景：

• 某个产品很多订阅者（即用户），后台维护有很多内容。
• 后台新增或编辑某个内容，所有订阅者打开这个页面都会看到红点。
• 某个订阅者点击红点后红点消失，其他订阅者没有点击过还会有红点。
• 后台再次新增内容，所有订阅者都会再次看到红点。

现在我们做一个简单的红点微服务。

2，这个需求怎么实现

2.1 数据库设计

2.1.1 外部表引用说明：用户表和内容表

这俩表不属于红点微服务，简单起见就给出最小可行性定义：

create table user (id int unsigned not null AUTO_INCREMENT default 0 comment '主键id';status tinyint unsigned not null default 1 comment '数据状态：1正常/0软删除标示';update_time datetime not null default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP comment '更新时间',create_time datetime not null default CURRENT_TIMESTAMP comment '创建时间',PRIMARY KEY (`id`),
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';create table content (id int unsigned not null AUTO_INCREMENT default 0 comment '主键id';status tinyint unsigned not null default 1 comment '数据状态：1正常/0软删除标示';update_time datetime not null default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP comment '更新时间',create_time datetime not null default CURRENT_TIMESTAMP comment '创建时间',PRIMARY KEY (`id`),
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='内容表';

2.1.2 微服务表设计

只需要定义一个用户阅读记录表，记录下阅读某个内容的时间。

create table user_read_record (id int unsigned not null AUTO_INCREMENT default 0 comment '主键id';user_id int unsigned not null default 0 comment '用户uid';content_id int unsigned not null default 0 comment '内容id';last_read_time datetime not null default CURRENT_TIMESTAMP comment '最后阅读时间',status tinyint unsigned not null default 1 comment '数据状态：1正常/0软删除标示';update_time datetime not null default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP comment '更新时间',create_time datetime not null default CURRENT_TIMESTAMP comment '创建时间',PRIMARY KEY (`id`),index idx_uid (`user_id`),index idx_cid (`content_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户阅读内容记录表';

2.2 接口设计

红点微服务应当提供这几个能力：查询某个用户对某个内容是否应该看到红点，用户点击红点使其消失，编辑或新增内容用户重新看到红点。

2.2.1 查询红点

message GetRedDotRequest {int user_id=1;// 用户uidint content_id=2;// 内容id
};message GetRedDotResponse {int need_show=1;  // 是否应该展示红点：1是/0不是
}service RedDot {rpc GetRedDot(GetRedDotRequest) returns(GetRedDotResponse);  // 查询用户最后阅读时间，以及内容最新更新时间，对比后返回是和否应该展示红点
}

2.2.2 消除红点

message ClickRedDotRequest {int user_id=1;// 用户uidint content_id=2;// 内容id
};message ClickRedDotResponse {
}service RedDot {rpc ClickRedDot(ClickRedDotRequest) returns(ClickRedDotResponse);  // 插入或更新一下用户阅读内容记录表
}

2.2.3 重置红点

message ResetRedDotRequest {int content_id=1;// 内容id
};message ResetRedDotResponse {
}service RedDot {rpc ResetRedDot(ResetRedDotRequest) returns(ResetRedDotResponse);  // 调用内容微服务更新内容的updatetime
}

3，这样做有什么问题

按照上面的实现，一个简单的内容更新提醒微服务就完成了。

but，红点服务和内容服务，紧密耦合，有两个问题：

• 红点微服务需要调用内容服务（比如查询/更新内容的更新时间）。
• 通用性不强，如果想对别的什么非内容实体也添加红点逻辑或着弹框逻辑，就不适用了。

3.1 纠正

红点服务应当属于非业务相关的基础功能服务，应当与业务服务解藕，并进一步抽象提升通用能力。

3.2 数据库设计

红点微服务需要建立两个表：触发器事件用来记录某个抽象实体（内容/通知/弹框/浮层）最新的抽象事件触发记录，用户行为事件用来记录用户对某个触发器的最后一次行为记录（比如点击/阅读/展示）。

create table trigger_event (id int unsigned not null AUTO_INCREMENT default 0 comment '主键id';obj_type tinyint unsigned not null default 0 comment '实体对象类型：1内容，2通知，3，弹框，...';obj_id int unsigned not null default 0 comment '实体对象id';event_time datetime not null default CURRENT_TIMESTAMP comment '触发器事件发生时间',status tinyint unsigned not null default 1 comment '数据状态：1正常/0软删除标示';update_time datetime not null default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP comment '更新时间',create_time datetime not null default CURRENT_TIMESTAMP comment '创建时间',PRIMARY KEY (`id`),index idx_objtype_objid (`obj_type`, `obj_id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='触发器事件记录表';create table user_event (id int unsigned not null AUTO_INCREMENT default 0 comment '主键id';user_id int unsigned not null default 0 comment '用户uid';trigger_id int unsigned not null default 0 comment '触发器事件id';event_time datetime not null default CURRENT_TIMESTAMP comment '用户行为事件发生时间',status tinyint unsigned not null default 1 comment '数据状态：1正常/0软删除标示';update_time datetime not null default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP comment '更新时间',create_time datetime not null default CURRENT_TIMESTAMP comment '创建时间',PRIMARY KEY (`id`),index idx_uid (`user_id`),index idx_trigger_id (`trigger_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户行为事件记录表';

3.3 接口设计 

3.3.1 事件查询

message GetEventStatusRequest {int user_id=1;// 用户uidint obj_type=2;// 实体对象类型int obj_id=3;  // 实体对象id
};message GetEventStatusResponse {int has_happened=1;  // 用户行为是否已经发生过service Event {rpc GetEventStatus(GetEventStatusRequest) returns(GetEventStatusResponse);   // 查询触发器，根据触发器id查询用户行为，对比两者的事件发生时间
}

3.3.2 事件发生

message EventHappendRequest {int user_id=1;int obj_type=2;int obj_id=3;
};message EventHappendResponse {
}service Event {rpc EventHappend(EventHappendRequest) returns(EventHappendResponse);  // 查询触发器，根据uid和触发器id，更新或插入用户行为事件记录
}

3.3.3 触发器重置

message ResetTriggerRequest {int obj_type=1;int obj_id=2;
};message ResetTriggerResponse {
}service Event {rpc ResetTrigger(ResetTriggerRequest) returns(ResetTriggerResponse);  // 插入或更新触发器事件记录表
}

4. 结语

本质上，这是一个yes/no业务需求，常规有两种思路：有/没有分别对应yes/no，大于/小于分别对应yes/no。这两种思路属于经验之谈，难道一切内卷的尽头都是经验吗？

微服务应当尽可能抽象，且在实际项目中，应当划分业务层和基础层微服务。基础层就如本次提到的用户行为/触发器功能，可以用于红点，弹框，浮层，push等各种应用场景的实现。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！