过去几年，公有云凭借着更高扩展性、灵活性、可靠性和安全性，吸引了大量的企业将应用程序部署到公有云上。随着业务规模的不断扩张，企业出于某些原因，如避免厂商锁定、追求更低的延迟、更高的可靠性等，选择将应用部署在更多的公有云上；也有些企业出于数据敏感性等原因，选择将部分应用部署有私有环境中。后者也更像是将上云的过程拉长。不管是多云还是混合云，基础设施都不可避免的存在着差异，企业不得不在适配底层设施上投入了大量的人力物力。 Kubernetes 的出现，完美地解决了这一问题。除了屏蔽基础设施层的差异解决了跨平台的问题，还提供自动化的容器编排、更高的扩展性、弹性和高可用性，其背后更是有着庞大的社区的支持。Kubernetes 的风靡，得到了大量企业的青睐。随着时间的推移，企业使用多个 Kubernetes 集群管理应用的情况越来越普遍。 如何在跨越多个集群、甚至是混合多云的环境下来管理应用成了新的难题。Karmada[1] 的出现正是要解决这一问题。
正文开始之前，想先问你一个问题：说到 DDD（Domain Driven Design），你的第一反应是什么，想一想？ 对于这个玩意，最早接触的时候觉得这个东西太高深了，有点把握不住，云里雾里的感觉。 但是随着自己一点点深入的了解，其实发现这玩意其实“不过如此”，DDD 并不是一种新技术名称，应用框架之类的东西，而是一种比较好的业务重构的思想、一种独具特色的架构风格。 事实上，作为软件开发方法学层面的 DDD，并不仅仅局限于像微服务这样特定的架构风格，而是在企业数字化转型中有着广泛的应用。因此，目前各大公司也纷纷在核心业务中落地 DDD，例如京东物流、阿里零售、美团等等。 虽然 DDD 在这几年越来越流行，但不少人对 DDD 的基本概念、核心技能还不能充分地掌握，从而影响了 DDD 的学习和落地。
在系统的开发过程中，很多开发者都为了实现系统的高可用性而发愁。本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用系统的架构设计需要有哪些关键的设计和考虑。希望腾讯的经验方法，能够给广大开发者提供参考。内容较长，您可以收藏后持续阅读。
忙忙碌碌一天下来工作效率大大折扣，时间都不知道花到哪里了。相信很多人都存在这个困惑，做一件事时想到另外一件事或者被其他事情打乱节奏，如果你也存在这种情况建议精读这篇文章，一定会对你有所帮助。
Prop drilling 是指当上层组件中持有 state，而一个深度嵌套的组件需要使用这个 state 时，一种做法是用 props 透过中间组件一层层往下传，尽管中间组件并不需要他们。 只需要做一下重构就可以避免 prop drilling：
笔者近期在尝试解决低资源场景下的文本分类任务时，发现使用一些在ModelScope社区上开源的零样本分类模型就可以极大提高分类准确率。因此对零样本文本分类模型进行了梳理，希望对大家有所帮助。
提到Spring依赖注入，大家最先想到应该是@Resource和@Autowired，很多文章只是讲解了功能上的区别，对于Spring为什么要支持两个这么类似的注解却未提到，属于知其然而不知其所以然。不知大家在使用这两个注解的时候有没有想过，@Resource又支持名字又支持类型，还要@Autowired干嘛，难道是Spring官方没事做了？ 真的是没事做了吗？读了本文你将会了解到： @Resource和@Autowired来源 Spring官方为什么会支持这两个功能如此相似的注解？ 为什么@Autowired属性注入的时候Idea会曝出黄色的警告？ @Resource和@Autowired推荐用法
下图示为手淘网络协议演进关键节点。2015年为优化标准TLS/1.2握手慢问题，我们自行研制上线了轻量级私有加密协议Slight SSL来优化握手与加密问题，在没有重放攻击风险时允许将会话协商和数据加密放在一个TCP报文中来实现0-RTT，目前手淘线上流量HTTP2+SlightSSL也是主要承载者。与此同时过往问题排查/业务接入/业务诉求面临一些疑难或者无法满足诉求问题，诸如 "WI-FI下长链全失败降级短链https可以成功，切换到4G网长链正常使用（SlightSSL私有协议被wifi防火墙断开）"、"你们计划支持TLS1.3吗？"、"我们域名接入服务端不支持部署SlightSSL"等；另一方面随着QUIC RFC9000、HTTP3 RFC9114正式发布，将手淘网络协议演进到HTTP3/QUIC不管是解决Slight SSL私有协议在业务上痛点，还是为了提高网络传输性能提升用户体验，同时也是当下网络协议向前演进的大势所趋。私有化协议带来高效网络体验的同时，归纳起来问题主要集中在以下三点： 私有化的协议意味着更定制，需要端到端的部署支持（侵入性） 不支持TLS1.3 偶有网络
