个人的服务开发经验总结：
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，更多的从库
一般规律是：从库复制 -> 停写 -> 切换
找业务量最小的时候上线