1 编写目的

1.1术语与定义

(资料图)

1.2引用标准和规范

1.3参考资料

2系统总体框架

2.1设计目标

2.2总体技术路线

2.3架构概览

2.3.1架构总览图

2.3.2功能一览图

3功能展示

1.1编写目的

体验APP通讯,实现聊天功能以及聊天项目的设计思路，选用高性能传输非阻塞的netty框架进行开发,秒级响应

接入websocket技术应用聊天消息的已读未读，还有聊天消息的测试与联调

Netty心跳检测机制

云服务器构建项目，引入CICD，以及Devops构建,接入监控体系，一秒钟定位异常

针对登陆不同场景，结合桥接模式进行项目改造，代码review

1.2 术语与定义

Netty：Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

NLP:自然语言处理(NLP，Natural Language Processing) 是研究人与计算机交互的语言问题的一门学科。按照技术实现难度的不同，这类系统可以分成简单匹配式、模糊匹配式和段落理解式三种类型。

推荐系统：帮助用户找到想要的商品

1.3 引用标准和规范

1.阿里巴巴开发规范

2.接口使用规范

3.开发过程规范

4.异常管理规范

1.4参考资料

《阿里巴巴开发规范》--阿里官方Java代码规范标准

Netty实战

2系统总体框架

2.1设计目标

目标：旨在模拟微信APP体验实时通讯理念,秒级响应用户请求，由前后端统一处理消息，模拟从登陆/注册->用户个人信息维护->交友聊天等主流程。

玩转云服务器，从容面对IM聊天业务，延伸场景:自住回复机器人等。

技术扩展

1.登陆：用户登陆保存用户信息到缓存，以便用户第二次打开app可实现不输入密码登陆，并对密码进行MD5加密。

2.登陆时生成全局唯一id，根据id的调用谷歌的com.google.zxing.BarcodeFormat生成个人二维码并进行保存，当加好友，扫一扫时可进行唯一id判断来添加维护好友关系。

3.登陆后可进行个人信息维护，角色管理，查看数据，页面配置，黑名单管理等，朋友圈既是一个社区型评论功能化系统，可进行功能复用。

4.站在业务角度分析一次聊天事件的流程

5.当出现用户群后，根据DSSM模型分析用户行为。

6.Netty源码解读

7.云服务项目部署

2.2总体技术路线

2.3系统架构

1、以业务分析为输入，以总体的企业应用架构为原则，按着不同区域划分，由于本次基础以聊天业务为入口，侧重点不同，在此不做分析。

2、业务可配置性实时变化，引入apollo

3、定位用户ip，上传用户真实ip定位用户位置，引入iP2region，举例说明：即为了用户的隐私安全，定位用户的位置，第一时间定位报警用户行为的位置。

4、随着公司的业务的不断发展，当基础的系统逐步成型以后。业务运营就需要开始做⽤户的拉新和促活,从⽽保障 DUA 的增速以及最终 ROI 转换

3.功能展示

4.延伸问题：DSSM(Deep Structured Semantic Models)

也叫深度语义匹配模型，最早是微软发表的一篇应用于NLP领域中计算语义相似度任务的文章。深度语义匹配模型当用户量达到一定群体，分析用户行为，精准推送用户广告，喜好分析等成了我们不可或缺的一个话题。通过打标签，关联分组，给不同数据源的关联，这里涉及到两种建模：一种是自然兴趣建模，根据用户操作终端行为获得user-item关联，给不同的数据源打标获得item-tag关联，最后将上面两种关联进行join操作得到user-tag的关联实现给用户打上兴趣标签，这里相当于是从标签维度为广告主推荐人群；另一种就是商业兴趣建模，在自然兴趣建模的基础上，从广告维度为广告主推荐人群，那么就需要目前大火的DSSM双塔模型了。

那么平时最多的用户喜好数据来源哪里？

1.输入法

输入搜素引擎：根据用户的每日输入词都可推算你的历史组词，当然可分析此行为找出关联性最多的词组进行特征分析，将用户标签、用户属性、项目属性、用户操作行为、聚类算法、基于用户、基于项目、基于内容等混合推荐。

2.点击日志

短视频平台/海量曝光日志，根据用户多次点击的同tag类视频进行爱好分析，比如滑雪视频，你点击一次，首页就会出现多篇推荐，然后在产生一次点击，就会源源不断的进行推荐

其实第一次看这篇论文的时候，有点云里雾里，我不得不再次进行阅读，但结合推荐系统来看更容理解，推荐算法大致可以分为以下几类

基于流行度的算法

协同过滤算法

基于内容的算法

基于模型的算法

混合算法

在次就不展开讨论，只个人结合资料查阅，而DSSM更像是在基于模型的基础上，完成推荐任务，跟分治算法，回溯算法等不谋而合

5.朋友圈设计：点赞+评论

结合社区内容设计，将朋友圈视为新的一个tab展示，并将社区属性的评论与点赞进行集成展示。

对于点赞和评论的博文可参考个人公众号文章

点赞功能设计

https://mp.weixin.qq.com/s?__biz=Mzg2ODA3NjA1MA==&mid=2247484981&idx=1&sn=569bc3d748026dd8c2814e33a3e916d0&chksm=ceb09948f9c7105e203e09e4bb1d30de17bba55a68f7d4df71ccb55c8e34871e2b02b7a1f9ed&token=889485161&lang=zh_CN#rd

本次着重介绍评论系统

1.使用递归开发评论功能，并改造为极简循环调用，防止递归层次太深

大多数的评论功能可

1、单一消息体：分为主评论，然后层级下逐一排列回复，消息体之间一对多

2、嵌套消息体：即分为主评论，层级以下可互相回复评论，但展示层级是在同为第二层(着重解释)

3、套娃消息体：即可对每条评论进行回复，除主消息体外，都视为第二层，且可对第二层消息体进行回复，每次回复视为一层，消息体为一对多中的多又是一对多~

单一消息体

数据库设计：

CREATE TABLE `comment_msg` (  `id` varchar(64) NOT NULL,  `send_user_id` varchar(64) NOT NULL,  `accept_user_id` varchar(64) NOT NULL,  `msg` varchar(255) NOT NULL,  `sign_flag` int(1) NOT NULL COMMENT "消息是否签收状态\r\n1：签收\r\n0：未签收\r\n",  `create_time` datetime NOT NULL COMMENT "发送请求的事件",  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

即展示所有主题评论下的所有评论即可

select * from comment_msg where send_user_id=#{send_user_id}

嵌套消息体

待续...