2017年陌陌服务化架构实践.pdf

《2017年陌陌服务化架构实践.pdf》由会员分享，可在线阅读，更多相关《2017年陌陌服务化架构实践.pdf（33页珍藏版）》请在三个皮匠报告上搜索。

1、r T T 陌陌服务化架梅实践201120132014201520162017起步早12年底开始转向服务化架构自主研发核心框架与周边生态产品全部自研架构升级迅速拥抱微服务与容器化等先进理念1000+服务7000+实例6000+主机（含Docker容器）全天调用总量 1500亿峰值 300万/秒PHP开发API快速响应业务需求Java开发服务层处理复杂运算从单体应用过渡到垂直应用架构开始出现包含公共逻辑的接口上层PHP调用下层Java应用为主HTTP+JSON方式通信使用共享的Command结构进行交互Java内部高效通信PHP等多种语言仅消费服务统一的服务发现机制JSON序列化协议贴近原有数据

2、结构与交互方式灵活性、可读性业务接口复杂度可控Redis传输协议相比HTTP更加简洁高效多语言客户端丰富、稳定节省传输层开发成本Redis vs ZooKeeper满足变更通知与高可用的需求使用和运维经验更加丰富架构优化扩展一主多从分担压力路由层服务增加缓存减少QPS订阅不同服务使用单链接多Channel通过域名访问服务DNS解析到LVS服务器加入HAProxy解决网段受限的问题地址来源分层，组成责任链结构开关灵活控制功能开启完善监控机制仅有本地日志，没有统一的监控系统异步调用支持框架内部实现功能有限，使用场景日趋复杂数据采集通过SDK统计分钟为周期提交Redis队列传输监控项精确到方法百分位

3、时间线程、GC针对异步调用需求开发独立产品Broker、队列、Worker三种角色支持调用Service与HTTP接口增加Kafka队列模式解决请求堆积问题日志平台服务器数量增多，日志查找成本剧增分布式跟踪系统调用链路复杂，依赖关系难以梳理原理Agent采集Kafka、Storm中转HDFS存储场景多服务器日志查看滚动冲刷日志回溯分析数据采集原理制定链路日志规范分层记录、统一收集唯一ID关联还原场景调用链路分析单次慢请求分析链路异常报警并行调用代理PHP作为大量服务的调用方，无法实现并行调用多语言发布代理其他语言开始有抽取公共服务接口的需求Java开发代理服务请求打包发送至代理服务代理并行执行，打包返回响应标记失败请求，由调用方处理服务框架改造成Proxy Server同时部署Proxy与业务进程以公有协议（Fast CGI）传递Request复用框架原有的服务发现、服务治理、监控等机制降级、限流系统稳定性成为首要目标，快速从异常中恢复容器化实现资源合理利用、灵活调度由基础镜像创建构建环境拉取代码构建应用创建应用镜像推送至应用仓库由应用镜像创建应用实例应用实例由k8s进行调度微服务（Microservice）细粒度、独立运行、轻量通信服务网格（Service Mesh）服务间的通信机制作为更底层的设施预装轻量的通信代理，构成通信网格