故障恢复

故障恢复
之前做个一个折中的处理方案,类似于快速接收,批处理,反馈处理状态。之所以这样处理,是因为合作机构IT水平参差不齐,而且配合程度不高,如果把数据接收+处理+反馈放到一起的话,一旦有错误,就要麻烦对方重新推送最新数据,或者自己脚本重新处理数据,而且一天峰值十分明显,峰值时根本来不及处理数据。
1、数据接收阶段,采用了快速失败策略。一旦数据落库文件落盘,就返回成功,反之失败。
2、数据处理阶段,会进行重试,三次后进入失败队列
3、进入失败队列后,会通知运维和开发,去看下数据什么问题。有时会把文件手工处理一下,再重试。如果实在无法处理,就线下通知合作方相关人员如何修改数据。
4、数据处理成功后或彻底失败后,发送处理结果给合作方。

这种方式,在对合作方约束很小、合作方缺乏技术支持、项目前期阶段、以快速开展业务为优先考量时,可以尝试一下。后面自己做起来后,就可以要求对方,做一些统一要求了。

限流和降级
之前在一个大量读写小文件服务的入口处,用过令牌桶限制访问量,防止IO过高。问题是每秒要发放发放多少令牌,最后是慢慢试出来的。

后面微服务时代就是中规中矩的限流,降级和熔断了。但降级和熔断,是通过HTTP状态码进行判断的,有些后知后觉了。

零信任网络
一个团队去完成一个任务,如果彼此信任,相互配合就会很流畅,沟通成本会很低,任务推进也会很顺畅。比如几个知根知底的伙伴去创业,一个眼神可能就懂了。
一群互不信任的人去完成一个任务,哪怕每个人都很努力,但经常感觉别人掣肘,吵来吵去,任务止步不前。一个流动率高,甩锅成风的组织,便是如此。

代码也是如此,如果我们假设代码是可信的,直接拉取镜像就行了。
如果假设代码是不可信的,开发提交代码后,要各种引擎扫描,扫描通过后,流水线打包镜像。同时还要提交各类材料如测试报告,越权测试报告,渗透测试报告,压力测试报告,代码审核报告等等相互佐证代码没有问题,然后发布。
这样先不说要多少资源支持,单说发布,就从十几秒变成了十几分钟,甚至几十分钟。

服务也是如此,如果假设服务是可信的,不要加任何控制,就可以相互访问。
如果假设服务不可信,就要各种验证,网络端口是否允许访问,token是否正确,双向证书过了没,是否有服务访问权限,是否有数据权限,是否符合流量控制要求等等。
先不说做需要多少资源支持,单说服务性能,从几十毫秒一下到了几百毫秒。

那做这些值吗?值!
但要符合自己的情况,不能太过,绑了自己的手脚!

零信任网络安全
我认为边界安全模型和零信任模型会长期共存,边界安全模型毕竟更成熟,而且在资源隔离程度上,远高于零信任模型。istio们并没有提供边界模型的一些组件,比如杀毒,比如入侵检测,比如蜜罐,比如上帝视角的规则控制等。而且istio们本身也有被入侵的可能,所以不能只依赖这一个层面的安全管控,而是立体的安全管控。

可观测性
单体程序时代,类似于一个办公大楼,有了问题,告诉管理员门牌号和具体事情就行了,管理员就可以乘电梯过来解决问题。
只要在日志里输出一下,哪个方法,做了哪个任务或出了什么问题,用日志工具就可以统计到处理速度或快速定位到问题了。

微服务时代,类似于管理城市物流。要提出问题,我们必须说明,那条街,哪个门牌号,几单元,有什么需求。工作人员上门时,要看下地图,什么路线过去最快,遇到堵车怎么办,小区不让进怎么办,然后才能到顾客这边提供服务。数据链路就像城市地图,监控就像地图上的流量,而日志必须还原到这张地图上,才知道哪个交叉口或哪个大楼哪里出了问题。
所以,我们要花必要的精力,去做全链路,绘制这个地图。所以我们要收集度量信息,去监控哪里流量红了,哪里彻底堵车了。只凭日志,是无法快速定位问题的,这个交叉口堵车,问题可能出在三公里之外,一个交叉口一个交叉口查过去,太慢了。

流量大了,堵车是必然的。只有做好可观测性,才能快速疏导交通,做到事半功倍。

日志
个人觉得,如何正确的记录日志,用何规则做日志分级,要记录哪些东西,比用什么技术栈分析日志重要的多。老师能否分享一下,日志规范如何在团队中落地呢?

有两种情况,多记录一些日志有好处的。一类是部署于第三方的系统,宕机时要多记录日志,最好有dump文件,利于排查问题。第二类是跨公司做集成对接,输入输出一般都会记得很清楚,为了防止扯皮。

聚合度量
主要监控了服务请求,JVM,服务器的一些指标。但服务请求方面,做的还很基础,有较大提升空间。

Leave a Reply

Your email address will not be published. Required fields are marked *

*