当前位置: 代码迷 >> 综合 >> 大型网站架构设计---经验总结
  详细解决方案

大型网站架构设计---经验总结

热度:52   发布时间:2023-12-07 22:52:14.0
个人的服务开发经验总结:

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,更多的从库
一般规律是:从库复制 -> 停写 -> 切换
找业务量最小的时候上线
  相关解决方案