zhny
架构师
- 公司信息：
- 上海一谈网络科技有限公司
- 工作经验：
- 12年
- 兼职日薪：
- 1000元/8小时
- 兼职时间：
- 可工作日驻场（离职原因）
- 可工作日驻场（自由职业原因）
- 所在区域：
- 上海
- 浦东
技术能力
12年以上开发经验，两年管理经验，崇尚技术，喜欢追根究底，始终保持学习的心态，具有丰富的系统架构设计、数据库结构设计、业务逻辑抽象能力，性能优化设计能力，有大型网站高并发架构设计及调优经验.spring-boot、dubbo、apollo、kafka、rocketmq、mybatis、redis、hbase、sentinel、canal。
项目经验
直播用户画像中台 后端研发
构建一套用户画像系统支持离线计算与实时计算平台。
主要功能为业务开发或数据运营在平台配置对应源数据、类 sql 之后自动生成执行 job 进行计算，计算结果存入画像系统供业务方调用。
技术架构主要分离线计算部分、实时计算部分、后台配置、C端展示层。
离线部分采用阿里 odps （类 hive），主要流程为 quartz 根据配置频次执行批处理 job ，离线数据从 Odps 执行 hsql ，计算结果发入 kafka ，监听脚本将数据存入 hbase
实时计算部分采用 flink 流式计算引擎，主要流程为 zk 监听配置变更，变更后重新生成 flink job 编译成 jobGraph后 yarn-client 远程提交至集群执行，计算结果发入 kafka ，监听脚本将数据存入 hbase 。实时部分额外负责 flink job 的集群管理。
2020.01 - 2020.03
活动运营配置平台 后端研发
背景：
在营销域中，存在大量活动，每次活动的上线都必须有很多后台配置需要达到修改后实时生效的目的，这些配置有很多特性，比如交互单一，表单多，配置单一，可复用性强等。
虽然可以利用 apollo 来实现。但是这种方案的弊端很明显，首先在 apollo 中配置 json 数据虽然能达到快速上线的目的，但是不支持可视化，容易出现格式错误；活动规则配置字符很容易超过 apollo单 key 的最大字符上限；其次 apollo 的用户对象是研发同学，而非活动运营这样既不安全也不合规。
基于以上原因，亟待开发一套通用可视化配置系统，能支持业务多维度资源配置，实现通过定义表单描述语言或者拖拽组件即可实现新页面的创建。
活动配置中心系统具有以下优点：
- 定义了一套表单描述语法，整套界面支持可拖拽，操作便捷，支持多种数据结构，通用性强
- 支持配置数据数据同步，可以与业务方数据库表数据一一对应、实现了配置的读写分离
- 高性能 配置读取本地内存缓存，利用 Zookeeper 做实时更新，实时性强
- 高可用 sdk 支持配置持久化到本地文件快照，保证即使 server 不可用时业务端也能读取文件快照对外提供服务
主要分为后台配置模块和业务端实时配置读取两大块
后台部分：
流程一：RD 根据表单描述语言（DSL ）将需要配置的内容生成表单描述信息（这里简称 Schema 集合），然后通过后端表单结构控制器后保存到数据库。
流程二：后端表单结构控制器通过读取 Schema 信息返回给前端，前端渲染成表单配置页面（运营使用）。
流程三：运营操作配置页面数据，可以进行 crud 操作，然后通过后端配置数据控制器持久化到数据库
业务端 sdk 获取实时配置数据：
非同步场景：
sdk与 zookeeper 保持长连接，ZK 主要用来将配置更新通知到 SDK ，运营修改配置后 push到 zk，zk 再通知到 SDK，sdk 更新本地缓存。
备注：2022.8 移除 zookeeper watch 机制改用 rocketmq broadcasting 通知 sdk 配置变更
同步场景：
运营修改配置后台发送 rocketmq 消息，业务方 sdk 注册需要监听配置变更，sdk 客户端监听到注册变更消息将配置变更保存至对应业务配置表内，然后将回调结果返回给配置中心。
2019.01 - 2019.12
活动中台建设 后端研发
根据我司活动场景抽象出不用的活动玩法，沉淀成功能组件。活动中台部分在逻辑上分成了基础服务、通用能力、玩法编排层三层。
- 基础服务层聚焦于基础服务，无需考虑业务的复杂性而制定多种规则，不会随着业务和前台产品的调整发生变化，基础服务层对一致性要求较高，需要具备可溯源能力，基础服务层不会对外开放。
- 通用能力层则专注于业务的抽象，将通用逻辑汇聚到一起，通用能力是不断演进的，随着业务的复杂变的不断的厚重，能力不断的壮大，最终把活动生态里面的能力都呈现出来。
- 玩法编排层主要是对通用能力的组合在一起对外提供服务，通过编排可以控制各个独立的通用能力之间的关联逻辑，使其专注于自身的领域内逻辑，很好的进行了模块间的解耦。将一些独立的系统串联到一起，满足不同的玩法需求。通过其灵活性可以编排出各式各样的玩法逻辑。如果没有编排引擎，那么模块间的关联关系就必须通过上层业务层编写代码实现。
基础服务
1.物品系统主要包含道具、资产组成。为了统一化管理，在其上次抽出了聚合层，用于聚合其他团队的道具和资产、屏蔽技术细节、对外提供统一服务。目前已经接入的外部服务有：比心币、星钻、钻石、优惠券、直播或语音道具、装扮类等50多种资产类型。对于外部资产一致性保障
案例展示
-
活动运营配置平台
背景： 在营销域中，存在大量活动，每次活动的上线都必须有很多后台配置需要达到修改后实时生效的目的，这些配置有很多特性，比如交互单一，表单多，配置单一，可复用性强等。 虽然可以利用 apollo 来实现。但是这种方案的弊端很明显，首先在 apollo 中配置 json 数据虽然
-
活动中台建设
根据我司活动场景抽象出不用的活动玩法，沉淀成功能组件。活动中台部分在逻辑上分成了基础服务、通用能力、玩法编排层三层。 - 基础服务层聚焦于基础服务，无需考虑业务的复杂性而制定多种规则，不会随着业务和前台产品的调整发生变化，基础服务层对一致性要求较高，需要具备可溯源能力，基础服务
