以尝试压缩cache中的数据,分单系统会导致DB压力过大,这个时候可以适当的进行调整来消去峰值。柔性:对系统重新进行分析,看清业务与系统开销的对应关系。不常用的二级服务选择性的进行停用。对服务分级,对某些一级服务可以进行降级。扩容:数据库硬件升级,Push服务集群化改造,开发定制化LBS服务算法替代Redis以及MongoDB。然而以上这些应对办法,也只是治标不治本,无法根治方案B所展现出来的各种问题,而这个时候方案C就孕育而生了。图6给出了方案C的架构图、提示:方案C的改造成本以及建造会非常高,但是可以根本上解决问题,因此一般情况下不会选择方案C,除非做到了滴滴这样全国性出行服务规模。图6架构方案C示意图图6只是给出了方案C的总览图,其中每一个虚线块都可以成立一个项目组单拉出来进行研发,例如图6左下方的数据同步系统,其中包括了DB集群、KV集群等。下面给出了方案C的参数特点。支撑并发流量在5亿左右架构服务化,并且分城市部署,每个重要城市自选IDC机房。成本则需要50+的研发团队以及7个人左右的运维团队。支持SPDY协议,SPDY协议是Google提出的基于传输控制协议(TCP)的应用层协议,通过压缩、多路复用和优先级来缩短加载时间。该协议是一种更加快速的内容传输协议。使用DevOps开发运营模式,为了按时交付软件产品和服务,开发和运营工作必须紧密合作。尝试建立内部私有云,通过云技术、大数据的优势解决一些复杂的问题。5总结本文档分别从预期目标、功能框架、技术体系以及架构体系这4个方面对打车APP的解决方案进行了系统的描述,让所有人在项目动工之前对项目的总体情况有了大致的了解。其中架构方案这里也从简单到复杂给出了三套架构方案,以适合企业不同时期的发展,并满足了软件的可扩展性。----------THEEND,THEREISNOTXTFOLLOWING.------------
全文预览
