前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >技术专家写代码-以点带面谈做开发

技术专家写代码-以点带面谈做开发

作者头像
静儿
发布2018-07-02 16:04:22
4980
发布2018-07-02 16:04:22
举报
文章被收录于专栏:编程一生编程一生

静儿历时8个月终于如愿回归写代码的生活。希望这8个月的成长能对自己的码砖起到一定的指导意义。下面就介绍一下静儿回归后的第一次码砖经历。

以下是静儿的方案设计:

01

— 

方案设计

背景:

DNS绑定会有一定的失败率。失败原因包括但不仅限于:

  • dnsupdate服务只进行基本的ip和域名唯一对应合法性检查:add操作,如果已存在域名的正解或ip的反解,则会更新失败。
  • dnsupdate服务由于各种原因造成的不可用或处理错误

针对上面情况需要做一个补单

调查:

dnsupdate域名更新服务API接口说明 对此文档,针对dns.add,返回结果举例如下:

XXXXX

此例子来源于线上日志,新美大日志中心地址:

XXXXX

其中返回值中有个status='init'字段。通过向云计算部门XXX同学了解,对于dns绑定和解绑,都是异步操作,先提交任务,然后再查询任务执行状态。实际执行线上目前要跟X台dns服务器更新数据。校验不通过,状态码是400;在状态码200的情况下,如果能拿到taskid,status,就说明任务是校验通过,理论上应该执行成功的,后来查询到status时failed,可能是dns服务器异常,或者已经有了相关记录。

自身优化:

XXX里的

public boolean dnsAction(String action, String ip, String host, String domain) 和

public void add(String ip, String name, String host)

public void delete(String ip, String name, String host)

做了同样的工作,但是dnsAction没有cat埋点,统一用dns.add和dns.delete,并添加cat埋点。

XXX的封装,这个封装判断成功的依据是可以获取到更新dns的request id。但是作为补单来说可以做更细粒度的处理,此处需要优化。

技术调研:

  • MQ:

因为hulk-config项目中已经使用了mafka,根据项目稳定需要尽量减少依赖的原则,所以一开始考虑使用mafka做延时消息队列,调研结果支持延时时间区间没有确认是否能符合要求。

延迟消息队列

发展历史

是否BG隔离

部署机房

延迟精度

是否考虑时钟漂移

支持延时时间区间

线上接入业务

线上接入量

KV双写

单点故障

是否有容灾演练

mafka延迟队列delayserver

2016年中旬至今

是,每个BG都有单独集群

北京侧:dx,yf,gh均有部署 上海侧:gq

100ms

考虑了

5s-7天

金融支付,到餐退款,外卖等均有接入

600+topic 15000+qps

有,优化方案已开发完毕

rabbitmq延迟队列 koala

2016年底至今

只接入外卖业务

dx处于使用状态 yf冷备

1s

未考虑

不限制

外卖配送业务

共有105个队列 10000+qps

beanstalked无团队维护,技术团队在主推mafka,逐渐淘汰rabbitmq。所以如果考虑支持延时时间区间不符合要求采用MQ代替方案。

  • Redis:

因为实际上只需要一个队列,延迟可以控制客户端的消费频率来实现。而redis里有List结构来实现消息队列,理论上是可以实现的,而项目中已经依赖了squirrel,不会产生新的依赖。之前在乐视做过redis cluster的map结构性能压测,在一个map超过万级的时候,性能恶化非常严重。list同map一样,也存在集群的性能优势不能发挥作用的问题。性能方面有待测试(Mark),目前问题不大,数据量增大可用多个list横向扩展解决,还避免了MQ的分片上限影响扩展性。

  • 下游支持

涉及公司内部信息,此处省略

补单处理:

  • 逻辑梳理

针对调用XXXX,结果分为下面几种情况:

*注意:第三方 的报警设置,加上,请求url,参数,返回参数。若cat无法支持此种报警策略,可考虑自定义大象。

总体采用mafka延时队列实现

1>查询时间间隔:(1)5s,(2)5s,(3)5s,(4)5s

最长查询时间20s,设置MCC开关控制,最大重试4次

2>补单时间间隔:(1)5s,(2)10s,(3)60s,(4)10*60s,(5)20*60s,(6)30*60s

