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

  不管是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 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

SDN中的Segment Routing

作者简介:晏志文,原就职于中兴通讯,目前供职于安徽皖通邮电股份有限公司。数通测试专家,本领域从业深耕多年,熟悉传统网络技术及行业解决方案,密切关注新兴网络,IC...

1924
来自专栏铭毅天下

Elasticsearch学习,请先看这一篇!

题记 Elasticsearch研究有一段时间了,现特将Elasticsearch相关核心知识、原理从初学者认知、学习的角度,从以下9个方面进行详细梳理。欢迎讨...

1.4K14
来自专栏腾讯Bugly的专栏

《iOS APP 性能检测》

| 导语 最近组里在做性能优化,既然要优化,就首先要有指标来描述性能水平,并且可以检测到这些指标,通过指标值的变化来看优化效果,于是笔者调研了iOS APP性能...

1.3K5
来自专栏P2P传输

.torrent文件该如何理解?BT种子的技术原理是什么?

1、torrent文件的原理:如果这个问题是指torrent文件本身,那么,当你对一个文件(或者文件夹)制作成.torrent文件,实际上生成的.torre...

1300
来自专栏chafezhou

小说python操作PLC

PLC(Programmable Logic Controller)可编程逻辑控制器,可以理解为一个微型计算机,广泛应用于工业控制中,如楼宇智控、精密机床、汽车...

1K2
来自专栏腾讯NEXT学位

webpack 4 测试版 —— 现在让我们先一睹为快吧!

3385
来自专栏Android干货园

Android 轻松实现百度地图定位

版权声明:本文为博主原创文章,转载请标明出处。 https://blog.csdn.net/lyhhj/article/details/49...

2441
来自专栏腾讯架构师的专栏

云计算时代的数据库核弹头 : Tencent MySQL ( TXSQL)

作为腾讯规模最大的 MySQL 数据库服务,CDB 在腾讯云上也是最受欢迎的关系型数据库产品。CDB 不仅具备备份回档、监控、快速扩容等数据库运维的全套解决方案...

6330
来自专栏社区的朋友们

埋在MYSQL数据库应用中的17个关键问题!

Mysql的使用非常普遍,跟mysql有关的话题也非常多。要想掌握其中的精髓,可得花费不少功力,虽然目前流行的mysql替代方案有很多,可是从最小成本最容易维护...

2.3K2
来自专栏Golang语言社区

Hulu大规模容器调度系统Capos

Hulu是美国领先的互联网专业视频服务平台,目前在美国拥有超过2000万付费用户。Hulu总部位于美国洛杉矶,北京办公室是仅次于总部的第二大研发中心,也是从Hu...

1443

扫码关注云+社区