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

个人的服务开发经验总结：

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，更多的从库

一般规律是：从库复制 -> 停写 -> 切换

找业务量最小的时候上线