最长补单时间1小时,设置MCC开关控制,最大重试6次

3>流控初期先用开关控制,后续可以考虑做熔断。

4>需要在XXXX表里做标记

  • CAT埋点方案

调用dnsupdate服务前后埋点记录输入和输出

后续TODO:

  • 出一个DNS调用数据,预估需要DNS服务要支持的容量,看是否需要推动DNS服务的扩容、性能优化。
  • 需要DNS服务的兄弟给出细化的错误原因

02

开发

    代码开发很简单,静儿整个开发阶段(不算测试和联调)实际上耗时两小时。这里主要谈谈遇到的问题和一些思考。

程序无法启动

    在开发过程中最不愿意遇到的问题就是环境问题。静儿代码开发完了,想启动验证效果,程序启动不起来。在启动之前

  1. 静儿新拿到服务,之前没有启动过
  2. 做了一些修改
  3. 其他同事用的是外部配置的jetty启动,我直接在pom文件里添加了个jetty控件启动的
  4. 确定了其他同学拿到代码没有做任何修改直接可以启动

    这时候我是不是应该慌里慌张的新拉一下原始分支试一试是不是自己改出来的问题?答案是“No”,为什么呢?

    从报错来看,日志堆栈最上面是最表面现象,最下面是直接原因。表面现象是数据库连接问题,最下面有定位到一个点评框架的代码。直接来看和我新写的代码没有关系。

    之所以选用mafka是因为项目本来就用到了,所以我新开发的代码不存在引入新的中间件问题。新配置了一个远程调用的服务,是启动时加载的,但是原来也是有调用,调用方式不同,并未引入新的jar包,也不存在少引用的问题。

    错误和代码之间没有直接关系,先不考虑新修改代码的影响。直接根据堆栈信息找错误原因。

    堆栈里报的最直接的cause是一个NPE(空指针异常),定位了一个报错代码位置,但是由于不是直接引用,所以不能点进入定位原因,那就先做一个依赖。依赖后点击进入一个反解析后的代码,代码是使用点评的配置框架。配置需要依赖一个本地文件。

    这时候心里的想法是通常这种问题可能和我使用的mac本需要写入授权有关。找到本地文件的路径,果然在磁盘上没有这个问题。所以授权了整个目录所有权限,重启还是没有这个文件。手动创建文件,再次启动还是同样错误。

    这时候想的是:这应该是一个使用这个点评框架的通用问题,美团同事会常遇到这个坑。所以这时候我根据问题去美团的wiki上搜索,果然搜到需要进行一个文件配置,里面要写内容。

    所以我跟一个项目的同事要了他的文件,将内容写入,启动成功。

测试用例启动报错

    程序可以起来了,但是我们是一个后台系统,测试不能点页面做黑盒测试,我们都是自己写测试用例做白盒测试。测试用例跑不起来?

    报错ClassDefNotFound,少jar包?引用冲突?问了同一组的哥哥,他那边没有任何修改可以正常启动。先不管这些,少什么加什么,既然正常程序没有问题,新加的pom引用scope都是test,添加了三个引用,启动成功,问题是why?

    我将自己没有修改过的原分支在其他地方重新下载一份。将两个分支的mvn dependency:tree做对比:

发现我手动添加的三个引用

|  \- org.codehaus.plexus:plexus-classworlds:jar:2.5.1:compile

[INFO] |  |     +- org.codehaus.plexus:plexus-utils:jar:3.0.24:compile

[INFO] |  |     \- org.apache.xbean:xbean-reflect:jar:4.5:compile

在原分支的

com.dianping.squirrel:squirrel-client:jar

这里面做了间接引用。而新分支我添加一个exclusion:

然后直接引用了这个jar包:

问题是:

我没有exclusion掉cat啊?结果却成了:

why?

这是maven的传递性依赖,具体请参考:https://www.cnblogs.com/wuchanming/p/5403135.html

静儿的博客近期会进行一些改版,在博客园的文章只有技术干货,分离出“总结与思考”、“跑题时间”在每次自己个人公众号上单独发表。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018-05-11 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 背景:
  • 调查:
  • 自身优化:
  • 技术调研:
  • 补单处理:
  • 后续TODO:
相关产品与服务
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档