Git常用命令

在日常工作中,可能经常会遇到一些一致性需求,需要将本地代码和Git远端代码保持一致,因此这里就主要来记录一些Git的日常操作。 强制覆盖本地代

一文帮你快速回顾正则表达式知识

背景: 在日常工作中,我们经常会使用正则表达式来快速匹配和过滤一些我们期望的字符串来处理一些简单又繁琐的文字统计和过滤操作;而作为一名技术从业者,我们也经常会在程序中或者配置文件中使用正则表达式来处理字符或进行批量配置项的查询和更改,但通常情况下,我们需要对编写的正则表达式进行不断测试才能满足我们的需求,本篇文章带你重新回顾正则表达式,并分享一个在线的正则表达式工具(https://regex101.com/),帮你在工作中快速测试你的正则表达式。

kafka端到端的延迟

前言: 在大规模的使用kafka过程中,我们通常会遇到各种各样的问题,比如说,通常会有一些大数据集群中的Job发现总有几个task会比较慢,导致整体的任务迟迟不能完成运行,这种情况通常问题会比较复杂,想要知道具体延迟在哪里,我们需要知道在Kafka集群中哪些点可能会增加端到端的延迟。

接下来的内容翻译自confluent官网博客中的一篇文章,希望能够帮助大家理解kafka使用过程中端到端的延迟。99th Percentile Latency at Scale with Apache Kafka

kafka如何合理规划分区数量

背景: 如同其他分布式系统一样,在kafka集群中,单Topic的partition也并不是越多越好,但通常对于业务方来说,可能会简单的根据生产者或消费者的处理能力来提出扩partition的需求,此时就需要根据具体的场景进行分析以确定partition的数量。

对于Kafka集群承载的业务Topic来说,分区的数量,可以体现出整个业务的量级同时能够尽可能的提供更高的吞吐,但并不是越多的分区就意味着越高的吞吐和处理能力,通常情况下需要业务方和基础服务方一起来进行分析。

以下为多分区Topic的优缺点,可以适当根据需求和场景进行规划分区数量。

kafka常用运维操作

前言: 在kafka的集群运维操作过程中,我们需要通过一些工具来实现集群的高可用以及负载的平均操作,而对于kafka集群的SRE来说,需要掌握好如下几点,才能更好的维护和保证kafka集群服务的稳定性,可靠性和整体性能。

kafka生产规划和运维

前言: 通常对于初创企业或者初创业务团队来说,对于开源组件的使用都会显的比较随意,而这种情况会随着业务量级的增长或时间的推移导致开源服务的滥用,进而造成的结果就是服务整体的稳定性和可靠性相对较差,且是边际效应递减的,如果此时不对整体业务以及开源服务进行规划和改造,那么风险和成本将是同比增长的。在我过去的工作经历中,经历过类似服务的有Redis集群ElasticSearch集群,虽然整体改造后并不一定将成本降到最低,但是可以将服务的可用性和可靠性提高很多,而且根据业务场景以及使用方式来规划集群后会使得整体的边际成本呈递减状态。

笔者目前所处的团队所管理的kafka集群也处于该种状态,集群当前规模大约为20+ECS,总数据量大约400T,其中承接的Topic服务主要分为日志收集数据管道流式计算业务事件存储几种大场景,我们需要知道,以上几种使用场景对于kafka集群的的可用性可靠性数据一致性要求其实是不同的,如果将所有场景耦合到同一个集群,在数据量较大的情况下,任何的小异常点都可能造成整体服务受到影响,并且整个集群的恢复周期会很长,如果业务没有及时的降级策略很可能影响核心业务的处理。

鉴于以前对开源分布式服务的规划和改造经验,本篇文章将根据官方文档以及经验来分享一些关于Kafka生产集群规划和运维管理相关的知识.

Traefik的可观测性方案

Traefik的可观测性支持

traefik-observability

注意: 在Traefik-2.X的生态里,将可观测性分为了如下几个部分,并提升到了专门的功能说明中

  • 服务日志: Traefik进程本身相关的操作日志
  • 访问日志: 由Traefik接管的代理服务的访问日志(access.log)
  • Metrics: Traefik提供的自身详细的metrics数据
  • Tracing: Traefik也提供了追踪相关的接口,用来可视化分布式或微服务中的调用情况