在公司画的图不允许带走，所以这里的很多图都是我离职后画的，过去了这久很多细节记得不太清楚了
很多方案业界都差不多也不存在什么泄密的风险

耕耘-大数据量的选品、选买家、选商家系统

之前写的一篇介绍业务的文章：https://mp.weixin.qq.com/s/1f1Eh0m650SKtrIWKq9j9Q

主体用户：内部运营、产品、业务开发等
简介：基于阿里内部的搜索技术体系（Ha3）构建了高效、实时的商品（亿级）、商家（百万级）、买家（千万级）筛选系统，流计算能力接入也让 1688 的品商圈选进入实时（毫秒级）阶段。承载了 1688 几乎 100%的运营选品、商功能,提升运营选品、商效率 50%左右，已有筛选规则十万+。还在原业务之上衍生出自助的指标接入中心系统已接入字段 几百+，并抽离底层引擎和上 层业务接入 CBU 多个其他业务。

职责

Developer->Owner->技术PM

前期：核心开发，技术调研、方案设计，跨部门沟通。整个项目分为数据层、引擎层、应用层，我主要负责应用层的设计和开发，以及部分引擎层的开发。应用层我负责：抽象商家、商品、买家流程规则流程，负责数据预览、排序、去重，导出（投放导出、人工导出、历史数据导出），打标（对接打标系统），对接投放系统，对接报名系统，指标管理系统。

中、后期：Owner、技术PM，人员有变化就独立负责整个产品的技术发展，带一个P5和一个实习生一起开发。在原有的基础上做好自动化接入和复用。1.指标接入自动化 2.引擎层抽象出来提供给BU内其他想接入引擎的业务方使用 3、商家、商品、买家能力诊断 4.数据治理，自动下线字段，自动清理过期规则。 5.字段统一，提供部分离线数据的输出能力。 5.线上问题定位、性能优化等

核心问题**

背景
逍遥子提出人货场一体，招、选、搭、投需要串联，提升运营效率。
image.png

核心痛点

技术调研和原架构问题
0.特定业务场景下的业界方案基本没有，淘系也有类似的架构，但是业务属性不同不能直接在其上面进行搭建。
1.数据量大MySQL根本无法满足
2.基于MapReduce、ODPS等架构查询耗时巨大，无法满足实时查看的的需求
3.原架构基于OLAP在实时能力上无法满足，价格、商品上下架状态、优惠等

业务架构

image.png

简单数据流向

image.png

技术架构

image.png

DUMP内部细节

image.png

挑战与方案

1、数据量大、dump要快、要求实时预览-》搜索、Ha3、Blink、ODPS
商品将近3亿亿数据（1个多小时）
2、新增商品要求实时更新-》Blink、Swift、binlog
3、多引擎、多业务-》抽象引擎查询层，并提供给其他业务接入
4、字段接入逐渐成为瓶颈-》引入指标自助接入中心
5、历史数据离线DUMP优化-》blink批量，以及两层并发
15亿历史记录，2个半小时完成同步
6、助力业务（商家成长）-》商家、商品、买家画像
7、数据治理->统一部分离线字段数据，上下线机制
离线数据导入到hbase中，bulkload优化，非blink耗时1个小时左右
8.如何快速导出，线程池并发请求，使用easyexcel写入，解决oom

成果数据

1、招选搭投中至关重要的一环，100%的运营使用率、十万+选品规则、几百+字段接入
2、引擎查询层，同时支持多个引擎，多个技术方。而在有此系统之前，一个业务方如果想接入搜索能力，需要向团队中精通搜索底层原理的搜索业务owner提开发需求，等待一周左右开发排期，待搜索owner完成一套引擎服务搭建后，业务同学后才能进入业务开发阶段。 我们用此系统消除了搜索owner的单点阻塞问题，实现了用自动化技术解放生产力。
3、双十一大促、商人节大促1688选品，赛马，几十个垂直和横向业务

收获与反思


收获**
1.前期的技术调研很重要，具有特性业务属性的方案很难在外面找到合适。前期调研了很多集团内部各个BU的选品方案，和各个BU的同学也做了很多的交流，对各个BU的技术方案有大致的了解也可以借鉴很多的经验，避免了很多的坑。
2.搜索的实时能力其实很早就有，但是每个接入放都需要和搜索团队一起配合开发。这也让我对搜索的底层架构有了一些了解。
3.业务上的评价非常好，获得了好的绩效。

