程序员的自我修养
Home » 文章归档 » 2016年十一月

架构师做什么?

0条评论859次浏览

记得我最早思考这个问题的时候还在国企,那会刚参加工作没多久。某天突然看到有人的职位是架构师,于是很好奇,作为一个架构师,他/她的日常工作是做什么?或者这么说,你要能够做些什么,才能成为一个架构师?

然而,作为一个低端码农,对这个问题一直无解。而且还受到国企那些架构师的影响,一度以为架构师就是一群没能力做开发,只会满嘴空炮,开一个又一个浪费生命的会议,写一堆自己都不愿看第二遍的文档的复制粘贴机器。

前几天梳理后端架构,过程中有很多想法,例如这里当初这么设计不是没事找事?这样设计这个模块岂不是没法扩展?当初要是不这样设计现在工作量岂止减少10倍?!突然间我意识到,架构师的工作,是不是就是处理这样的事情——让系统/服务/产品等后期更容易维护/扩展,不至于被后来者诅咒?

程序员为自己写的代码负责,为自己弄出来的bug买单。除此之外,一个系统/服务/产品是否就没有其他方面的问题了?比如程序员按照设计用redis来缓存数据,现在内存不够用了,是程序员的锅吗?当初采用了http+json作为内部通信协议,现在随着业务增长和新的需求,发现http+json的效率更不上了,是谁的锅?某个mysql表的字段设计成了text,导致现在稍微大量点的写入就主从延迟超过阈值,这是谁的锅?

诸如此类,或大或小、或轻或重的问题,我想应该就是架构师来处理的吧。

对于架构师做什么,现在只有这点浅薄的认知,希望以后成为架构师(不是国考的系统架构师)后再写文章补充吧。

如何成为架构师?我觉得除了脑子必须特别好用这种基本要求外,还需要丰富的经验和特别广的知识面,而且需要专精一两个领域。

比如你得知道kafka作为MQ,可靠性有多少,TPS/QPS有多少,作为整个系统的消息中心,是否可以信赖;

你得知道redis的QPS和TPS是多少,是否会因redis存在瓶颈,如何设计key可以方便从单机redis扩展为集群,或者小集群扩展到大集群。

你得知道http/thrift等通信协议的优缺点,不同场合做出不同的选择。

你得知道mysql能撑住的量是多少,字段类型设计成什么样能满足需求又不失性能。

你得知道hbase、mongodb试用什么场合,都有什么坑。

你得知道响应N万QPS http请求需要什么样的框架,需要几台机器。

你得知道处理流数据storm和spark应该选哪个。

如何高可用?需不需要冷备热备?如何监控报警?系统中某个节点挂掉怎么办?服务解耦到哪种粒度?

是否所有需求都应该满足?哪些需求可以判定为不合理需求?
......

(以我目前的见识和经历,也只能想到上面这些。[捂脸])

等一系列的事情,这样才能在设计阶段,就能看到以后可能遇到的坑。

