谢谢！
前几天，有位朋友问我，你平时都是怎么去排查一个程序的性能问题的啊。说到性能问题，可能大家立马会想到类似并发数、吞吐量、响应时间、QPS、TPS等等这些指标，这些指标的确可以反映出一个系统性能的好坏。
可随着我们的系统结构变得越来越复杂，要找到这样一个性能的“损耗点”，同样会变得越来越困难。在不同的人的眼中，对于性能好坏的评判标准是不一样的，譬如在前端眼中，页面打开速度的快慢代表着性能的好坏；而在后端眼中，并发数、吞吐量和响应时间代表着性能的好坏；而在 DBA 眼中，一条 SQL 语句的执行效率代表着性能的好坏。更不用说，现实世界中的程序要在硬件、网络的世界里来回穿梭了，所以，从 80%的功能堆积到 100%，是件非常容易的事情；而从 80%的性能优化到 85%，则不是件非常轻松的事情。
想清楚这一点非常简单，因为我们的系统从来都不是简单的1 + 1 = 2。此时，我们需要一个性能分析工具，而今天给大家分享的是 JetBrains 出品的 dotTrace 。
我们使用Go标准库中的net包，很容易发送UDP和TCP的packet，以及在它们基础上开发应用层的程序，比如HTTP、RPC等框架和程序，甚至我们可以利用官方扩展包golang.org/x/net/icmp,专门进行icmp packet的发送和接收，不过，有时候我们想进行更低层次的网络通讯，这个时候我们就需要借助一些额外的库，或者做一些额外的设置，当前相关的介绍IP层packet收发技术并没有很好的组织和介绍，本文尝试介绍几种收发IP packet的方式。
传统的 Java 应用开发模式基本不会去了解容器的内存大小，因为以前大家的应用都是部署在一个内存较大的虚拟机上，所以感知不到容器内存的限制。这样很容易让自动生成的 Xmx 大于了容器的内存大小，以致于 OOM。推荐 JVM 的配置小于容器限制的 2/3，预留一些内存。
复杂系统学科里已经对涌现现象做过很久的相关研究。那么，什么是“涌现现象”？当一个复杂系统由很多微小个体构成，这些微小个体凑到一起，相互作用，当数量足够多时，在宏观层面上展现出微观个体无法解释的特殊现象，就可以称之为“涌现现象”。
在日常生活中也有一些涌现现象，比如雪花的形成、堵车、动物迁徙、涡流形成等。这里以雪花为例来解释：雪花的构成是水分子，水分子很小，但是大量的水分子如果在外界温度条件变化的前提下相互作用，在宏观层面就会形成一个很规律、很对称、很美丽的雪花。
那么问题是：超级大模型会不会出现涌现现象？显然我们很多人都知道答案，答案是会的。
美团到店餐饮算法团队在跨域迁移学习的长期实践中，基于多场景的业务背景，提出了分层信息抽取网络，提升了多场景多任务的建模效果。相关技术方案形成的学术论文已经被国际数据工程会议ICDE 2023收录，本文详细阐述了多场景&多任务学习的解决方案，希望能给从事相关方向研究的同学带来一些帮助或启发。
对于一款支持海量数据分析系统而言，能支持 DML 查询实属难得可贵。在海量的数据场景下，很多看似简单的操作也会变得举步维艰，所以一些系统会选择做减法来规避一些难题。而 ClickHouse 支持完备的 DML 命令，包括 INSERT、SELECT、UPDATE 和 DELETE。虽UPDATE 和 DELETE 可能会存在一些性能问题，但这些能力的提供确实丰富了架构师的筹码，在架构设计师可以多几个选择。
作为一款完备的 DBMS，ClickHouse 提供了 DDL 和 DML 功能，并支持大部分标准的SQL。这也是 ClickHouse 相对容易上手的原因。但作为一款异军突起的 OLAP 数据库黑马，ClickHouse 有着属于自己的设计目标，高性能才是它的根本。比如 ClickHouse 在基础数据方面相比于其他常规数据库会少一些，但它又同时提供了实用的复合数据类型，而这些复合类型是常规数据库所不具备的。再比如，ClickHouse 所提供的 DDL 和 DML 查询，在部分细节上和其他数据库也是不同的（例如 UPDATE、DELETE 是借助 ALTER 的变种实现的）。
所以掌握 ClickHouse 中的数据定义方法是很重要的，这能帮助我们深刻理解和使用 ClickHouse。
这篇文章要介绍的 cert-mangager，跟 certbot 这类工具有点类似，区别在于它是工作在 Kubernetes 中的。
cert-manager 是一个证书的自动化管理工具，用于在 Kubernetes 集群中自动化地颁发与管理各种来源、各种用途的数字证书。它将确保证书有效，并在合适的时间自动更新证书。
本文记录复盘的是一次k8s集群相关的生产故障。
随着服务增多，集群的庞大，一些未知问题就必然会出现（而如果集群规模较小，也就基本不会遇到了）。
对于一开始未知原因、诡异、没有思路的问题或者bug，往往利用穷举法列出所有可能的原因，然后采取最小化复现、差异化对比等等，基本能解决大部分这类问题。
本文简要分析了Dockerfile为什么这么大的几个主要原因，并且根据生产经验罗列了一些优化镜像大小的措施以及其他方面常用的处理办法，很多技巧性的内容，比较杂乱，就不一一提及了 ~
本文分析介绍基于ack，结合k8s原生调度方式，综合考虑现有应用自身特性、节点池资源特性、成本、效率等方向而设计的调度规范参考。
后续随着业务的复杂性增强，会将更多的调度设计原理与业务相结合，充分利用公有云及k8s的新生特性，例如在离线业务混合部署、拓扑感知调度、二次调度、弹性容器实例ECI、Serveless函数计算等，甚至于出现可用的调度方式都不满足的调度需求，实现自定义调度，进而实现更多更好更强贴近业务、使用效率提升的服务调度方式，根据更多的数据指标和服务中链路的追踪来进一步优化业务，最终实现业务的快速迭代、自动部署、独立高效。
在创业公司担任管理者时，是不能照搬大公司的管理制度和流程的。
一方面是因为公司规模不同，导致能够使用的资源有限，很多创业公司在照搬大公司的管理制度时，往往会听到员工吐槽“又要 996，又不给加班费；又没有大公司的命，又得了大公司的病”。毕竟创业公司总是人手有限，管理者除了担任管理职能以外，往往还需要真的做事，如果在一家几十个人的创业公司里，管理者的工作就是看日报，盯工时和开会，那对于基层员工将会是一件很无奈的事情（毕竟创业公司里要做的事情总是太多了）。
以我个人的经验来说，在这种时候，相比选择花费时间去学习管理课程/书籍，参与 MBA 的课程能够起到的作用并不大（并不是说不好）。毕竟“纸上得来终觉浅，绝知此事要躬行”，管理课程书籍中提供的往往是那种“正确但又难以在短时间内落地的知识”，而由于不同公司的企业文化，组织结构和可用资源，很难找出一种对所有公司都有效的“具体方法”。
在之前的文章《如何管理新的产品团队》中，我分享了一些以往的心得和经验，刚好最近又有一些新的想法，与大家进行分享。