反思
1.在商品力和商家成长的战略下，我们尝试做商家、商品、买家的画像，发现这个其实非常难做。比如一个商家的各项能力，在B类场景下非常难衡量，最后只能和各个行业的运营交流，确定一些常用的指标来对商家进行画像。
2.产品其实逐步发展的，要比业务想的提前一点，但往往业务需求来的非常突然，需要平衡好。我个人觉得一旦有机会，一定要把自己从重复的答疑、人工接入中脱离出来，提供自动化的接入和答疑机制，这样才能把更多的人力资源用在核心业务的跟进上。

数据聚合中心



用户：业务开发、运营间接使用
**

核心问题

1.会场搭建前端基于各种模板组件，后端提供字段来填充，产品、运营告诉前后端展示哪些字段。
2.每一次新的功能都需要多方沟通使用哪个字段，商品基础、不同的业务开发、前端等等，甚至很多时候是运营自己在页面选字段了，逐渐变得混乱。
3.投放系统、招商系统用的字段不同，导致线上问题等等。

核心功能
1、会场标准化数据聚合路由，商品、商家维度的投放字段标准化，统一化，方便聚合字段
2、逐渐有越来越多的其他业务接入，接入标准化、使用标准化
3.本质起到的是类似业务网关的聚合作用
**

核心流程

接入
image.png

使用
image.png

技术架构

image.png

核心接口

1.PrimaryDatasource
Result get(Map)
Result batchGet(List<Map>)

2.EnancheDatasource
Result get(Map)
Result batchGet(List<Map>)

3、DataQueryServiece
Result query(Param)
聚合ID,需要返回的字段，超时时间设置

核心流程

流程非常的简单，代码量非常少。非常常规的线程池利用。
image.png

挑战与难点

1、聚合情况下性能不能有明显的下降
线程池技术，只负责转发接口性能取决于外部系统
2、稳定性非常重要
监控、降级、熔断机制；对接口性能提出要求
3、数据治理不能忽视
申请机制
4、问题协查有点麻烦
提供测试功能
其他同学开发了链路工具
5.线程池？
线程数量选择：IO密集型还是CPU密集型，2N/N+1?用压测微调

成果数据

1、大促qps峰值 几万+，负责期间无故障
2、1688几乎90%的页面在使用，支持商家、商品维度接入，百+主数据源、几百+辅数据源、几千+聚合数据源
3、 双十一大促、商人节大促多次经受考验

收获与反思

1.对并发的使用有了进一步的了解
2.小小的功能可能带来不错的业务效应和技术提效
3.稳定性压倒一切
4.所有接入放的流量预估都是不准确的，要有熔断的手段

任务权益中心

职责

前期：核心开发，技术调研、方案设计，权益、任务等基础技术能力的打造，技术方对接接入
中、后期：owner、技术PM，和一个P5、一个实习生一起开发，开放技术方自动化接入、运营使用平台打造

核心问题

1、各种类型任务、权益分散，各自业务开发重复建设，不利于技术复用，运营使用麻烦，没有统一的平台
2、BU 战略需求，商家成长、商品力等，通过任务、权益带动商家对店铺、商品的优化

业务流程

任务接入
image.png

权益接入
image.png

领域建模

任务域：任务原型、任务项、任务包
权益域：权益原型、权益项、权益包
场景：任务、权益、人群

技术流程

任务技术流程
image.png
image.png
image.png

权益技术流程
image.png
image.png

挑战与难点

1、需要支持不同数据源，离线、实时
适配器，统一归一到MQ消息，但对MQ的消费需要限流，sentinel的匀速限流非常好用
2、权益、任务不要强耦合
不同系统，权益人群支持不同圈定方式
3、关系数据比较多，数据量上亿，采用何种存储？
使用lindorm,写入 tps 10W/s ，qps 7W/s完全满足需求,二级索引可以满足查询功能
4、任务完成状态和权益发送状态商家会非常关心，容易引起投诉
建立对账机制，补偿机制，同时提供订正和手动触发功能

成果数据

结合 1688 的业务需求构建了支持商品、商家、买家的任务、权益系统，使得任务、权益的接入 规范化，任务及权益支持实时（毫秒级）、离线两种方式的接入。目前已接入 100+任务、权益， 发放任务实例亿级、权益百万级，经历多次大促的考验，系统日均调用量千万级，大促峰值 QPS 2 千+。

内容导购-挑货

背景

image.png

内容导购的一种尝试，从0到1搭建，做了半年多，后来业务交出去了，业务量没有起来，去年业务死掉了，哎.

供应商可以方便的进行老买卖关系维护，买家可以快速获取关注的供应商的重点动态。也可以为供应商引入新的客户，并沉淀为老买卖关系，降低商家的运营成本。

功能上主要是：主要是商家资质入驻、动态发布、feeds流打造（采用了活跃与非活跃的推拉结合方式）