这里再记录下现在工作中遇到的一些坑:

  • mysql的某字段设计成为text,实际上设置成为varchar完全能够满足。text导致主从延迟十分大。如何确定的?弄了另外一张完全一样的表,将text改成varchar,就完全没有主从延迟了。但现有数据量太大,改变字段类型起码会锁表30分钟以上,完全不可接受,最后只能切换到另外一张表才解决问题。
  • 无效devicetoken存放在单机redis中,设计成为以app为key的set,某些巨型app的无效devicetoken可能上千万。后来单机redis的qps满足不了高峰期的查询需求,只能改成集群redis。但现有的key设计导致同一个app的数据只能存在一台redis上,根本解决不了问题,高峰期压力无法分散开来。最后将key设计成appkey+devicetoken的形式才解决问题。
  • redis集群的proxy问题。最开始我以为codis/twenproxy的proxy和hbase的master/zookeeper一样,不负责数据传输,只负责存储些meta信息,真正的数据交互式client和实际worker交互。结果发现只有一个proxy的情况下,qps和单机一模一样。后来进一步了解到原来proxy是要进行数据传输的,想要提高qps就得增加proxy数量。比如4台redis组成的集群,需要4个proxy才能发挥出全部的性能。
  • 同样的mongodb的proxy(mongos)也进行数据传输,后来全部改成多个proxy了,既发挥出了集群的全部性能,又消除了proxy的单点故障。
  • alias和tag的设计问题。这个就涉及到具体的业务了,大致的情况就是对这2个接口没有做任何的限制,基本的长度限制都没有,导致开发者/黑客滥用接口,alias库里面各种超过4MB长度的数据,有的甚至把整个网页当成alias,有的全部是各种攻击注入sql。而更多的开发者弄不明白alias和tag的区别,把两者混用,把tag当成alais,导致后端查询压力巨大,把alias当成tag,导致数据库完全存储不下。这个问题至今没有完美的解决方案,当初设计上的想法是好的,可不是每个用户都是按照设计的想法来的。永远不能小瞧用户的创造力/破坏力。从最开始,就应该有严格的限制来引导开发者正确的使用各个接口。没有限制往往带来的是灾难。
  • 存储在redis中的数据没有设置ttl。当初选择将数据存放在redis时就应该考虑到ttl。现在的结果是接近1T的数据,用了9台价值7-8W的机器,存放在redis集群中。而这个集群的qps是多少?1W都不到!一台redis就可以满足qps,但因为历史数据无法删除,导致只能不断扩展集群大小。根据dau等其他方面推测,这接近1T的存放在redis中的数据,最多只有30G的数据是有效的数据。
  • 没有防爆量设计。每个集成了sdk的app都会在一些事件的触发下发送http请求到服务器上。而有的集成有误的app可能会导致请求量暴涨到服务端无法处理的地步,可能只是log文件就能撑爆硬盘。这个问题到现在也没有解决,现在每次遇到爆量都只能硬编码。其实解决起来很简单,方案我也出了,但因为一年可能都遇不到两三次爆量,所以老大就一直觉得无所谓不用浪费时间开发这个功能。
  • 定时任务太多。很多业务数据都靠定时脚本上传数据到hdfs上再计算,每当遇到新增服务到新机器,服务转移到其他机器等情况,就会出现忘记部署定时任务的情况,从而导致业务数据计算有误差。现在解决方案是所有需要上传的数据写kakfa(实际上本来就会写kafka),然后后端spark streaming消费并写到hdfs上。干掉所有定时任务真是一身轻松。
  • 不合理的需求应该拒绝。某汪*带盐的网站家的app,大概累积设备量不到30W,每次广播打开数在7000左右。就算这7000个打开都在同1秒,那他们的服务器的qps也不过7000,况且这7000个打开是24小时甚至更长时间内陆续打开的。就这样的压力,他们就受不了了,要求我们把发送速度降到100/s。如果真的降到100/s正常情况下也就不到10s能发送完的任务我们需要40min才能发完,这意味着一台服务器在40min里只能龟龟龟龟速的发送这个任务。为了这个需求修改服务?我觉得除非吃多了,不然绝对不可能满足这样的需求。然而,我觉得的没用,你们懂的。[大哭]
分类:杂七杂八, 随想
标签:

玄学出奇迹

1条评论1,219次浏览

2016-11-03开始,APNs HTTP/2 API速度突然变得奇慢无比,建立连接各种超时,handshake各种超时。50个channel的情况下每秒能发送的消息只有个位数。简直哔了狗了。

初步排除一番后,发现10台服务器当中只有5台服务出了上述问题,另外5台的发送速度居然比平常还要快。于是怀疑集团为了双十一把网络调整了,让pe联系集团网络部的查了一通,返回结果,并没有任何调整。

接着怀疑是不是这五台机器的硬件出问题了,又查了一通,发现并没有。

最后怀疑程序出问题了。为啥最后才怀疑程序?我这服务线上无故障跑了好几个月了,突然出问题,还是几台机器在同一时间出问题,打死我都不相信。结果也表示,程序没有任何异常。

最后只能让苹果背锅了,认定是苹果的APNs HTTP/2 API服务抽风了,和这5台服务器命中相克。于是只能将大部分发送任务放到老版本API上去,少部分流量放到APNs HTTP/2 API上,然后关闭了出问题的那5台机器。

经过3天的观察,发现之前认为没有问题的另外5台服务器居然也出现了同样的问题。又是各种查后无果。期间抓包发现居然有高达20%的网络重传。

就在我即将崩溃,准备裸奔释放情绪的时候。突然间无意的发现,貌似这些发送比较慢的任务的remote ip地址第三位比较集中。苹果服务器ip前两位是固定的17.188。而那些发送比较慢的第三位基本上都是12X、13X以及少量的14Y(y<4)。难道是巧合?于是把所以机器上的所有发送慢的任务的ip全部查了一通,发现居然没有一个反例。于是我不由自主的得出一个玄学结论:remote ip第三位比较小的(比如小于145)发送速度慢,大于145的发送速度快。为了验证我的猜想,我又把所有服务器上的所有发送速度快的任务查了一遍,发现卧了个槽,居然还是没有反例,没有一个例外能推翻我的玄学猜测。

