Kubernetes 作为一项核心技术已成为现代应用程序架构的基础，越来越多的企业使用其作为容器编排系统。Kubernetes 集群经历了 从单 Kubernetes 集群到多 Kubernetes 集群、从多 Kubernetes 集群到 Kubernetes 多集群的演进[1]，集群的展现形式不断发生着变化。 为此，Kubernetes 多集群 SIG 提出了 KEP-1645: Multi-Cluster Services API[2]（以下简称 MCS API）应对 Kubernetes 多集群带来的挑战，详细内容可以看之前的介绍：认识一下 Kubernetes 多集群服务 API[3] ，这篇要介绍的是多集群服务 DNS。
本文记录了一次问题的排查过程，从中可以学到不少共性的方法论和经验教训，所以做了提炼归纳。（文末有活动）
随着业务日益复杂，应用微服务化已成为主流趋势，业务领域通常在多个微服务应用中实现。DevOps 工程从应用角度，虽实现了应用流水线和项目流水线，但也面临着测试阶段管理多套应用流水线的复杂场景。通常情况下，这些业务会存在多套互相隔离的环境，而这些环境的构建也依赖人工处理资源申请和部署。由于构建不易，这些环境通常被长期反复使用，并需要定期与生产环境同步以确保开发和测试的有效准确。这些工作要求工程师对业务的应用架构熟悉且有时间频繁进行操作，但实际上这些工作大多落在项目资深的 DEV 或 QA 身上，浪费了宝贵的人力资源。因此，我们可以考虑建立“环境构建平台”，实现环境即用即建，让 DEV 和 QA 专注于自己擅长的事情，并最终节约人力资源提升效率。Qunar 的基础平台团队对此问题进行了长期实践，本文将分享 Qunar 在测试环境治理领域的实践经验和思考。
当我们在面对一些用户反馈的运行问题时，如白屏，页面加载时间过长，页面卡顿等等，如果能够知道客户端的哪些行为导致了问题的出现，那么在定位解决问题上一定会变得事半功倍。 如客户端白屏可能是某个静态资源挂了，页面加载时间过长可能是静态资源的cdn托管服务不稳定，页面卡顿可能是长耗时的js调用导致阻塞了主线程，为了帮助开发快速收集问题出现时客户端所发生的上下文信息
现代系统正变得越来越复杂，从单线程到多线程，从单体到微服务，从单节点到分布式，从本地到云端... … 复杂度使得程序产生预期的结果需要越来越多的必要条件，而每种条件都有其自身的成功概率，即使每种条件的成功概率都很高，根据墨菲定律，或早或晚一定会遇到不可预知的结果。 在数据工程领域，这个问题尤其突出，目前大数据领域几乎都是分布式运行的任务、高可用的消息队列、多备份的存储、主从节点等等。在这样的情况下，如何构建稳定、健壮的任务或服务成为了一个挑战。而数据工程实践中每日调度的任务成为了与各个复杂数据组件交互的最主要形式，所以本文我们将以数据工程的任务调度为例，利用混沌工程帮助我们找出系统薄弱点或脆弱性，引出我们沉淀的基于日志驱动的任务调度实践。
作者系统详实的介绍了什么是AsyncLocalStorage、如何使用、Node 是如何实现的 AsyncHook等。不论你是0基础还是对此API有些了解的读者都比较适合阅读此文。（文末有活动）
通过阅读了多篇围绕大模型应用、提示词工程等等的文章，结合之前的工程经验，对于如何围绕大模型来进行应用设计有了些新的理解，整理成这篇文章。
1. 如何解决业务方在小程序、H5应用上的接入地图服务的困扰？ 我们统一收口哈啰&高德服务能力，业务侧不需要每次接入LBS和高德服务都做http服务的接入工作，只用接入地图提供的组件包。我们还提供在类型声明，线接入文档，简化业务方的接入成本和工作量。 2. 总是担心服务不稳定，如何缓解心智负担？ 我们在前端侧优化了请求策略，加入了降级兜底能力，稳定性更有保障。 3. 面对调用量增长，减轻服务压力，将如何面对？ 我们从缓存方面入手，为调用量特别突出的逆地理设计缓存方案，通过缓存机制来减少调用，减轻服务压力。
