架构设计从这5点考虑,能帮后期运维很大忙!

系统运维 来源:netease_im 20℃ 0评论


周梁伟|云信 IM即时通讯云服务器端开发负责人·


1.良好的系统架构是顺利开展运维工作的前提

在做系统架构设计时需要充分考虑功能模块的耦合性,尽量做到业务功能的独立解耦,降低互相之间的依赖;最差的情况就是所有的服务功能集中在一个进程中,一个挂,全部挂,一个升级全部受影响,这种系统设计对运维工作来说就是灾难;做好功能模块的划分和隔离,可以降低故障的影响范围,在升级等日常运维工作中也可以做更好的规划;


 

2. 架构设计时将HA作为必须满足的非功能性指标

任何一个系统都会存在故障的可能,程序猿写的代码即时再好也有出bug的时候,即时程序不出bug,也还是逃不过机器宕机后者断电断网等各种意外情况的发生;所以设计者需要善于找到系统中存在的单点,并解决这些单点;高可用的特性并不是说要求程序一定不能挂,而是说从架构上允许故障的发生,任何一个节点的故障只能影响系统的整体处理性能,但是不会造成业务不可用;具体来说,如果是Web类的应用,可以使用Nginx等反向代理工具来搭建多个后端的业务集群,并在出口上做Keepalived等高可用的方案,对于一般的应用,设计时需要保证多实例可同时服务,多实例功能相互对等,任何一个实例的停服,其业务请求可以被其他实例来分担;做好了HA架构,我们在运维工作时才能更加从容,因为当运维报警发生时,我们知道当前业务处理能力虽然下降了,但是整个业务并不是不可用的状态,对用户来说不会产生直接的影响,运维人员可以从容得恢复故障节点即可;同时良好的HA架构也有助于业务扩张时的增强系统扩展性;


 

3. 业务系统给运维系统提供更加友好的接口

运维平台的一个重要工作是从业务系统中提取到准确的指标,并针对这些指标来做线上的监控和预警;更加了解业务系统的还是开发人员,而非运维人员,所以开发人员需要在设计功能时同时兼顾到运维的需求,充分设计哪些指标需要被暴露出来,常见的比如当前系统的TPS(每秒的处理能力)MRT(平均响应时间),系统的能力上限等,再结合如JVM内存使用情况,GC情况等基础数据,运维平台就能做出更加合理的监控支持,有了这些监控数据之后再制定更加科学的预警,可以在故障实际发生之前就做出预警(比如TPS达到系统容量的80%了),让运维人员提前做出扩容等应对,而不是等到功能不可用了才报警;从技术实现上来说,业务系统向外暴露接口的方式就非常多了,比如JAVA程序可以通过JMX来实现,通用的进程可以使用隐藏的Http接口等方式来实现;如果运维平台使用的是Ganglia等开源平台,也可以使用对应的客户端Agent来向运维平台暴露数据;


 

4. 规范的日志输出

很多开发者在实现业务系统的时候往往会忽略日志的作用,或者只把日志当做偶尔查查问问的工具,日志的输出内容往往是只有人来读取的非格式化内容;其实除了定位问题之外,日志还可以帮助我们做更多的事情,我们可以设计一个程序友好的日志格式,比如输出JSON格式的日志来记录每个业务请求的执行情况,如请求参数,处理时间和响应码,失败信息等;有了规范的日志之后,可以通过脚本的方式将日志中的信息提取成指标输入到运维平台中,可以对业务系统当前处理的成功率,响应时间等做更加细粒度监控和报警;


 

5. 善于利用功能测试框架

很多公司对开发人员的代码质量要求都很高,会要求在QA测试之前做到单元测试等工作,有些QA部门也会利用一些标准化的工具对线上流程做回归测试,比如Junit或者TestNG等;其实我们也可以充分利用这些资源来做线上的运维监控;我们退一万步来说,如果一个系统没有任何运维预警,那么如果线上发现问题的会是谁?这一定是用户,那么能不能有一个机器人用户来帮我们提前发现问题呢?这里我们就可以利用功能测试的成果了,将用作线上回归的TestNG代码用程序自动化的方式定期执行起来,并解析执行的结果,如果回归测试失败就立刻发报警出来,这种看起来很土的方法在实际操作中。