编程思路

首页编程思路
07
Oct
0

云调用链路性能分析稳定分析错误定位方法

一大早和老大讨论接下来框架管理端设计,讨论到云容器内的链路跟踪及展示

然后结合一些网上的内容,大概得出以下一些方法

1.链路跟踪:
发生在容器内部各模块间的互相调用,由于都在容器框架内部,有统一的调用接口,那么可以在首次进入调用时生成traceid用于跟踪
每调用一步都把id往下传,再生成一个层级id每进入一层加1,这样每一层记录,最后排序就能得到调用链路图.

2.异常追踪及重现:
根据跟踪图,存储每层相应的参数,接口,异常信息,追踪路径则可以很容易定位错误源.

3.负载计算:
根据时间,再在跟踪图里加入,服务器序列信息,再进行实时统计得出各服务器负载情况,得出高负载点,及确定为什么不能就近调用,或得出错误调用路径

4.存储链路及如何进行实时计算:
收集+离线计算已经不能满足需求,所以不能用hadoop等大型离线方式处理,更好的方式是支持pipeline数据库,流计算库StreamLib等

5.监控系统:
流计算有一点很难控制,有时监控数据异常,无法判断原因是流计算负载太大出问题,还是实际生产环境出了问题,那么是否异常发送给管理员,暂时找不到很好的方法,只能在计算流的各个阶段都放入监控,通过各阶段的数据来确定是否正常,再发送警报.

6.统计粒度及时长:
天,小时,分钟基本满足要求,按机器序列,统计,可以知道负载等

7.模块化及可视化
分块可按业务点进行拆分,数据清洗等,可视化可以用google blockly进行二次开发,管理员可以自定义数据

27
Sep
0

灰度发布的几种思路

最近公司云平台准备搞灰度发布,思来想去,无法想象大公司,比如阿里云他们是怎么做的,
以最简单方式实现的思路,大概有这么几种,比较简单的方案:

最近刚了京东,用于测试推荐算法的A/B TESTING,发现无比适合这个场景,有那么一瞬间,感觉这个已经是灰度发布了
只是不知道京东的实际做法是怎样的,不过他们肯定是能精确控制的喽

  1. 创建A/B TESTING方法,在JS里实现调度规则

    这方法很难精确控制实际分配的量,不过简单,来两句代码就完事,后台甚至都不用改任何东西.  失败了恢复,只需要刷新页面
    
  2. 以新特性模块方式,让用户自己选择是否开启

    这方法很难勾引很多用户去使用,要么给很大好处,模块化平台设计会比上一种方式复杂,首先模块化,其次嵌入公告什么的,以前做过类似的,确实蛮麻烦的,又要保证公告系统,又要维护模块,公告系统上次还弄残了,想想就够了.同上,也很难估计流量.失败了,只有弃用一途,公告撤回等太麻烦
    
  3. 以升级用户标致,用户升级了的标为1,访问新特性,反之

    这方法想来,还是最好用的,前提也是应用要做相应的模块,不过比第二种稍微要弄的东西要少,哪怕搞坏了,立马恢复也很容易,退出重进或动态配置
    

2018.02.23 更新

  1. 上面几种方法都不能很好的实现控制区域,控制时间,控制多少流量进入新版本,控制客户端类型分别访问什么服务器,什么版本等等,所以再增加一种,对用户生成动态配置,每次上线给出当前的连接配置,这样可以方便的分配负载均衡(分配器需要知道其它的监控信息),分配区域,死掉了可以迅速控制配置转移到新的机器上

完了,还是很想知道大公司是怎么做的...