我的笔记

 

一、接口定义

   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.线上自动化测试--验证线上业务可用性