目前的微服务架构中，通常包含服务消费者、服务提供者、注册中心、服务治理四元素，其中服务消费者会向注册中心获取服务提供者的地址列表，并根据路由策略选出需要调用的目标服务提供者地址列表，最后根据负载算法直接调用提供者。当大规模生产环境下，服务消费者从注册中心获取到的服务提供者地址列表过大时，采用传统的路由方式在每次服务调用时都进行大量地址路由选址逻辑，导致服务调用性能低下，资源消耗过多。
Helm Charts 如今已是一种非常流行的软件打包方式，在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中，业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下，单纯依赖 Helm 工具可能无法做到灵活的部署和交付。
定时任务作为一种按照约定时间执行预期逻辑的通用模式，在企业级开发中承载着丰富的业务场景，诸如后台定时同步数据生成报表，定时清理磁盘日志文件，定时扫描超时订单进行补偿回调等。程序开发人员在定时任务领域有着诸多框架和方案可供选择，并借此快速实现业务功能实现产品上线。本文将就当前主流定时任务解决方案进行介绍和分析，期望可以在企业技术选型和项目架构重构时作为参考。
从“上云”到“云上”原生，云原生提供了最优用云路径，云原生的技术价值已被广泛认可。当前行业用户全面转型云原生已是大势所趋，用户侧云原生平台建设和应用云原生化改造进程正在加速。然而，云原生复杂的技术栈和传统IT的历史包袱给用户带来了巨大挑战，针对平台建设和应用改造的能力要求缺少统一规范成为企业转型的最大障碍。在用户侧，企业执行层面存在“三难”问题，即诊断难、规划难、选型难，需求和供给不能精准对应，缺少权威建设指南；在技术供给侧，技术迭代加速，产品能力构建缺少行业“灯塔”，技术押宝的风险掣肘发展。
本文尝试从 CommonJS 和 ES Module 两者规范的差异，详细说明该配置是如何影响 tsc 编译结果的。
单元测试是我们常用的验证代码正确性的工具，但是如果只用来验证正确性的话，那就是真是 “大炮打蚊子”--大材小用，它还可以帮助我们评判代码的抽象程度与设计水平。本文还会提出一个以“可测试性”为目标，不断迭代重构代码的思路，利用这个思路，面对任何复杂的代码，都能逐步推导出重构思路。为了保证直观，本文会以一个 “生产者消费者” 的代码重构示例贯穿始终。最后还会以业务上常见的 Excel 导出系统为例简单阐述一个业务上的重构实例。
