前言
本文聊下
1、服务管理平台设计与实践
2、AI （个性化推荐、智能搜索）
服务管理平台设计与实践
定义
1、服务质量 比如
a、耗时小于100ms、100-200ms,大于200ms请求量占比
b、前100个耗时最短请求
2、健康指数指请求错误率情况 上游调用下游有多少抛弃量 下游有多少拒绝量
3、问题追逐不在服务管理平台 而在分布式链路跟踪系统中
4、多维度流量 比如1小时流量多少，1秒流量多少
为什么需要
流程简介
操作界面展示
服务方流量维度
服务方质量维度
服务-调用方列表
服务方：我这些服务被哪些调用方使用以及使用情况
调用方
从调用方角度展示了我调用的这个服务下游有多少服务被调用
针对每一个服务设置熔断策略
服务方-报警列表
报警详情
服务治理-创建工单
1、调用方调用某一个服务
服务方不能允许任何人调用
对调用方进行管控
2、审核通过 服务方会分配给调用方一个key即token
调用我的时候 拿着key 服务方才可以让它访问
服务方-服务节点列表
服务管理平台本质
1、对于rpc调用进行管控
2、dubbo是rpc框架也有服务治理功能（只是不强大）
3、brpc、grpc、thrift 仅仅是rpc客户端 没有服务治理
服务管理平台生态
服务管理平台仅仅是展示服务流量使用情况(即每秒查询率QPS)
流量数据来自于数据收集中心
1、通过服务管理平台的SDK数据上报
2、服务管理平台SDK和控制中心、数据收集中心、可视化平台交互
3、控制中心、数据收集中心、可视化平台交互数据均是存储在Mysql中
流量计数器
以1分钟为维度 把所有调用方请求量进行汇总
可以知道整个集群的请求量
运行工作机制
1、上报数据是UDP通讯
UDP通讯是异步的过程 对业务无阻塞
上报数据丢了也无所谓
2、数据中心是UDP Server是基于netty来做的
总体架构
1、数据收集中心(质量与监控)、管理平台（可视化）、控制中心都是all in one即都聚集在一个sdk中
对于内部管理系统没有必要整一个数据访问层
这三个都是一个独立的进程
收集数据存储方案
方案1
1、收集项名称：CA-SB-F1
表示客户端服务A调用服务端服务B的F1函数
2、客户端服务A和其他客户端分别将本地一分钟内的请求量 上报给数据收集中心
3、数据收集中心1分钟聚合一次 只需要将这一次的汇总数据存储到数据库即可
4、type表示是（rpc）http访问还是rpc访问
5、本地一个聚合 数据中心一个聚合
6、数据最长保存一个月
7、真正熔断是客户端服务自己做的 一旦到达阈值 就会熔断
方案2-数据量大不可行
1、数据收集中心不汇总聚合请求量 而是将每次上报过来的数据都存储到数据库
2、查询1分钟内的请求量 通过group by unixtime（一分钟一个时间戳）
时间同步问题
限流问题
场景：一天内只允许10万次请求即1分钟1000次
服务管理平台
高可用
AI （个性化推荐、智能搜索）
个性化推荐系统
需求层面定义
为什么需要
- 长尾挖掘
1、长尾流量就是非热点数据
2、热销品比如iphoneX没有库存
3、冷门商品 每一个种类的数量很少 但种类多
4、
a、遵循二八原则:
20%的商品可以满足需求 产生80%的数据
b、遵循高斯分布（正态分布）
高斯分布
- 流量利用
- 用户体验
- 技术趋势
推荐技术应用场景
推荐系统构成
召回层：比如用户对手机感兴趣 从1000个商品中取100个推给用户
架构核心技术
冷启动阶段：
你第一次进入网站 选标签 因为这时没有你的行为
如果你没有选择 基于当前热点或最新的数据推送给你
用户有了行为即点了哪些商品
这个商品和另外商品相似度会对应一个分值比如0.3
基于内容推荐 若推一个话 则推荐相似度最高的
典型的电商架构
1、用户点了哪些商品 即行为有哪些 做日志埋点
2、收集埋点数据做机器学习训练、推荐作业系统（Hadoop MapReduce） 计算出来用户感兴趣的商品列表
3、计算结果存储在Redis中
基于物品的推荐
基于用户的推荐
基于时间段：比如白天可以推荐给用户，晚上不推荐
LBS即基于位置的服务比如北京、上海
电商推荐场景
用户维度推荐
商品维度推荐
电商推荐架构演进
石器时代
特点
架构
1、参数验证：请求分为header（定长）和body(变长)
网关验证非业务语义的参数 比如参数是否为空
业务逻辑的参数验证则验证和参数相关的 比如参数值是否达到设置的业务最大值
2、网关还可以拼接一个时间戳比如15天 则es只会召回15天内发布的商品
3、排序也是在es中做的
基于人工规则的相似度计算过程
相似度计算方式
CF 协同过滤
使用场景：用户点击商品A 看商品B、商品C分别和A相似度多少
从B、C中推荐一个和A相似度最高的
基于用户行为计算(用户行为相似不是内容相似)
比如10个用户既点击商品A也点击了商品B的有2个人 则相似度（贡献度）为2/10=0.2
余弦
欧式距离
铁器时代
特点
架构
还是按照权重排序
没有引入机器学习
工业革命时代
特点
架构
1、引入机器学习排序
不是基于规则排序
机器学习是动态规则
2、权重w如何计算：通过模型训练比如逻辑回归LR、GBDT等
3、让业务逻辑层只做排序 其他都抽象出来
4、推荐血统即数据源来自于Codis缓存还是来自ES
架构未来
特点
架构
1、离线计算出用户对哪些商品感兴趣 计算结果存在codis缓存中
一键部署到线上去给用户使用
2、机器学习模型w1,w2... 模型训练参数 推送到线上去
3、通过pipline模型 解决了迭代效率问题
搜索系统 Elasticsearch
开源搜素引擎
- SolrCloud
业界用的少 性能较弱
- Elasticsearch
1、支持模糊搜索
2、搜索一个词比如Java架构 先做分词(Java、架构)
3、最近版本支持tcp
两者比较
es应用案例
底层基于Lucene实现
数据类型
非结构化数据即是全文数据
结构化数据保存在tiDB、mysql、mongodb
搜索方法
反向索引（倒排索引、倒排拉链）含义
Lucene检索过程
查询语法
shard(类似于分表)和replicas（冗余备份）
支持转发、自动分散聚合（主节点操作）
自动平衡分片
自动failover
热点数据自动迁移
自动主从切换
副本自动动态调配
多租户
多租户索引
架构图
架构1.0
为什么需要代理层
原生客户端没有限流和熔断等功能且可删除索引
数据导入
业务逻辑层和proxy代理层强耦合
所以数据导入需要异步化
查询语法
脚本
架构2.0
1、控制集群做集群开关
集群1使用，集群2处于未使用状态
集群1需要重启 此时通过控制集群服务配置集群1关闭，集群2开启
控制集群将开关配置发送到代理层
代理层决定路由到集群2上
2、流量切换 比如80%的访问集群1，20%的流量访问集群2
3、每个集群都是全量数据
数据导入
多集群必要性
控制集群服务的作用
参数设置
1、副本至少是2个 也没有必要设置多个
2、shard数量和机器个数保持一致就可以
3、datanode节点是一个单进程 配置占30G内存
es管理和监控工具
- Kopf
- Marvef
电商搜索演进
搜索场景
架构演进
规则化阶段
特点
a、人工规则排序
b、主观调整调权
c、不支持线上ABTest
架构
机器学习阶段
特点
架构
平台化阶段
特点
功能聚焦
微服务化
架构
圈红部分都是数据访问层
架构未来
特点
a、中台(类似SAAS)
b、云搜索平台(通过界面来建立索引、查询)
c、业务一键接入
后记
本文介绍了
1、服务管理平台
2、搜索引擎架构设计
3、个性化推荐系统设计
觉着有价值的话 麻烦帮忙分享下哈😄
