架构必会的性能指标及分析策略

  不管是java还是.net基础设施必不可少。

MQ:

  如果发现MQ是瓶颈。不管用的是rabbitmq还是kafka,其他的也好。作为生产者要确认超时时间、重试机制、异步线程池。消费方要做两件事:发现和解决。发现的主要是通过积压阈值最快发现问题。解决的方法主要有:短期方案:增大线程数,增加服务器。长期需要优化逻辑。积压阈值的设置主要取决于对积压的容忍程度,比如我们的服务对延时很敏感,那么设置积压阈值为50或者100。这样有问题可以快速发现。

缓存:

   缓存的话,不管是tair还是redis或者memcached。我们对缓存的写入成功和数据存在性都不能强依赖。所以基本要做到缓存读取不成功就需要再次查DB。而且不管出什么问题,对程序来说,就是抛异常了。所以一定要异常捕获。数据要用异步线程池异步写入。监控要做好。我们有个服务要做一层缓存。我们组的兄弟比较担心,问我了解不了解冷热启动的概念。这个其实需要去咨询维护服务的人怎么定义这个概念。一般来讲:冷启动数据是从磁盘加载的,热启动是从内存加载的。

超时和重试:

  为了防止别的服务出问题,一定优化好超时时间和重试机制。超时时间的定义一般设置为一个请求处理99.9%的耗时时间的5到10倍。这是因为考虑到跨机房等网络耗时的问题。虽然运维的同事会告诉说跨机房之间的时延也就是1ms或者2ms的事情,但是实际值要大于这个值,所以一般设置超时时间是100ms起步。很多请求设置了这个值还是超时了,没关系,就是截获一个异常然后重试。如果服务不重要,比如展示的时候,去取一个展示的key的字典值,也可以不重试。一般的RPC组件默认重试是3次。

  一般超时的异常有以下特征:

java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy67.xxxx(Unknown Source)
at 

Caused by: org.apache.thrift.TException: tthrift remote(IP:端口) invoke(xxxx) timeout, traceId:-2093033244087395764, timeout:100

  Unknown Source:远程问题的特征之一

  timeout是超时的特征

服务隔离:

  服务隔离是为了减少损失的影响范围,避免雪崩效应。比如我们有一些外部的依赖:我们依赖微信支付的稳定性、支付宝支付的稳定性、银联支付的稳定性。那么我需要按照这几种通道做物理隔离,可以部署相同的代码但是部署在不同的机器群。

组件版本及时升级:

  比如httpclient4.3的版本有个bug并发量大的时候会阻塞。之前在乐视的时候,部门有个小组的服务就发生过这样的线上问题。

及时下线不再使用的代码:

  可能在一个团队中很多程序bug都是因为存在太多的兼容逻辑和临时代码,写这些逻辑的人如果没有加上很好的注释,在用完的时候也没有及时清理。后来维护的人看到这段毫无道理的代码不敢动。程序里大量的IF和ELSE,很容易踩坑。招聘的时候卡的很严,很多面试者不服气,我也能写出来代码。但是会写代码和会写代码是不一样的。我们需求很急,但是宁愿不做也不要一个写出一堆问题代码,处处是坑,难以维护代码的程序员。

数据库:

  一个数据表的数据过多,对更新和查询性能都有影响。对于不再使用的数据要及时备份清走。一般数据库的容量剩余不到60%, 就要考虑分库分表了。一般一台物理机写入能力也不能高于QPS1500。所以对于主从延时不是很敏感的业务场景,一定要做好读写分离。虽然做了读写分离,如果读和写的代码在一个事务里,其实都是走的主库。杜绝慢查询。

梳理好依赖:

  开发一个系统,最忌讳的是没有灵魂。来什么需求都接。把系统搞得很乱。梳理好系统的边界和定位。我们应该依赖什么服务,是强依赖还是可以降级的弱依赖。调用系统的调用方需要什么东西,我们是应该给提供,还是让他们自己去解决。

总结:

  上面提到的哪一步没有做好,都可能引发蝴蝶效应。比如:一个MQ的消费能力差,积压了,生产者同步写入,写入等待。另外一个服务调用了这个接口,还把这个调用包裹到事务里,导致这个事务长时间不提交。这样的请求来几个,线程池满了,整个服务就挂了。如果别人调用这个服务,超时时间设置的过长,别的服务也跟着线程池满,挂掉了。如果没做好物理隔离,所有服务都挂了。

