外卖的背后：饿了么基础构架从0到1的演进ppt课件.pptx
,外卖的背后-饿了么基础架构从0到1的演进,介绍,2015年初组建框架&工具团队从0到1的演进 话题太大方向决定成败，细节关乎痛苦讲点细节的东西,CI/CDConfigTraceLog,MetricsAlertJobMessageSD,大 纲,负载均衡无损升级基础组件设计,大纲,兰建刚,负载均衡最初的方案,F5HAProxy,部署在客户端本地不需要考虑HAProxy的高可用流量不是问题,负载均衡,兰建刚,负载均衡遇到的问题,部署量变大,痛点：扩容需要更改所有客户端的HAProxy配置，维护客户列表超级复杂后果：运维拒绝再部署HAProxy,配置不统一,目录不一致，文件格式不统一批量修改容易出问题案例：DAL采用N+1的容灾策略，由HAProxy控制切换，完成一次切换演练需要1小时,负载均衡,兰建刚,负载均衡探索解决之道,方案一：减小部署量,集中式的HAProxyF5OSPF LVS,方案二：减少运维成本,服务发现 只需要配置服务名和集群名自动配置下发 服务上下线自动同步至订阅方HAProxy不支持,负载均衡,兰建刚,负载均衡RPC解决方案 内置LB SDK,服务自注册/自发现配置少 只需要服务名集群名部署简单 随应用一起部署RoundRobin 简单可用,负载均衡,兰建刚,负载均衡,Redis/DB解决方案 GoProxy,DAL DB代理，sharding，读写分离Corvus Redis代理，redis cluster，协议转换DAL/Corvus作为服务自注册GoProxy,基于Go语言订阅DAL/Corvus注册事件带服务发现的HAProxy：配置少业务方改造成本低,负载均衡,兰建刚,client,dal,goproxydal,dal,port？,负载均衡Tips,长连接 vs 短连接,把长连接当短连接用以节点而不是连接做负载均衡,健康检测,客户端与服务端心跳检测可扩展健康语义：进程在、端口活着不代表服务“可用”“半死不活”比“死透了”伤害更大,负载均衡,兰建刚,大 纲,负载均衡无损升级基础组件设计,大纲,兰建刚,无损发布最初的状态,开发都有生产权限随时随地发布没有考虑无损发布这回事,无损发布,兰建刚,诉求：“一单都不能丢”,无损发布经典解决方案1. 服务端准备下线2. 通知客户端3. 客户端停止向服务端发送新请求4. 服务端等待正在处理的请求结束5. 服务端下线,无损发布,兰建刚,clientserver,无损发布经典解决方案1. 服务端准备下线2. （通知）（所有）客户端3. （客户端停止）向服务端发送新请求4. 服务端等待正在处理的（请求结束）5. 服务端下线,无损发布,兰建刚,clientserver,无损发布无损发布RPC调用 服务发现机制 注销时所有客户端都会得到通知 客户端与服务端直连 客户端从可用列表里剔除准备下线的服务 绝大多数的RPC的响应时间在秒级以下 sleep 2s搞定,兰建刚,无损发布数据库访问 客户端使用jdbc/sqlalchemy通过GoProxy访问DAL 没有通知机制,无损发布,兰建刚,clientgoproxy,dal,dal,dal, goproxy支持mysql协议 支持dal侧连接重连, 客户端改造：限制连接存活时间,无损发布无损发布Tips 服务心态：能用技术解决的尽量用技术解决 业务方的改造能节省中间件的很大精力,兰建刚,大 纲,负载均衡无损升级基础框架设计,大纲,兰建刚,基础框架设计,兰建刚,开放式架构 基于组件,给业务开发团队最大限度的自由,基础框架设计,兰建刚,开放式架构 基于运行时,封闭,给业务开发团队最大限度的自由,兰建刚,基础框架设计开放封闭原则敏捷软件开发-原则、模式与实践,基础框架设计,兰建刚,开放封闭原则饿了么基础框架实践基础框架应该是可以扩展的，但是不可“选择”的,
