微店 陈国成——微店技术演进之路

2020-02-27 755浏览

  • 1.微店技术演进之路 陈国成
  • 2.10 - 300人 海豹突击队 LAMP、F5、redis 技术特点 100w – 3000w 注册卖家数 第一阶段，开天辟地
  • 3.DB 问题一、安全 日均受攻击 560 W次 问题二、全站性能很差；稳定性问题频发 1E、单机单实例、性能/稳定性低下（2个 9）、SQL治理差 第二阶段，亡羊补牢
  • 4.• 统一接入层（lua on nginx）运行。对业务无侵 入，且100%全覆盖。 • 完善的漏洞防护，覆盖owasp主要漏洞类型。 • 实时规则防护，0day防护。 • 全天候实时阻断 • 虚拟补丁，规则动态实时更新 • 覆盖owasp Top10主要类型安全问题，完全规避 防范SQL注入问题。提供cc防护、爬虫拦截、限 流支持。10w级黑名单加黑支持。 • 与安全日志分析系统联动，实时的风险感知并 拦截 • 0误伤 WAF，安全防火墙
  • 5.• 支持语言java、php、Node.js等语言 • 动态（语法分析）、静态（正则表达）以及 集成第三方扫描引擎（rips、findsecbugs等） 相结合的扫描模式 • 跟发布系统流程上结合覆盖所有发布上线项 目，强制安全扫描 代码扫描，过安检
  • 6.• HIDS 轻量级agent和云端组成，实现对文件监控、登录行为监控、命令审 计、webshell查杀、网络监控拦截等功能。 • 解决主机层安全风险，并可对员工行为进行审计 安全，主机安全保护
  • 7.ü 建模： ü 关键字、频率、webshell、httpheader 等 ü 去噪 ü 菜刀请求特征 ü 基于统计的模型 ü 机器学习攻击检测—无规则引擎实现（进 行中） 安全，实时安全日志分析预警
  • 8.• 分库分表：Client端实现分库分表功 能；提供jdbc规范的接口，接入时只 需替换数据源 • 读写分离 ：根据业务的sql确定使用 主库还是从库执行sql语句，降低主 库的压力；读请求按比例分配 • 独立的账号体系：接入业务使用的是 vdds的账号，数据库用户名/密码加 密且对业务隔离，保证了数据库账号 的安全性 • 配置自动变更：配置改变之后，自动 推送到所有机器上，不需要业务重启 机器 • 灵活的hint机制：业务可以通过hint 直接指定物理表，多运用于扫表的场 景 中间件 ， VDDS（分库分表）
  • 9.• 平滑下线 ✓ vdds proxy下线时，通过lvs心跳机制， 不接受新db请求，同时等待老连接完成请求在关 闭vdds proxy实例，降低业务端报错的概率 • 配置自动生效 ✓ 给vdds proxy增加逻辑库的时候，自 动推送到所有vdds proxy实例，初始化对应的 vdds配置 支持mysql preparedStatement协议 • 负载均衡 ✓ 业务的db连接分配到多台vdds proxy， 保证服务的稳定性 中间件 ， VDDS proxy（分库分表）
  • 10.• vss（增量数据同步） Ømysql，消息，hdfs， kudu的支持 Ø高可用 Ø灵活的过滤规则 Ø动态加载目标写入代 码 Ø任务配置自动生成 Ø负载均衡 中间件 ， vss（增量数据同步）
  • 11.• vts（全量数据同步） Ø 存储，mysql，消息，hdfs， redis，本地文件支持 Ø 高可用 Ø 动态加载过滤规则 Ø 数据拉取和写入的速度可控 Ø 负载均衡 中间件 ， vts（全量数据同步）
  • 12.• 消息队列作为中间件的核心产品，在电商平台体系中 扮演着极其重要的作用，包括异步系统解耦，流式数 据处理，binlog同步等 ✓ 已有800多个topic ✓ 每天有三千万多万的消息产生 ✓ 每天亿级消息消费 • 由于电商平台业务的复杂和多样性，导致对消息中 间件有着特殊的功能需求及性能和可靠性要求： ✓ 持久性，消息堆积，消息回溯 ✓ 支持严格顺序消息：binlog同步 ✓ 高吞吐，低延迟 ✓ 高可用，容灾 • 开源框架选型 RabbitMQ：使用erlang开发，出现问题难以把控， 且顺序性消息及消息可靠性无法提供保障 Kafka：分区越高load越高；多个分区导致随机写， 影响整体吞吐 RocketMQ（开源版本）：不支持事务消息；缺 少容灾支持；运维成本比较大 中间件 ， vdianMQ（消息）
  • 13.Ø事务消息： Ø全链路消息轨迹： Ø高可用，容灾 ØAdmin运维 Ø其他feature： ✓按照tags过滤消息 ✓支持位点重置 ✓支持消费分组以及分 组内的负载均衡 中间件 ， vdianMQ（消息）
  • 14.Ebay 两阶段提交 基于消息 Alipay XTS Taobao TXC 方式 同步 ；阻塞协议 代码侵入性 弱 异步 Try同步； confirm/cancel异步 较强 强 同步 弱 数据库侵入性 弱 主事务分支事务记 录 Log表业务同库 中间件 ， tcc（分布式事务框架）
  • 15.中间件 ， tcc（分布式事务框架）
  • 16.Ø TCC处理流程 每个service需要register和commit; 每个业务db写操作,附加日志表写作为本地事务提交 TCC-Server负责事务注册、回滚;必须保证性能和稳定性 每接入一个应用,多两次RPC调用，开销为15ms左右 支持应用级别事务动态降级 Ø Tcc特性 支持Local和Remote两种模式 Local模式收敛在单一系统中，解决跨库事务 Remote模式支持跨系统之间RPC调用的分布式事务 数据层封装遵循JDBC规范，透明代理VDDS，方便后续无 缝同步升级 支持Hint方式指定回滚逻辑和自定义回滚方法 默认不需要显示回写回滚参数，基本无侵入 支持显示调用回写特殊参数 中间件 ， tcc（分布式事务框架）
  • 17.Ø 数据评估参考： 页面加载速度每提高1秒，转化率增加2%...反之，如果超过4 秒，25%的用户会选择离开… 用户最满意的打开网页时间是2-5秒，如果等待超过10秒， 99%的用户会关闭这个网页 Google：网站访问速度每慢400ms就导致用户搜索请求下降 0.59% Amazon：每增加100ms网站延迟将导致收入下降1% 雅虎：如果有400ms延迟会导致流量下降5-9% 秒开
  • 18.秒开 S 300 MS 500 MS ID C
  • 19.流程优 DNS TC P C SS JS VA P 1 1 C SS JS 秒开
  • 20.第二阶段成果
  • 21.5000w IDC成本 70% , < 15% 服务器利用率 第三阶段，女娲补天 600+ 技术人员
  • 22.全站分布式，语言收敛
  • 23.运维体系，以应用为中心
  • 24.TraceId由最前端java应用生成，会放到tomcat中 Rpc链路的串接使用0.1.4.1.5的方式，异步情况做了特殊处 理 所有远程调用框架的日志格式一致，存储位置一致，通过 不同类型来区分 TraceId分四部分16BSeq:short类型2B 1～8000循环递增 时间戳：long类型8B 当前时间 机器IP：int类型4B 当前机器ip，转成int 进程号：short类型2B 当前进程号，避免统一机器起多个 应用冲突,同时对大于short的做截取处理（进程id是int的） 服务治理， vtrace（分布式链路跟踪）
  • 25.服务治理， vtrace（分布式链路跟踪）
  • 26.·资源快速交付 ·运维能力的一个重要指标 ·即时交付，秒级交付 ·应用平滑上下线PAAS化 ·节点创建后，应用可以自动完成上线 ·节点删除后，应该可以自动下线 ·自动化平台化 ·和CMDB，发布系统等运维系统自动化对接 ·平台化管理 ·生命周期全部自动化 ·降低TCO ·提高虚拟化密度 ·快速上下线 ·跨平台 ·支持libvirt虚拟化，支持docker；稳定性和灵活性 兼顾。 私有云，成本 & 效率
  • 27.支撑系 统 镜像存储 Ceph集群 ES集群 日志 监控/性能 Graphite集 群 VLB(4层7层管理平台) SOA平台 A APP APP APP APP APP APP APP P I 资源调度模块 应用管理 统一API 健康检查 and LB管理模块 dashboard 资源配置模块 迁移模块 资源集群管理 权限管理 KVM IAAS管理 docker IAAS管理 镜像统一管理 日志查询 监控/性能 服务发现 应用节点 管理调度平台 监控 and 日志 graphite logstash 平台数据交互 RPC rabbitmq websocket 通信层 Vdos-agent 容器资源 节点 Vdos-agent 容器资源 节点 Vdos-agent 容器资源 节点 Vdos-agent 容器资源 节点 IDC资源
  • 28.开发自助管理自己的应用，解放PE/OP的 工作量，加强开发参与，提升应用稳定性。 PE/OP向SRE转型 1 CD • 核心产品： 监控系统 容量水位 线上job管理；job互编排 日志采集、中转、分析 链路依赖治理 完善的dashboard，数据分析 超级agent 交付 3 • • jira • • 4 • • grep • cron • Ssh • 2 • • • job AIops • • • • 2 AI NOOPS，效率 & 质量
  • 29.43s 平均每次构建 104s 平均每次部署 574，324，400+ 后端应用数量，前端应用数量，每天发布 18，9，6 平台建设前后的OP数量变化 NOOPS，效率 & 质量
  • 30.第四阶段，海量数据下的搜索与推荐
  • 31.技术挑战 数据行数大 实时性、一致性要求高 TPS/QPS在1-2k左右 业务挑战 排序逻辑复杂 搜索引擎 1.0 1.0架构 • 引擎基于solr，主从 复制框架，⼀主，N 个从 • mapreduce join 数 据，批量直接更新主 solr 索引中。分钟级 增量 • 排序模型简单使⽤少 量⼏个销量数据加权 计算。solr 函数排序
  • 32.• 封装solr，构建分布式架构 • 引⼊merge层（ illusion）， 采⽤海选+精排架构 • 引入统一接口层（atlas）。 QP实现；ABT • 索引构建，全量 hadoop join + 实时增量；形成dump 服务 • 粗糙的引擎管理系统：屏蔽 降权等 • Rank。海选+精排，引⼊ LTR • 问题，仍然还有。。。 搜索引擎 2.0
  • 33.• 引擎能⼒升级，⽀持算法个 性化能⼒，插件化⽀持；同 时Rank在线学习，模型更 新更实时。 • 实现实时引擎，时效性 < 500ms • 索引管理引⼊调度器，引⼊ 全量索引切换调度。（2.0 按顺序切换） • 索引碎⽚整理，减⼩磁盘空 间，提⾼查询性能。 • Dump 服务升级，hbase 成为 dump 的基础。 • 不依赖业务的版本号设计 （hbase ⾏原⼦），简单、 稳定、⼀致。同时稳定、可 靠的版本号为系统做幂等提 供支持 • 实时对账/补偿 搜索引擎 3.0
  • 34.个性化推荐算法
  • 35.S to rm H5 zookeep er S to rm WT sp o u t S pout b o lt B o lt R ed is ES b o ltB FTR L jsto rm H AD ES ES 基于个性化的推荐算法-online Ranking & online Rerank
  • 36.基于个性化的推荐算法-offline I2I
  • 37.