跑题时间:

  玛格丽特.米切尔写的《飘》英文原名是《gone with the wind》,意思是美国南部的奴隶制文明一去不返,中文的翻译完全没有这种韵味。女主人公斯嘉丽爱慕阿希礼的高贵气质,冒着生命危险为他做了很多的事情。而阿希礼只在斯嘉丽需要的时候给了她一把土。当时光沉淀了一切,斯嘉丽意识到自己爱上的只是自己想象出来的一个人,基于阿希礼。阿希礼只是空有一副皮囊,他的灵魂基于他的妻子梅兰。而斯嘉丽自己的丈夫白瑞德才更配的上自己的灵魂。爱情来的时候本来就是毫无道理,而自己困境中望着你,你一次次将我逼进绝望。我一次次从绝望中翻身的强大会将你从心里挤走。一个再坚强的女孩子最后也会爱上让自己不用坚强的人。

  喜欢做鱼头鸡汤。鱼肉可以做出很多种花样,而鱼头吃起来比较费劲,骨头多,做汤最好。鸡片入锅,加上水豆豉,枸杞、姜片、甘草。将鱼头放到笊篱里,水煮到笊篱里只剩鱼骨,将笊篱拿出。关火装盘即可。好汤关键是食材,食材越好,调料可以越少。

  世界上最遥远的距离是鱼和飞鸟的距离,一个在天际一个却深潜水底。我却偏偏想让他们在一起。即使不用一起成为汤,他们也可以在水面的一瞬间相遇。世界上最遥远的距离是我变成了你最喜欢的样子站在你面前,却不喜欢你。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏岑玉海

RChain的跨分片交易算法

1252
来自专栏ImportSource

NoSQL Sharding 分片

翻译内容: NoSQL Distilled 第四章 Distribution Models 作者简介: ? 本节摘要: 各位周末好,今天我们主...

35212
来自专栏H2Cloud

H2Engine服务器引擎介绍

H2Engine服务器引擎介绍 简介   H2Engine服务器引擎架构是轻量级的,与其说是引擎,个人觉得称之为平台更为合适。因为它封装的功能非常精简,但是提供...

4158
来自专栏编程一生

业务高速增长场景下的稳定性建设实战

1362
来自专栏北京马哥教育

从解决Redis访问超时的问题谈起——故事比结果要精彩

这周终于解决了Redis访问经常超时的问题,终于可以踏实睡觉了。从上周就开始纠结在这个问题上,可以用寝食难安来形容,感觉这个问题就像个定时炸弹一样,虽然根据手搜...

3305
来自专栏IT大咖说

一位前端专家构建GraphQL工程的心路历程

内容来源:2018 年 6 月 9 日,国内某大型电商公司用户体验部门前端开发专家邓若奇在“杭州第一届 GraphQLParty—GraphQL与领域驱动带来的...

1281
来自专栏尜尜人物的专栏

数据库之架构:主备+分库?主从+读写分离?

注:图中圈出的是数据同步的地方,数据同步(从库从主库拉取binlog日志,再执行一遍)是需要时间的,这个同步时间内主库和从库的数据会存在不一致的情况。如果同步过...

962
来自专栏北京马哥教育

Redis集群技术

1. Redis常见集群技术 长期以来,Redis本身仅支持单实例,内存一般最多10~20GB。这无法支撑大型线上业务系统的需求。而且也造成资源的利用率过低——...

2937
来自专栏java一日一条

高并发系统的设计及秒杀实践

一个大型网站应用一般都是从最初小规模网站甚至是单机应用发展而来的,为了让系统能够支持足够大的业务量,从前端到后端也采用了各种各样技术,前端静态资源压缩整合、使用...

803
来自专栏JAVA技术zhai

优化不易,且写且珍惜!

本文要感谢我职级评定过程中的一位评委,他建议把之前所做的各种性能优化的案例和方案加以提炼、总结,以文档的形式沉淀下来,并在内部进行分享。力求达到如下效果:

4037

扫码关注云+社区