一、接口定义
1.区分业务级异常及系统级异常。
系统级异常：抛出异常
业务级异常： 返回不同的业务代码
----这样根据异常可以区别是系统级的还是业务级的
a):对于http接口，返回如 ：{"sysCode":0,sysMessage:"成功",busiCode:0,busiMessage:"",result:{}}
sysCode==0 为系统级成功，其它值为系统级失败，系统级失败，就不要限业务返回值了。
busiCode==0,业务成功。其它值，业务失败。
这种方式实际上有三级状态码：
1. httpstatus==200 ,http请求成功
2. syscode== 0 ，系统执行成功（未异常）
3. busiCode==0，业务级执行成功
以上三步成功了，再取result结果值。
b):对于rpc接口：
1.调用接口未异常，则说明系统执行功能
2.返回值对象busiCode==0，说明业务级成功
以上两步成功了，再取result结果。
2.返回值：多次调用接口，返回的数据结构与语义要一致。
如果返回值是一个json,这个json全量的属性有100个，那么无论这100个属性，有没有值，都需要返回。
如果只返回有值的，那么当数据有变化时（某属性从无值变有值），接口返回的数据格式(json中的属性数)与上一次不一致了（多个某个属性）。
二、超时问题
1.一个服务在确定了主机环境与相关的数据库，redis等，它的能处理的最高tps基本上就确定了。
用压力测试测出单个服务的最高tps ,以该tps 的60%为预警值，实时计算线上服务当前的tps,如果超过
预警值，就告警，以扩展服务个数，缓解压力。
就是要知道这个服务能干多少活，不能超过太多。
2.同理对于数据库，在环境确定的情况下，测试其最大的tps ,以该tps 的60%为预警值，以使及时知道问题，为数据库更换性能更好的主机 或分库。
3.
三、数据核对
新应用上线后，初期定时扫描数据，做附合业务规则的核对，有可能发现异常数据，找到应用问题
四、监控
1.请求数量变化监控
2.线上定时请求返回正确结果监控
3.应用端口监控
4.主机监控
5.
1.接口定义，明确入参，返回值，返回值各种状态
2.单元测试，覆盖返回值各种情况
3.分层：接口层，缓存层，业务逻辑聚合层，模块功能层，DAO层
各层尽量用接口描述
4.区分强依赖及弱依赖，
强依赖：成功或快速失败，
弱依赖：走异步，不影响业务线程
5.数据库表：大表拆小表，按索引查询，尽量不做表关联查询
6.MQ消费服务，独立部署
7.压力测试：平均响应时间毫秒级
8.线上自动化测试--验证线上业务可用性