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