服务开发需考虑的事项
2016-11-17 11:47
246 查看
开发一个服务不是简单的将服务功能实现,程序能跑这么简单,还需要考虑到各个方面,这里大致总结了几点,整理如下:
逻辑正确,首先要保证程序的运行结果符合预期;
方便修改,比如有些参数可能会修改,(1)这些就可以放到配置信息里,运行时,只需要改下配置,重启或者热修改,新的参数/配置就可以生效了;(2)还可以通过发送信号,与服务交互,服务代码中包含信号处理的逻辑,不同的信号,代表不同的信息;
性能问题,现在的实现能否符合性能要求,比如QPS,连接数,响应时间,延迟,吞吐量;
服务降级,遇到请求量激增,比如零点秒杀类似的情况,为了增加性能,一种情况是服务本身的某些逻辑停止运行,另一种情况是调用其他服务的接口停止调用,这些情况都需要留有开关,在需要降级时,将开关关闭,以求缩短请求处理时间,提高服务性能;
资源使用,正常情况下,对CPU,内存,网络带宽,磁盘,打开文件数,等等的使用情况,随着服务压力的增加,要对资源使用情况进行评估,资源是否可以满足需要;
重启/停止,能否做到不影响正常服务的情况下重启,比如像Redis做到的,在服务停止时,需要考虑到内存中的数据要会丢失,如果不想丢失,采用的措施比如可以通过拦截停止的信号,等内存中的数据全部处理完毕后,再安全退出;
状态监控,时刻了解服务运行状态,比如当前的QPS,处理单个请求平均时长,消费kafka到哪个点了有没有积压等,业务不同, 具体指标也不同,要么记录在日志文件里,或者通过图表界面展示出来;
异常告警,可以跟第7点归到一起,在各种运行状态的基础上,设定阈值,当超过阈值时,通过邮件、短信、微信、电话等方式告警;
上线部署,服务要做到方便部署,集群化管理,配置信息放哪里,使用配置文件还是配置文件搭配zookeeper,启动/停止脚本等;
扩容/缩容,能否做到只通过增加机器或者一台通过增加进程/线程,就可以做到平行扩容,性能提升,这也要求在设计时,就要考虑到多进程/多线程的问题,进程间的通信是通过共享内存、管道等还是通过TCP Socket;
追补数据,如果出现异常终止,比如core dump,处理不及时,需要有补救的方案,减少损失;
服务外资源和服务,一个应用很难不跟自身以外的服务或资源打交道,比如需要使用缓存(Redis/memcached等),需要调用其他服务的接口获取某些数据,这也就需要考虑到这些资源或者服务的可用性以及性能,之间通信的网络开销和延迟,对其他的资源或者服务的可用性和性能也要监控,比如返回值中无效结果量,如果某个时间点突然增加,就要联系他们,查找原因;如果请求回复之间的时间间隔突然增加,正常是1ms,增加到了10ms,就要查下是对方的服务出问题了,还是网络负载太高引起的;
日志定位,服务中的日志输出要有明确的格式,并且在关键路径处,比如调用接口、请求别人的服务等,都需要有日志输出;
服务端程序考虑的远不止这些,这里只是列出了几条最常见的需要考虑的条目
逻辑正确,首先要保证程序的运行结果符合预期;
方便修改,比如有些参数可能会修改,(1)这些就可以放到配置信息里,运行时,只需要改下配置,重启或者热修改,新的参数/配置就可以生效了;(2)还可以通过发送信号,与服务交互,服务代码中包含信号处理的逻辑,不同的信号,代表不同的信息;
性能问题,现在的实现能否符合性能要求,比如QPS,连接数,响应时间,延迟,吞吐量;
服务降级,遇到请求量激增,比如零点秒杀类似的情况,为了增加性能,一种情况是服务本身的某些逻辑停止运行,另一种情况是调用其他服务的接口停止调用,这些情况都需要留有开关,在需要降级时,将开关关闭,以求缩短请求处理时间,提高服务性能;
资源使用,正常情况下,对CPU,内存,网络带宽,磁盘,打开文件数,等等的使用情况,随着服务压力的增加,要对资源使用情况进行评估,资源是否可以满足需要;
重启/停止,能否做到不影响正常服务的情况下重启,比如像Redis做到的,在服务停止时,需要考虑到内存中的数据要会丢失,如果不想丢失,采用的措施比如可以通过拦截停止的信号,等内存中的数据全部处理完毕后,再安全退出;
状态监控,时刻了解服务运行状态,比如当前的QPS,处理单个请求平均时长,消费kafka到哪个点了有没有积压等,业务不同, 具体指标也不同,要么记录在日志文件里,或者通过图表界面展示出来;
异常告警,可以跟第7点归到一起,在各种运行状态的基础上,设定阈值,当超过阈值时,通过邮件、短信、微信、电话等方式告警;
上线部署,服务要做到方便部署,集群化管理,配置信息放哪里,使用配置文件还是配置文件搭配zookeeper,启动/停止脚本等;
扩容/缩容,能否做到只通过增加机器或者一台通过增加进程/线程,就可以做到平行扩容,性能提升,这也要求在设计时,就要考虑到多进程/多线程的问题,进程间的通信是通过共享内存、管道等还是通过TCP Socket;
追补数据,如果出现异常终止,比如core dump,处理不及时,需要有补救的方案,减少损失;
服务外资源和服务,一个应用很难不跟自身以外的服务或资源打交道,比如需要使用缓存(Redis/memcached等),需要调用其他服务的接口获取某些数据,这也就需要考虑到这些资源或者服务的可用性以及性能,之间通信的网络开销和延迟,对其他的资源或者服务的可用性和性能也要监控,比如返回值中无效结果量,如果某个时间点突然增加,就要联系他们,查找原因;如果请求回复之间的时间间隔突然增加,正常是1ms,增加到了10ms,就要查下是对方的服务出问题了,还是网络负载太高引起的;
日志定位,服务中的日志输出要有明确的格式,并且在关键路径处,比如调用接口、请求别人的服务等,都需要有日志输出;
服务端程序考虑的远不止这些,这里只是列出了几条最常见的需要考虑的条目
相关文章推荐
- 开发Adobe AIR移动应用程序的考虑事项
- [开发笔记]-Windows Service服务相关注意事项
- ArcGIS Server SOEs开发前应考虑的事项
- 中小型服务开发的主要事项
- 微服务开发过程中需要注意的若干事项
- 微服务开发过程中需要注意的若干事项
- 大数据24小时:诺基亚推出物联网服务正式入局区块链,伊朗考虑开发自己的加密数字货币
- 企业应用:C/S 开发需要考虑的事项
- 中小型服务开发的主要事项
- Vertx-blueprint:Vert.x 蓝图 - 待办事项服务开发教程(读后感)
- 关于服务程序开发的几点注意事项
- 当前框架下微服务开发注意事项 @Arthur
- 开发Adobe AIR移动应用程序的考虑事项
- 开发Adobe AIR移动应用程序的考虑事项
- 开发服务端程序,在存在并发请求场景下,需要考虑一些常规事项简单梳理和总结
- 标题:化繁为简-使用Weblogic WorkShop8.1开发Web 服务
- 用 XML-RPC 开发 Web 服务:XML-RPC 中间件
- 用Eclipse开发JSP篇——2.建立lomboz项目注意事项
- J2EE Web服务开发系列之十三: 实现安全的AXIS Web服务,第2部分