新年10个Flag实现中~
访问量
2.4M
文章数
154
运行天
1333
一、全链路监控1.1什么是全链路监控,为什么我们需要全链路监控?(1)全链路监控:对请求源头到底层服务的调用链路中间的所有环节进行监控。(2)为什么需要:对于单体应用,我们可以很容易地监控和分析它的性能。对于微服务,编程语言不同、服务器数量庞大、可能跨多个服务/区域,那么面对复杂的请求调用链路,就会有一系列问题,只有全链路监控才能处理,例如: 如何快速发现有问题的服务?如何判断故障影响范围?如何梳理服务间依赖关系?如何分析链路性能问题?对于一次慢请求,如何找到慢请求的来源?(3)和其他监控组件的定位区别监控、追踪和日志是可观测性(observability)的基石:和日志监控Logs区别:日志监控侧重于单个业务的代码bug分析。虽然利用MDC可以追踪一个请求,但不能追踪跨线程、跨服
一、分布式一致性算法分布式一致性算法,用于解决分布式系统的数据一致性和集群共识问题。数据一致性是指,分布式系统对外提供的数据读写表现是一致的。当然可以细分为线性一致性、最终一致性等。集群共识是指,能够对集群达成某种状态产生一致意见。1、比特币PoW等共识算法主要用于“节点间无法协商”的场景,相当于无限个节点在进行共识,因此借助概率来单机计算。2、Paxos属于理论基础,实际应用通常都是基于它改造过的算法。3、Zookeeper的ZAB算法(ZookeeperAtomicBroadcast),它其实不算是一个通用的算法,而是专门为ZK做的分布式一致性算法。它有两个印象深刻的点:(1)每轮选主的投票会更新多次,每次收到投票都会进行选票PK,然后广播更新。优点是简单,但缺点是收敛可能会很慢。对比一
2021是我最后的一次机会了,我要找到一群奔跑的人。今年只有一个目标。
一、和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
一、背景JWT(JsonWebToken,RFC7519)是常用的轻量级授权认证手段,常用于Web服务校验客户端身份。JWT分为三部分:Header:头部,明文,比如密钥IDkid、或者签名算法alg等等Payload:内容,明文,包含了业务的信息,比如可以加入一些不敏感的clientId等字段Signature:签名,利用“加密算法”对JWT进行签名,保证没有被篡改过值得注意的是,这里的数据都是明文的,算法实际上执行的是最后的数据签名功能,只能保证“不被篡改”,而不是保证“不被解密”,所以后面看到“加密、解密”,其实都是为签名服务的。签名例如,一个完整的JWT形式是"Header.Payload.Signature",中间用英文句号的“.”连接起来,如果选择的算法为HS256,那么会将前面
Kafka中,必须要知道的概念就是消息和日志段。一、V0和V1消息在0.11之前,消息被称为Message,一批以数组形式保存的消息被称为消息集合(MessageSet)。消息集合只是简单的聚合,消息集合中的每条消息都有自己的元信息(Metadata),这个并没有聚合。0.10前Messageversion=0,0.10~0.11版本Messageversion=1,这个Messageversion被存储为魔术数字(MagicNumber),放在消息里面。1.1V0消息  V0版本的结构都比较简单:attribute:1字节,低3位是压缩类型,0=NONE,1=GZIP,2=Snappy,3=LZ4(LZ4需要kafka0.9.x以上)key:key可以为null,如果为
一、Kafka的基本框架在Kafka中,发布和订阅的对象称为主题(Topic),主题可以有多个。向主题发布消息的应用称为生产者(Producer),订阅这些主题消息的称为消费者(Consumer)。生产者可以有多个,可以在不同的系统;消费者也可以有多个,同样也可以在不同的系统。生产者和消费者都称为客户端(Clients),这个概念与Kafka服务器(Server)对应。 Kafka服务端可以有多个实例构成集群,每个实例都称为一个消息代理(Broker),这些实例可以分布在一台机器上,也可以分布在多台机器上以达到高可用的目的。你可以在消息中间件中经常看到Broker这个词,例如MQTTBroker等,Broker的本意是“经纪人”、“代理人”等等,中间件正是这样一个中间代理的角色。K
12345... 17下一页