新年10个Flag实现中~
访问量
2.0M
文章数
150
运行天
1206
一、和Istio的融合问题1.1Istio的mTLS默认开启导致无法访问K8S服务在Istio1.4.x版本,MeshPolicy默认开启全局mTLS(values.global.mtls.enable=true),如果服务网格没有定义DestinationRule,那么就会使用mTLS。如果此时网格内的服务想要访问外部的K8S服务(比如数据库等,没有进入网格的K8S服务),istio会以为它是网格内的,仍然以mTLS建立连接,导致对端服务无法响应。因此,需要显式地设置Istio的DestinationRule,禁用掉mTLS:apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:mysql-1nam
前言长连接放到K8S之后,做性能测试就发现连接量上不去,在7~8W连接左右的时候,ELB的“波动队列”就开始暴增至1024,然后开始丢包。我一直有其他的工作要处理,这个排查又比较费时间,所以一直把这个事情搁置了。在迭代新版本的时候,发现连接量降至单个容器6W左右,反向优化最为致命…我的同事开始排查这个问题,最终找到是ELB的问题,记录一下他的思考过程,积累经验。一、问题描述在AWS的ELB(CLB)中,有一项监控指标叫做波动队列(SurgeQueue),长度最大为1024。波动队列的作用是,当后端服务器没有响应的时候,它会将请求包缓存起来,等服务器有响应了之后再把这些包慢慢消化掉,如果流量过大超过1024,则直接将包丢弃掉,避免在服务器处理能力有问题的时候遇到突增流量导致崩溃。在性能测试(P
前言在接触到MQTT之后,总是会有疑问,为什么用MQTT不用TCP长连接透传?看起来【TCP长连接+私有协议透传】和【MQTT+业务主题】似乎都能达到同样的目的,甚至用MQTT会使得设备端逻辑实现、APP端逻辑实现、云端架构实现更加复杂。那么为什么物联网还要使用MQTT协议呢?一、MQTT相比于TCP长连接的优势1、协议更标准MQTT是标准的RFC协议,相比于私有协议而言更加标准。好处在于:(1)协议非常完整,能够马上用于生产。各端实现同一套协议之后,就能进行通信;私有协议还需要进行大量的验证,看有无缺陷或欠考虑的地方等。(2)协议的标准化带来大量的开源组件,降低开发难度。随着物联网+5G生态越来越好,开源组件越来越多,可以减少重复编码量。(3)标准协议利于第三方接入。当第三方设备、平台想要
1