前言：从去年3月份入职到现在刚好一年半,在这一年半的时间里一直负责部门的资源服务开发与搭建,由于公司战略的调整我负责的这个服务需要交接到别的部门。因为在负责服务的一年半中遇到太多太多坑,也受到太多的批评和质疑,不过很幸运自己坚挺下来了,服务日访问量也由刚接手时候的8千变成2.0亿,业务方也扩大近一倍,今天我在这里把所有的经验与大家分享,希望大家以后在做服务时候少走弯路。
一：基础服务应该考虑的事项 1、基础服务的定义当接手一个新服务的时候我们就必须搞明白下面2件事:
这个服务的定位
这个服务承担的职责
我在工作中有次领导突然问我你能告诉我资源服务是什么吗,当时我有点晕圈,半天没有回答出来,因为我一直在根据业务方需求或者pm来开发自己玩去处于一个被动的角色,所以那次对话给我带来的震惊挺大的。从那以后我就经常想我的服务是什么,后来就明白了它就是一个基于资源的库存系统,既然是库存系统那么它应该具有哪些能力呢,无非就是添加、消耗、返点、冻结、解冻、转账等功能,当我们明白这些功能后我们就清楚哪些是我们开发所承担的能力,哪些不属于我们承担的能力,以至于后期我对我的服务进行大量解耦(比如一个用户想获取资源还进行判断是不是会员,其实他并不属于我们服务职责,那么类似这样的业务需求我们就应该果断抛给业务方)
2、基础服务的文档我在做服务的初期并不存在文档,但是慢慢发现文档在整个服务中也处于一个非常重要的角色,因为新每个业务方需要接入服务的时候你不能每次都直接口述,那样会耽误太多精力,而且很多接入服务出现的问题没有文档的记录也可能会丢失,这样一来新接入的业务方可能会出现同样的问题,为我们开发带来大大的不便(文档最好是准备2份,一份用wiki写接入文档,另一个是接口文档)。下面总结下wiki文档主要的内容
服务专业名字解释
服务负责人以及联系方式
服务配置说明(如版本号、沙箱ip等)
服务接口说明
服务调用demo
常见问题说明
3、服务的性能性能是每个服务都需要关注的点,但是我们在设计服务初期就应该有一个性能指标,比如我们操作接口平均响应时长控制在30ms以内,查询接口响应时长控制在10ms以内(这些指标可以根据业务方的需要来,比如一个下单功能整体要求是500ms可能分到我们提供的接口只有50ms),因为任何性能都是有一定标准的我们就围绕这个标准去打造,性能优化指标可以参考我以前的一篇文章(https://www.cnblogs.com/LipeiNet/p/6379579.html)
4、服务的高可用服务的高可用可以采取负载均衡来保证一台机器宕机从而不影响整体,目前我们并没有采用技术方面来保证高可用
4、服务的并发并发基本大多服务都会面临,一旦服务出现并发很可能造成了数据安全性出现问题,比如我们服务A用户请求资源然后进行消耗,同一时间A用户继续请求资源进行消耗,那么导致的后果就是A消耗了2次资源但是只扣一次点,这样一来服务就是出现问题,解决这个问题通常我们采用锁,锁主要分2种乐观锁和悲观锁。
悲观锁：认为所有的请求都会发生并发,所以悲观锁会对每一个请求加锁,单点常用的悲观锁有synchronized和lock,具体这两种锁区别大家可以自己百度,当然另外如果服务是分布式的,那么就需要采用分布式锁,常用的分布式锁有基于redis和Zookeeper来实现的,我们这边采用的是基于redis锁,因为对性能要求比较高
乐观锁：认为所有的请求都不会发送并发,一般常用cas锁来解决,就是先比后更的模式。如对数据加入版本号,获取数据时候记录版本号,如果更新时的版本号和获取时不一致则抛出异常
5、服务的一致性服务一致性我在这里来说明2种情况,一种是服务本身数据的一致性,另外是和调用方保持一致性.
调用方保持一致性：
我们服务提供幂等,当调用方出现超时或异常在次调用服务我们将会返回订单重复提交,调用方可以根据返回值来判断这个操作对自己业务而言是否是正确的.幂等我们服务采用的是永久性幂等,这样做法其实有缺陷,因为量级太大会占用很大的数据库资源,所以可以优化成对于添加采用永久性幂等,而一些消耗采用非永久性幂等,这样一来就可以对幂等数据做归档,就会减少数据库资源的利用。
服务本身一致性：