然后我将所有的结果汇总,发现remote ip第三位小于等于142的速度奇慢,各种超时,而且没有例外。而第三位大于等于144的速度奇快。然后让pe那边分析了一下抓到的包,发现20%的网络重传也全部都是remote ip第三位小于等于142的ip。进一步证实了我的玄学猜测是正确的。

接下来,修改程序上线,不连接那些remote ip第三位小于等于142的。经过1天的观察,卧槽,真的没有一个慢的任务。

对此我只想说,玄学出奇迹。

至于为何会这样,我只能猜测要么苹果的这2组ip地址的服务器在不同机房,有一个机房出了问题;要么就是苹果在灰度测试新的服务,因为抛开那些发送速度离奇慢的任务,其他的任务发送速度都翻了2-3倍。然而苹果官网上找遍了也没有一个公告什么的。

什么是玄学?玄学就是,今天编程不宜面朝东面,不然bug多;今天不宜上线,不然服务必挂之类的迷信。
1

分类:APNs
标签:,

Redis设置密码的那些坑

2条评论1,018次浏览

最近集团安全部扫描到我们组的redis没有设置密码。如何扫描的?一个脚本,登陆到服务器上查看固定路径下的redis配置,没有配置密码就被扫出来。简单无脑暴力。

于是开始虐心的添加redis密码之旅。

Server端配置

方法1:redis-cli -h xxx -p xxx CONFIG SET requirepass xxx

方法2:修改redis.conf文件,配置requirepass

对于twemproxy,可以升级到最新版本,然后配置redis_auth xxx。

Client端配置(Jedis)

项目中都是用的JedisPool。我们的方案是给所有代码进行如下处理:

看起来应该没问题,实际上测试了下,也一切ok,于是开始了第一次改密码尝试。将涉及到的七八个应用、几十处代码全部修改完毕上线后,一切正常。然后redis server端添加密码,瞬间崩溃了四五个服务,只剩两三个服务正常运转。于是立马去掉密码,开始查原因。

JedisPool初始化的坑

经过一轮排查,发现出问题的服务都是用的上面的方式初始化JedisPool。而没有出问题的都是下列方式初始化:

然后看了下源码,果然在有database参数且不等于0时,会进行一次select操作,而我们的password用的是null,所以就会报错。于是又一次将涉及到的七八个应用、几十处代码全部修改完毕,开始第二次改密码尝试。所有应用上线后,一切正常。开始redis server端添加密码,瞬间又是几个服务崩溃,几个服务正常。于是立马去掉密码,开始第二次查原因。

setTestOnBorrow的坑

又一轮排查后,发现出问题的服务都是JedisPoolConfig::setTestOnBorrow(true),没有出问题的要么是设置为false,要么是没有设置,而没有设置的默认情况下就是false。然后再次看了下源码,setTestOnBorrow应该是从pool中获取到实例的时候会去ping一下,然而此时没有auth过,于是又报错了。无奈,只能将所有的JedisPoolConfig::setTestOnBorrow(true)注释掉,开始第三次尝试。

还好,没有其他幺蛾子了,这次终于没有问题,加上密码,去掉密码,服务都正常运转。心塞。

分类:Redis, 战5渣
标签:,
11
profile
  • 文章总数:81篇
  • 评论总数:241条
  • 分类总数:32个
  • 标签总数:45个
  • 运行时间:1254天

大家好,欢迎来到selfup.cn。

这不是一个只谈技术的博客,这里记录我成长的点点滴滴,coding、riding and everthing!

最新评论
  • Anonymous: :?: :razz: :sad:
  • Anonymous: 牛
  • Anonymous: 楼主你好,我偶尔也会 遇到Reconnect due to socket error: java.nio.channels.ClosedCha...
  • Anonymous: sdfs
  • Anonymous: :arrow: :neutral: :cry:
  • Anonymous: java.io.NotSerializableExcepti on: DStream checkpointing has been enabled but the DStreams with their...
  • wick: HI,请问一下,U,S,V得到 ,怎么得到近似矩阵 (用spark java),谢谢。
  • Michael Whitaker: Thank you for this blog, it was very helpful in troubleshooting my own issues. It seems that no...
  • Anonymous: :mad:
  • Anonymous: :???:
  • Anonymous: :mad: :mad: :mad:
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • Anonymous: :razz: :evil: :grin:
  • 张瑞昌: 有很多,比较常见的是 Jacob迭代法,一次迭代O (n^3),迭代次数不清楚 ...
  • Anonymous: :mrgreen:
  • lc277: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: :smile: :grin: :eek:
  • 李雪璇: 想要完整代码,可以帮 忙发给我吗