 |
povsisterV2EX 第 686080 号会员，加入于 2024-04-20 17:50:48 +08:00今日活跃度排名 7621 |
povsister 最近回复了
3 天前 回复了 vst93 创建的主题 › 分享创造 › bili-fm 通过音频来听 B 站节目 |
大致扫了眼代码，作为练手项目完成度尚可。但大概 b 站一更新签名这 app 就废了
3 天前 回复了 Frytea 创建的主题 › 职场话题 › 深夜吐槽，感觉职场中小组长和中层最难受 |
手上没实权就别管那么多，掌管打绩效的权利才是该管人的角。你当好包工头就行了，至于磨人的活，信息留好到时候自然有人替你磨。
5 天前 回复了 wellcheng 创建的主题 › 宽带症候群 › 个人认为目前最适合的手机号+流量号+宽带方案 |
@zachary99 携转电信出去现在发短信没有任何合约的情况电信都不挽留。携转其他运营商到电信+升一档套餐，不给任何优惠。
5 天前 回复了 wellcheng 创建的主题 › 宽带症候群 › 个人认为目前最适合的手机号+流量号+宽带方案 |
@zachary99 电信五折现在没了啊，上周刚问的。229 套餐没有任何优惠
8 天前 回复了 singed58 创建的主题 › 职场话题 › 我也来问问 offer 怎么选？ |
有贷款无脑选 2 ，热钱不多，要抓住，先还完贷能一身轻。
而且小孩已经 2 岁了，过了那个特别折腾人到晚上睡不好的年纪。多关注下家庭给足情绪价值就行。
而且小孩已经 2 岁了，过了那个特别折腾人到晚上睡不好的年纪。多关注下家庭给足情绪价值就行。
8 天前 回复了 qiaofanxing 创建的主题 › 信息安全 › （转）国内最大 IT 社区 CSDN 被挂马， CDN 可能是罪魁祸首 |
哈哈，抄码农博客，偷 GitHub 代码，挂钓鱼木马，csdn 这辈子有了。
9 天前 回复了 aababc 创建的主题 › 程序员 › golang 中 error 如何影响 log 和 api 状态 |
@aababc
你列举的正是问题所在之一。
API 数量上升之后，服务治理将是一个非常头痛的问题，稍有不慎服务状态就和基础设施状态耦合进去了。你使用 http 状态码会加剧这一过程。
举个例子，http 504 是 gateway timeout ，但业务逻辑执行超时是很常见的现象，现在微服务框架都具备在链路超时 quota 超过后主动取消请求的能力，并且返回 deadline exceed 错误。按照你的想法，那它应该被设定为返回 http 504 。
ok ，记住上面的结论。
现实中，微服务和微服务间存在非常多的 middlebox （ router/Switch/L4/L7 LB ），他们会透明化的按照某些规则转发 http 请求。
假设，有一天中间某个 L7 负载均衡故障，造成 http 转发产生 504 超时。
请问：你怎么判断这个 504 是基础设施故障还是你业务逻辑故障？
以上是可观测问题，下面继续说深刻点。关于 SLO 治理。
正确的方式是让对的人去处理对的事情，而不是服务故障牵一发而动全身。因为你已经混淆了业务响应和基础设施问题，那服务出现故障告警时，运维和开发都会被拉进去。告警噪音将彻底击溃整个系统开发和 SRE 的基本信任。
ok ，到这都还是只讲了 http 。
那如果引入更多的应用层协议，使用 gRPC ，使用 thrift 时，虽然他们都是使用 http transport ，但并不遵守你那套 http status 要求，那你的告警和观测系统要各自做一套吗？
综上，最好的办法是，业务独立使用一套自己定义的错误观测体系，所有的应用层协议都按 transport 层处理。明确基础设施和业务边界
你列举的正是问题所在之一。
API 数量上升之后，服务治理将是一个非常头痛的问题，稍有不慎服务状态就和基础设施状态耦合进去了。你使用 http 状态码会加剧这一过程。
举个例子，http 504 是 gateway timeout ，但业务逻辑执行超时是很常见的现象，现在微服务框架都具备在链路超时 quota 超过后主动取消请求的能力，并且返回 deadline exceed 错误。按照你的想法，那它应该被设定为返回 http 504 。
ok ，记住上面的结论。
现实中，微服务和微服务间存在非常多的 middlebox （ router/Switch/L4/L7 LB ），他们会透明化的按照某些规则转发 http 请求。
假设，有一天中间某个 L7 负载均衡故障，造成 http 转发产生 504 超时。
请问：你怎么判断这个 504 是基础设施故障还是你业务逻辑故障？
以上是可观测问题，下面继续说深刻点。关于 SLO 治理。
正确的方式是让对的人去处理对的事情，而不是服务故障牵一发而动全身。因为你已经混淆了业务响应和基础设施问题，那服务出现故障告警时，运维和开发都会被拉进去。告警噪音将彻底击溃整个系统开发和 SRE 的基本信任。
ok ，到这都还是只讲了 http 。
那如果引入更多的应用层协议，使用 gRPC ，使用 thrift 时，虽然他们都是使用 http transport ，但并不遵守你那套 http status 要求，那你的告警和观测系统要各自做一套吗？
综上，最好的办法是，业务独立使用一套自己定义的错误观测体系，所有的应用层协议都按 transport 层处理。明确基础设施和业务边界
Select Language