大型网站架构设计---经验总结
来源:互联网 发布:送货单软件排行 编辑:程序博客网 时间:2024/05/17 02:56
个人的服务开发经验总结:
Web API服务:
1)负载均衡
固定用户的请求,重定向到固定机房(机器),因为机房之间数据的replication有延迟,这样可以保证每个用户访问的数据都是没有延迟的;
2)防止雪崩
挡住同IP频繁的相同请求
3)精简返回给用户的数据
减少网络流量和传输时间,开辟空间小,服务压力小
4)API调用下层服务时,异步调用(MQ),超时处理
耗时久的异步调用,和其他服务调用并发处理,减少等待;支线服务的调用异常不能影响主线服务的返回,支线服务挂了,仍然返回数据
5)统计Log
api的log直接记录了用户的行为,可以分析做很多事情:用户画像,推荐,个性化
6)灰度发布
基于api层做灰度发布,在api层做用户id过滤,只对满足条件的用户展示响应的内容
Service层服务:
1)每个接口的时间消耗统计
service的性能分析,很重要的依据
2)最大限度利用本地缓存
减少网络延迟,磁盘io延迟
3)高并发服务不允许复杂的SQL操作
复杂的SQL操作在DB中执行时间过长,阻碍了并发;还有一个原因是,如果有复杂的连表查询,以后会影响分库分表
4)怎么解决DB中复杂的查询呢
加载到内存在内存中做
根据实际应用场景,离线处理好数据,DB中保存用户直接展示的数据
Web API和Service共同需要的经验:
1)无缝发布
上线,不能影响用户体验
2)低延迟响应所有请求
3)分布式部署,多机房,多机器
机房可能出故障,单个机房要能抗住所有压力,单个机房要部署有所有的重要服务
4)RPC接口,经验数据
API调用RPC接口,量大时,数据的序列化和反序列化是瓶颈
5)服务性能监控
机器的监控,服务返回值的监控,异常日志报警,超时报警
6)GC调优
7)压力测试
单机测试,线上服务器测试,逐步的调权重
用历史请求模拟用户请求,这个是最安全的
对所有服务进行预估,必须对所有服务的上限做到心中有数
实时的扩展机器,必须还能做到有机器剩余,能够实时添加进去作为临时扩展
数据层的经验:
1)DB选取、文件系统选取
关系型数据库、nosql数据库、hdfs还是redis?根据业务场景选择,不同的细粒度服务不同的选择,一定要考虑数据规模和扩展性
2)初始,估计好数据的规模
好的DB选择,好的分库分表
3)数据的sharding,读写分离
中间件、代码中
4)根据应用场景决定库、表的设计
读多写少、读写均衡、写多度少
5)扩容、迁移
更大的sharding,更多的从库
一般规律是:从库复制 -> 停写 -> 切换
找业务量最小的时候上线
0 0
- 大型网站架构设计---经验总结
- 大型网站架构设计
- 大型网站架构设计
- 大型网站架构设计
- 大型网站架构设计摘要
- 读大型网站架构设计
- 大型网站架构设计-读书笔记
- 一、大型网站架构设计
- J2EE大型网站架构设计一点总结
- 大型网站架构设计(转载)
- 大型网站架构设计及技术总结
- 高并发大型网站架构设计
- 高并发大型网站架构设计
- 大型网站架构设计及技术分析
- 高并发大型网站架构设计
- 大型网站的服务器架构设计
- 大型分布式网站架构设计与实践
- 高并发大型网站架构设计
- Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK fla
- 移动定位业务之“A-GPS(辅助全球卫星定位系统)”
- 移动定位业务之“Cell ID + RTT(小区识别+往返时间)”
- Spring 注解通过@Autowired,@Resource,@Qualifier,@PostConstruct,@PreDestroy注入属性详解
- VM8下RedHat9上网配置,vsftpd同样可以用
- 大型网站架构设计---经验总结
- Java与C++之JNI编程小结
- 陌陌私有化 雷多易吐槽速来
- pkdbf2算法
- VS2010 Visual Assist X破解方法
- Android利用Fiddler进行网络数据抓包
- spm结课项目成果展示
- linux 内核调试指南
- 关于different time的几种方法