新用户访问挑货时，挑货服务会推荐部分优质供应商给用户，用户可以关注供应商，看到供应商的挑货内容。

业务流程

image.png

技术流程

image.png

Feeds流模式


业界方式**
image.png
可以参考tablestore的官方文章《如何打造千万级Feed流系统》、《Feed流系统设计》、《知乎首页feed演进》

我们的方式
其实开始在做架构设计是想基于微淘的，然而很多业务上的定制无法满足。微淘的关系和微淘的内容之前是在一个团队孵化出来的，并没有抽离出独立的内容库可供直接接入。在feeds流上微淘有自己开发的一套基于多级缓存的架构，并且是基于拉模式的。

1688的关系有独立的团队维护，组织架构决定了技术架构，因此我们决定自己打造内容库和feeds引擎。结合业务特点，我们采用推拉结合，以推为主、拉为辅的策略。

因为数据规模比较小，1688的老买卖关系总量在4亿，一个粉丝最大的供应商的粉丝数量级在几十万不存在非常明显的大V，同时考虑到在挑货频道活跃的还会有很大的递减效应。在业务运营了一段时间后我们统计发现在挑货频道活跃供应商量的活跃粉丝级最多在几万，更多在几百到上千。这种量级的数据，使用推模式能很好的支持查询性能。

推模式
image.png
image.png

拉模式
image.png

非活跃用户激活
image.png

评论设计
image.png
同步写入评论，消息异步更新计数表

点赞设计
类似评论的设计

计数设计
image.png
表结构类似上图

已读设计
我们的设计非常简单只是一个标志位的更新，业务上要求也非常简单
复杂的可以参考知乎的设计《知乎已读服务的前世今生》

挑战与难点

1.一个千万活跃或者亿级别的feed流或许会有非常多的难点，然而我们业务量上并没有起来，所以很多提前设计的东西都没有用上…
2.更多的是业务发展的挑战

成果数据

花了非常短的时间，三四个后端，2个前端，三四个客户端就把业务支持起来，之前放在阿里巴巴APP的第二个tab，业务上的目标是DAU是百万级别，然而后来我们把业务交给另一个团队的时候峰值DAU也仅在几十万。
从侧面也证明了B类的电商导购非常的难做，毕竟企业采购是一个非常谨慎的过程。和直播项目一样这样的导购活跃买家大部分是淘宝等下游买家，因为企业不管是大型企业或者中小型企业在采购计划上都会季度性。
image.pngimage.png

收获与反思

1.充分设计却不要过度设计。在挑货之前1688内部好几个不同的咨询类内容频道，并没有feeds类的。在架构设计的时候我们考虑了并内容频道的统一，把所有内容类的都落到我们的内容库来，而事实是业务还没起来的时候就已经交出去了，而在通用化上花了不要的时间，这部分技术的通用化并没有产生什么价值。

2.前期考虑的很多性能上的问题都没有出现过，很多提前设计的方案也没有用上。之后曾看过知乎的feeds演进，突然有一个结论，没有完美的架构，能做的只是尽量匹配当前业务需求的架构，而在扩展性上适当流一些口子就行了。
比如查询风暴的预防，我们设计了一个类似session池的机制来防止查询风暴的突然发生。在写入信箱的时候把用户最新的sequenceID放入缓存和存储中，查询的时候客户端把最新的sequenceID传过来做比较，如果没有更新的则不需要查询底层的存储。然而事实是业务量没起来根本不需要,用底层的存储抗流量足够了…

参考：《帖子中心，1亿数据，架构如何设计？》、《微博每日数十亿级业务下的计数器如何扩展Redis？》、《计数系统架构实践一次搞定》

1688直播

背景

直播导购的一种尝试，从0到1搭建，做了半年多后来业务又交出去了，业务还活着，但是流量一直起不来。

核心流程

《阿里云视频直播解决方案》、《阿里云-在线教育视频直播》
直播流、消息流、点赞流都基于淘宝的能力，主要我们做的主要是主播报名、入驻、管理，直播的消费、管理，主播、直播的数据分析，简单的投放排序模型，APP端和PC的投放。

挑战与难点

1.直播基于阿里云，很多东西不用做，只需要消费直播就可以。淘宝直播消息过来，消费后进行直播管理，然后就是直播的投放系统打造，核心在于运营排序机制的满足。
2.排序机制初期也非常简单，

成果

1.半年大概是主播十万+，1000+/日的直播量，大促的峰值买家DAU几十万左右
2.目前应该接入了算法了，但是B类的直播实在难做。

app端
image.pngimage.png

PC端
image.png
image.png

细节TODO

1688+钉钉

跨BU项目
image.png

