可观测性是指在一个系统中，我们可以通过一系列的工具、技术和方法来获取对系统运行状态的深入洞察和理解。它包括了日志、指标、追踪等多种手段，可以帮助开发人员和运维人员更好地理解系统的行为，及时发现和解决问题，提高系统的可靠性和可维护性。 日常的日志和监控是可观测性的两个重要组成部分，但并不等同于可观测性。日志是记录系统运行过程中发生的事件和状态的文本记录，可以帮助我们了解系统的运行情况和问题发生的原因；监控是通过定期收集系统的指标数据，对系统的运行状态进行实时监控，以便及时发现和解决问题。而可观测性不仅包括了日志和监控，还包括了追踪、分布式跟踪、异常检测等多种手段，通过这些手段，我们可以更全面地了解系统的运行情况，及时发现和解决问题，从而提高系统的可靠性和可维护性。
最近因为在公司的笔记本上写博文，所以并不打算采用在terminal中使用hugo new的方式来生成新的博文模板，而是自己在vs code中
编写好之后然后手动在github的网页新增文件触发github actions的执行然后部署到vps上。
然后发现自己新写的文章居然展示不出来。排查了一下博文前面的头信息：
中间件项目中，经常会有下面的场景：
这种其实都是在某一个时间点触发一些任务，但是当任务量很大时，怎么做比较高效呢？
比如client定时向server发心跳包，在server端如何对client进行判活呢？一般我们的做法主要有下面的几种，当任务量很大的时候我们一般都会采样环形队列/HashedWheelTimer方法。
关于同步、异步、阻塞和非阻塞这个概念性问题，这可能是非常容易混淆的概念之一，特别是那些刚开始解除网络编程的人来说。本篇文章争取来说清楚这个问题，如果有错误之处，恳请批评指正。
首先大家心中需要有以下的清晰认知：
这篇文章主要总结整理一下最近工作中两套监控系统合并过程中使用模板功能来抽象【针对应用相关的监控】 和【针对机器相关的监控】的差异。
公司主要的监控系统主要是针对应用级别的，所有的指标都是属于App级别的，也就是想看某条监控指标数据，首先需要选定具体的APP。 然后公司也有一套针对机器相关的监控系统，因为机器相关的监控很多时候是以机器为维度的，也就是想查询某个机器的指标数据时 需要先指定具体的机器。同时由于公司业务的特殊性，也需要增加对多种终端类型（比如门店、货柜）的监控相关的功能。同时考虑到开发 、维护等成本等等的诸多因素，现在需要将两套监控系统合并。因此需要一套通用的模型来抽象这种问题。
不知道你觉的工作多年的开发者最重要的技能是什么？
随着工作经历的增长，我个人越来越觉得对于开发者来说，很多时候个人的专业技能反而并不是最重要的，甚至在很多的时候是最廉价，最容易被替代的。反而是一些非专业技能确显得更加的重要。我觉的按照优先级从高到低依次为：
首先必须得说一下，我并没有实际参与过电商系统相关的业务，我一直工作的项目组做的事情和本篇文章要讲的东西完全不同。因此本篇文章仅仅是我自己平时观察和构想的一些整理，如果有不太合理的地方，希望大家指正，先谢谢大家。
在各大电商网站上，基本时时刻刻都可以看到促销活动。相信大家基本都参与过一些促销活动。随着业务的复杂化、运营的精细化，以及品类、平台、渠道的不断丰富，各种新的促销形式也层出不穷，贯穿从商品展示、搜索、购买、支付等整个流程。虽然促销的商品本身千差万别，但是但对于促销这个事情来说，又有很多共同的地方，本篇文章希望可以归纳总结出一套设计促销系统模型的方法论出来。
本文主要是初步记录一下关于单据零散的想法，看看是否可以形成一套可行的方法论。
单据这个实体，其实从抽象的层面来说，它其实描述了一次行为：
谁，在什么时间点，用了什么样的成本，对什么目标产生了一次什么样的行为
如果让我们来对上面这句话进行解析，其实可以发现它可以拆分为下面几块：
工作和学习过程中经常会遇到陌生的系统需要去熟悉，下面是我总结的一些自己的方法论，希望对你有所帮助。
首先我们需要对系统有一个Overview的了解，了解的方式可以是自己摸索，找对应系统负责人，团队leader聊，也可以自己找wiki，文档等方法。我简单的总结了一下步骤：
微信
支付宝