Kubernetes 中应用实例数设置有固定实例数、HPA 和 CronHPA 三种策略。使用最多的是固定实例数，但是很多业务都存在波峰浪谷，如果采用固定实例数的方式会造成较大的资源浪费。Kubernetes 中提供了 HPA 及 CronHPA 两种机制实现按需扩容实例数量，减少资源浪费。CronHPA 是用户设定定时规则，在固定时间进行实例数伸缩。但是设定定时规则较为复杂，如果定时间隔设置较大就会造成资源浪费。HPA 可以根据应用实时负载设置实例数量，当应用负载高时扩容，当应用负载低时则缩容实例。HPA 是基于实时负载进行扩容，只有当负载已经比较高时才会触发扩容，但此时业务已经处在高负载中因此业务部分流量出现响应慢或者超时的问题，即存在“弹性滞后”的问题。为此，我们提出了一种智能化弹性伸缩方案 AHPA，可以根据历史时序数据进行主动预测，提前扩容，避免弹性滞后。同时，会根据实时数据动态调整主动预测结果，兼容周期变动等场景。
IDC 预计到 2024 年，由于采用了微服务、容器、动态编排和 DevOps 等技术，新增的生产级云原生应用在新应用的占比将从 2020 年的 10% 增加到 60%，其中微服务的 workload 在企业内将超过 80% 。上面的四点是云原生时代所代表的四个核心技术。其中，我们的开发同学可能对于微服务比较热衷，从近几年的趋势来看，Java 领域的微服务框架日趋成熟，和云原生的结合也越来越紧密。从 EDAS 中的数据来看，Spring Cloud + Kubernetes 基本上已经成为了微服务架构形态下的主流配搭。但是另外一个数据让我产生了更多的好奇，就是目前在云原生场景下有过微服务生产经验的开发人员不足 8% 。为什么会是这个样子？我觉得主要原因有两个：
日志服务平台作为可观测性平台提供了数据导入、数据加工、聚集加工、告警、智能巡检、导出等功能，这些功能在日志服务被称为任务，并且具有大规模的应用，接下来主要介绍下这些任务的调度框架的设计与实践。
即使已经到了2022年， 在面向复杂多变的用户端开发领域，我们依然绕不开一个问题 ？我们选择什么技术更适应我们的业务场景，不管是通用还是独特。这回到一个问题的原点，每一种技术都有它的局限性（短板）。
CI/CD 的概念非本文重点，不解释了。从上图可以看出。Continuous Profiling（持续性能分析，下文简称为 CP）是生产向开发进行反馈的非常重要的手段。
我们在进行软件开发时要想实现可维护、可扩展，就需要尽量复用代码，并且降低代码的耦合度，而设计模式就是一种可以提高代码可复用性、可维护性、可扩展性以及可读性的解决方案。 大家熟知的23种设计模式，可以分为创建型模式、结构型模式和行为型模式三大类。其中，创建型模式是对类的实例化过程进行抽象，从而将对象的创建和使用分离开。工厂模式属于创建型模式的范畴，本文将着眼于工厂模式，从简单工厂模式、工厂方法模式和抽象工厂模式出发，展开学习和深入探讨。（本文如有表述不当的地方也恭请大佬们指教哦～）
去年的Log4j-core的安全问题，再次把供应链安全推向了高潮。在供应链安全的场景，蚂蚁集团在静态代码扫描平台-STC和资产威胁透视平台-哈勃这2款产品在联合合作下，优势互补，很好的解决了直接依赖和间接依赖的场景。 但是由于STC是基于事前，受限于扫描效率存在遗漏的风险面，而哈勃又是基于事后，存在修复时间上的风险。基于此，笔者尝试寻找一种方式可以同时解决2款产品的短板。笔者尝试研究了一下Maven是如何处理一个项目中的直接依赖和间接依赖的，并且在遇到相同依赖时，Maven是如何进行抉择的，这里的如何抉择其实就是Maven的仲裁机制。带着这些问题，笔者尝试调研了Maven的源码和做了一些本地的测试实验。总结了这篇文章。
