工作总结

发表于 阅读次数： Disqus：

一直想写这篇,但是持续拖延… …
主要总结下这几年做的一些较大且完整的功能,过于零散的小功能以及和公司业务强相关的东西就不做记录了.
顺序是新的在前,旧的在后,不断补充,就当自己的总结.
都是后端相关的工作.
实习的时候参与网站社区相关开发,毕业之后短时间参与了一个项目的零碎开发,之后一直做App后端相关的开发工作,今年年初转到对商家服务的组.
基础技术是spring,mybatis之类的就不每个都写了.

2014年实习
网站功能后端开发
网站新版社区后端开发
后端团队为3-4人

2015.6-2018.1:
App后端开发
主要涉及面向ToC的三个App和面向ToB的一个App
后端团队为2人(后来增加为3人)

2018.1 - 至今
Saas产品开发

消息中心服务

2018年10月 - 12月
使用技术: ES, Akka
建设外部消息服务(短信,邮件,语音通知,企业微信等)的访问服务.
因为对发送记录有检索和统计的需求,且发送量比较大,短信记录几十w条每月增加,保留短信原文.使用ES作为后备存储.
提供多家运营商的,且对发送时间有限制,使用akka封装各个发送端.

企业库项目

2018年8月
与网站ToC端合作,对方增加普通用户录入企业信息入口,提交的数据提供给Saas端.
主要功能为公司搜索(使用opensearch 数据库查询为后备),审核状态查询,后台审核功能.

权限重构

2018上半年
账号体系分为根账号和子账号,子账号权限继承自根账号硬编码排除部分.之后需求是根账号可以管理角色和分配角色给子账号.
对这一模块进行了重构,建立新的角色服务,引入了角色体系,表面是RBAC实现,但实际实现为了后期灵活(比如产品要直接给账号加权限)使用了角色,权限引用次数的设计.
并增加对应的中台服务.

任务体系

2018上半年
使用技术:kafka,redis.
完成任务-积分-等级的体系.
任务定义包括新手任务(只能完成一次),周期任务(每段周期内完成n次),周期积分阶梯任务(每段时间内完成n次,不同的n积分阶梯不同).
运用原有的CDC模块,订阅kafka消息,部分任务完成的事件监听表变化实现,新手任务和周期任务立即结算积分,周期积分阶梯任务使用定时器+redis全局锁实现.
后续完成积分抽奖功能,对接现有的抽奖中台.

数据统计(接手)

2018上半年
使用技术:ES,mongo,spark
原本负责人调走,接手维护改进的工作.
整个数据模块基于mongo+ES+spark完成,数据源包括数据库和kafka消息.
使用ETL导入带ES,spark进行计算后结果写入mongo.
主要优化了几个历史遗留的性能问题和bug,了解整个的设计思想.
写了一篇总结:
https://www.cnblogs.com/fairjm/p/painful-to-maintain-data-statistic-system.html

规则引擎

2017年下半年
使用技术:groovy
使用groovy的scriptEngine实现了一个简单的动态脚本.
本来想用于一些动态业务规则的配置,不过还没有投入到业务中去.
最初版本为: https://github.com/fairjm/common-rules .

feed流

2017年下半年
使用技术:kafka
之前做过一版使用redis存储触发事件的实体id(发帖就存入帖子id),每个用户一个list,支持显示1000条动态.
这一版是一个新的业务场景,要求的数据量比之前大,考虑之后放在redis里不合适,和组内另一位同事合作完成.
最初实现采用了推的设计,每个用户有自己的timeline和feed队列(存储于数据库, feed根据用户id分表分库).
timeline队列对应自己发的内容,自己的时间线,feed是关注的人的内容,是关注的人的timeline的副本(两者格式类似).
用户完成动作之后使用kafka推送到消息(包含feed所需数据)到feed服务并写入.
上线之后原开发组被拆了,没有进一步改进.

网站安全相关

App 扫码登录

图片PK活动

App AB test模块

设计购买业务(接手)

短信服务重构

redis监控

社区编辑器后端

业务思考

2018-06-26 init