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}嵌套消息体
待续...
加载中,请稍侯......
网友评论