把将近100W的诚信通商家拉到钉钉上，打通钉钉账号和1688账号，定制诚信通商家组织，自定义钉钉界面、消息、标签等等，运营自动化建群拉人、自动清理群成员、增量拉人。多种样式运营自定义群消息等功能的支持。

这个在技术上功能做的非常薄，除了商家钉钉数据的沉淀外，更多是钉钉获利更多。

投放流程优化和改造

image.png
image.png

核心问题

1.核心应用但是稳定性不好，大促出现问题，性能暂时能满足要求
2、多个域耦合导致一个域出现问题，其他受到影响
3、逻辑老旧，清楚的人较少

拆分应用

怎么拆分？
确定域范围，单一职责、服务粒度适当、考虑团队分工、多轮演进方式拆分、避免双向依赖和循环依赖
1、排序域：比较熟悉，参与
2、投放域：比较熟悉，参与
3、导购域：不熟悉

为什么要拆分？
组织架构其实没有发生变化，但团队内部分工细化了
1、稳定性
2、开发效率

步骤
1.明确拆分原则和拆分需求。
2.梳理出业务模块和之间的依赖关联关系。
3.按照业务为单位，拆分实体、以及应用工程单独部署。
4.按照业务为单位拆分应用服务，避免环形依赖和双向依赖。
5.抽离出公用的接口、实体，以及服务单独部署为公用服务。
6.考虑升级过程中的兼容性

明确拆分目的-》识别出要重构的地方-》量化拆分预期结果-》设计拆分方案-》方案评审，确定各端改动点和可能带来的最坏影响-》和业务方进行沟通知会影响点-》制定拆分时间表-》牵头拆分实施-》管理进度和风险-》灰度-》监控兼容性-》加大灰度-》监控-》完全切换。

业务因素、组织架构、投入产出比、系统可持续发展性、软件发布

具体工作

1、梳理逻辑，减少重复调用、合并调用等
2、逻辑不清晰，将逻辑描述xml化，通过上下文传递，自定义processor
3、数据库拆分

建新表&迁移数据&binlog同步
1） 新表字符集建议是utf8mb4，支持表情符。新表建好后索引不要漏掉，否则可能会导致慢sql！从经验来看索引被漏掉时有发生，建议事先列计划的时候将这些要点记下，后面逐条检查；
2） 使用全量同步工具或者自己写job来进行全量迁移；全量数据迁移务必要在业务低峰期时操作，并根据系统情况调整并发数；
3） 增量同步。全量迁移完成后可使用binlog增量同步工具来追数据，比如阿里内部使用精卫，其它企业可能有自己的增量系统，或者使用阿里开源的cannal/otter：https://github.com/alibaba/canal?spm=5176.100239.blogcont11356.10.5eNr98
https://github.com/alibaba/otter/wiki/QuickStart?spm=5176.100239.blogcont11356.21.UYMQ17
增量同步起始获取的binlog位点必须在全量迁移之前，否则会丢数据，比如我中午12点整开始全量同步，13点整全量迁移完毕，那么增量同步的binlog的位点一定要选在12点之前。
位点在前会不会导致重复记录？不会！线上的MySQL binlog是row 模式，如一个delete语句删除了100条记录，binlog记录的不是一条delete的逻辑sql，而是会有100条binlog记录。insert语句插入一条记录，如果主键冲突，插入不进去。

联表查询sql改造
现在主键已经接入全局唯一id，新的库表、索引已经建立，且数据也在实时追平，现在可以开始切库了吗？no！
考虑以下非常简单的联表查询sql，如果将B表拆分到另一个库里的话，这个sql怎么办？毕竟跨库联表查询是不支持的！
image.png

切库方案
image.png
image.png

4.代码拆分
按照人员分工、业务来拆分进行

感受：
1.重构是长期投资，很多人是看不到这一点，这时候就很容易出现非技术性的因素，包括项目成员和业务方
2.沟通非常重要，和管理者的沟通，和项目成员的沟通，和业务方的沟通
3.充分的测试和灰度机会很重要，包括单元测试、回归测试等等
4.没有带来直接可体感的拆分和重构都不值得进行，稳定性提升了、性能提升了、开发效率效率提升，都要可量化。
5.留点精囊妙计，墨菲定律。复杂问题要拆解为多步骤，每一步可测试可回滚！
6.重构的关键在于运用大量微小且保持软件行为的步骤，一步一步达成大规模的修改。
**

参考资料

自定义xml标签：https://www.cnblogs.com/java-zhao/p/7619922.html
《重构》：https://zhuanlan.zhihu.com/p/68385955
投放：https://www.infoq.cn/article/aqOl4cJOimbTBa2LpMTz