简历项目总结
自我介绍-吟唱
面试官您好，我叫陈立伟
本科毕业于华中科技大学软件学院软件工程专业
研究生就读于华中科技大学计算机学院计算机技术专业，攻读专业型硕士学位
今年暑期在联想上海研究院作为Java开发工程师进行实习，主要负责toB项目中后端服务的定制开发
所谓的定制就是在团队内部开发的公共组件标准品的基础上进行二次开发，满足客户的业务需求
除了后端开发工作外，我还负责了该项目所使用的离线k8s集群的部署、运维工作
在实习的前期初步完成了两个业务点位的开发任务后，该项目也已经部署到了企业现场
后期与负责视觉算法开发的同事一起调研并解决了企业现场的视频流延迟卡顿问题
简历上的第二个项目是我今年年初为了学习微服务架构下的项目开发，基于Spring Cloud搭建了一个简单的优惠券计算平台
最后一个项目就是我本科的毕业设计，利用TensorFlow构建了一个CTR(点击率)预估推荐模型，前后端部分利用Spring Boot+ThymeLeaf+Vue搭建了一个电影评分与推荐平台，实现了一个简单推荐系统的工程落地
实习项目总结
分布式营销优惠计算平台
简单介绍一下这个项目
在电商场景下，营销优惠是平台促进销量不可或缺的功能，这个项目搭建了一个极简版的优惠券计算系统，利用了Spring Cloud提供的各种组件搭建微服务架构
整个项目划分为四个模块，分别是优惠券模板服务、优惠计算服务、用户服务、API网关
优惠卷模板服务和优惠计算服务是项目的基础服务，而用户服务是对用户开放的接口，它依赖于这两个基础服务完成业务逻辑，API网关作为所有微服务的网关，主要用于内部服务治理负责请求转发与过滤
-
优惠券模板服务抽象出了具体优惠券的消费规则
-
优惠计算服务专门负责订单优惠券计算，这个服务几乎不与数据库有交互，所以可以抽出该模块做密集型计算服务
-
用户服务就是暴露给外部用户使用的接口，其业务场景包括用户领券、订单价格试算、下单核销等
-
微服务网关是架设在外部网关(Nginx)和内部微服务集群之间的桥梁，主要提供基础的限流功能和路由转发功能
为什么要使用微服务/使用微服务的好处有什么
微服务将一个大型应用拆分成了粒度更细且边界清晰的各个服务模块，每个微服务模块都能被独立测试、独立部署，可以快速上线
微服务架构的好处个人认为有以下几点:
-
快速迭代+快速回滚+降低协作成本
由于微服务模块通常粒度较细且可独立部署，微服务团队可以快速迭代微服务模块，即使遇到线上BUG也可快速回滚，且不影响其他微服务的正常发布和使用
单体应用的代码库、数据库都是整个项目组共享的，开发过程需要负责各个功能的小组耗费大量沟通成本，而微服务团队是小规模的，独享代码库、数据库、编译打包流程，降低了组内组外的沟通协作成本
-
资源利用率提高
应用被拆分后，就可以将资源更好地倾斜到压力更大的服务上，实现差异化的资源利用：比如计算服务不怎么需要网络IO资源而对CPU资源需求较大，可以将计算服务放在多核服务器上；而用户服务是对外暴露的接口，网络负载压力较大，可以分配到带宽高、稳定的实例上
-
高可用(最核心的优点)
高可用是微服务架构的最大特点，每个微服务模块都是个小型微服务实例集群，可以实时调整实例数量，流量高峰时能够动态地分配计算资源，对边缘服务进行降级，降低核心服务的压力。
缺点也很明显: 微服务之间要利用各种组件和中间件完成分布式架构下的数据一致性、容错、服务治理等问题，基础成本比较高
这个项目里你遇到的困难以及你是怎么解决的？
用到Sentinel时，每次重启Sentinel后，通过Sentinel-dashboard添加的限流规则就会丢失，又得自己手动添加，很麻烦
于是想把这部分规则自动同步到Nacos配置中心里，由Nacos持久化，Sentinel启动时从Nacos拉取即可
百度看了一下CSDN上别人的做法，然后去查阅Sentinel的Wiki，发现官方在Sentinel-dashboard的源码里的测试部分提供了基于Nacos的规则推送和拉取的示例，将这些原来在测试包下的类复制到dashboard.rule软件包下，然后将dashboard.controller包下负责发布和更新流控规则的FlowControllerV2用到的相关Bean改成Nacos推送和拉取的类。最后找到dashboard前端部分的sidebar.html中增加一个指向流控规则设置页面的入口，该页面由FlowControllerV2负责处理，这样添加、修改规则时会自动同步到Nacos Config，重启时也会从Nacos那拉取限流规则
Maven重新打包后即可使用新的规则可持久化Sentinel
各个微服务模块里导入sentinel-datasource-nacos依赖，在配置文件(或者Nacos配置中心的微服务启动配置中)中的sentinel配置项下配置Nacos数据源，指定Nacos服务器地址，namespace、groupId、dataId绑定该微服务对应的Sentinel规则配置文件
这样通过控制台修改了限流规则后，将同步到Nacos配置中心中，对应的微服务监听到配置文件的更改就可以拉取规则更新(微服务对应的流控规则dataId默认为{appName}-flow-rules)
基于推荐系统的电影交流平台设计
简单介绍一下这个推荐系统项目
该项目作为毕业设计，实现了一个简单推荐系统的工程化落地，整个系统分为三个部分
-
前后端部分: Spring Boot搭建Web应用，前端页面利用Vue做数据渲染(比如异步加载相似电影)
-
模型部分: 在Python环境下利用TensorFlow的Keras API，构建DIN模型，离线训练后利用TF Serving部署在云服务器上(Docker拉取TF-Serving镜像，上传模型文件到云服务器中)，提供线上服务接口。Web应用从MySQL中取出候选电影(候选物品集合)，利用召回层快速筛选与当前用户、当前电影相关的候选电影，再交由排序层调用模型线上服务得到CTR预估值，排序后生成推荐物品列表
-
数据处理部分: 冷启动时使用原始数据集MovieLens, 利用PySpark处理数据集，分离出用户信息、物品信息、上下文信息，然后利用基于随机游走的Graph Embedding方法:Deep Walk在物品组成的图结构上进行随机游走，产生大量物品序列，再将这些序列作为训练样本送入Word2Vec训练，得到电影的Embedding。用户特征和电影特征在冷启动时加载到Redis中(以hash结构存储
hset)，供排序层实时取出特征输入模型获得CTR预估
Embedding主要用来计算相似度，在召回层使用，快速筛选相似电影
召回层的策略
-
单路策略召回:
局限性很大，只能根据候选物品的某一个特征(项目里就是根据电影分类标签)按照评分降序，召回前100个评分最高的相关电影
-
多路策略召回:
策略1：根据用户的观看历史、喜爱历史中的电影分类标签召回 策略2: 召回所有电影中评分前100的电影 策略3: 召回上映年份最新的100部电影
尔后简单混合各个召回集(Map去重了)，并除去用户观看历史中观看过的电影
-
基于Embedding召回:
单路和多路召回都是基于某个特征或组合多个特征，很难综合考虑不同策略对候选物品的影响以确定混合比重等。而物品的Embedding向量本就是特征工程提取出来的，可以将不同策略作为附加信息融入Embedding中，然后直接计算目标电影和候选电影的Embedding相似度(项目里使用的是最简单的余弦相似度)，按照相似度排序后快速召回
排序层的策略
召回层快速召回后可以获得几百量级的候选电影集，尔后需要通过排序层决定到底需要推荐哪些电影给用户
项目中使用的DIN模型，需要4个部分的特征输入，分别是:
-
用户画像特征: 用户最喜欢的风格标签、评分次数、平均评分、标准差等，这部分是离线数据处理后，存储在Redis中方便快速取出
-
用户行为特征: 用户近期评分过、喜欢过的电影id，项目运行过程中用户会不断产生新的行为，这部分会实时更新到Redis中，由于用户特征比较多，排序层使用时从Redis中取出
-
候选电影特征: 离线数据处理时生成了电影的特征，这部分特征在冷启动时从MySQL中加载到Redis里，由于电影数量有限，为了加快获取速度，应用在启动后会从Redis中批量加载所有电影特征到服务器内存中，排序层使用时直接从内存中取出，包括该候选电影的上下文特征如历史统计特征的评分总数、平均评分、标准差等
