技术债在软件开发过程中不可避免。但是，在紧急的产品需求面前，技术债往往会被人忽略，解决时期一拖再拖。长此以往，技术债像滚雪球般越滚越大，给我们的迭代开发将会带来致命影响，偿还技术债的成本也会成倍增加，所以我们必须重视技术债，积极还债。本文会带领大家一起探讨什么是技术债，技术债的危害，日常工作中哪些场景容易产生技术债，如何管理我们的技术债以及如何偿还技术债。希望本文能够起到抛砖引玉的作用，让大家在技术债面前少踩坑，争取早日达到“债少一身轻”。
KMS 是一家日本的游戏公司，主要经营游戏业务、数字漫画业务、广告业务、云解决方案业务等，出品了多款在日本畅销的漫画风游戏，同时有网络漫画专业厂牌，以内容创作为目标，拥有原创 IP 创作、游戏开发等多元化发展的业务。 KMS 曾经是微软 Azure 的标杆客户，曾经在 Azure 的 Customer story 里有详细的介绍，主要是使用了 Azure 的 App Service。 2021年，KMS 开始迁移到腾讯云，并把第一款产品部署在了腾讯云上。从 Azure 迁移到腾讯云上后，整体成本降低50%。下面我们就来讲讲他们在腾讯云上的微服务实践。
全球推荐系统领域顶级会议ACM RecSys于9月18-22日在新加坡举行。东北大学与腾讯微信看一看团队针对推荐系统中用户留存优化的最新研究论文“Interpretable User Retention Modeling in Recommendation” 获得大会最佳短文奖（Best Short Paper Award）。该论文由入选2022犀牛鸟精英人才计划的丁蕊同学在学界导师杨晓春教授和微信看一看谢若冰高级研究员的联合培养下主要完成。
擅长 OLAP 分析的 ClickHouse 不仅可以用于 vector search，还可承担起整条 embedding 的加工处理工作,All in one Pipeline 也让速度远超传统批处理框架数倍；检索性能虽无法与专业 sim 检索服务相媲美，但因“搜索分析一体化”，让它在 AI 近线处理占据一席之地。 本文工作由 vcc、 levi、 longpo、 zifei、 luis 等人协同完成
互联网发展早期，业务场景差异大，试错迭代速度很快。这导致其后台服务使用的语言技术栈、开发框架、通信协议、服务治理系统、运维平台等或多或少存在差异。 业务发展到一定阶段后，跨业务合作越来越多，组织架构调整也愈发频繁。技术体系差异，特别是开发框架的不统一，给业务互通带来巨大成本，也导致开发和运营的效率难以快速提高。 同时，随着云原生技术的发展，业务越来越多地使用开源技术和云组件。拥抱云原生已经是一种主流趋势。 上述问题在腾讯内部也同样存在，且因为规模大、业务类型多，更加难以解决，更必须解决。tRPC 就是在这种背景下诞生的。
最近在 Discord 的技术 blog 看到 Discord 的底层数据存储的演进过程，从最开始的 2015 初用的单个副本集的 MongoDB，2015 年底迁移到 Cassandra，2022 年消息量达到了万亿的级别，他们将存储迁移到 ScyllaDB。本文会介绍 ScyllaDB 的基本架构和原理，分析下 ScyllaDB 能够支持万亿级存储的原因。
冯友兰治哲学，提出“照着讲”和“接着讲”的方法论。近两年，我断断续续梳理出关于领域驱动设计的两个 PPT：《领域驱动设计》和《领域驱动设计四论》。前者的内容主要是关于 DDD 经典著作的读书笔记，可视为照着讲，以证明自己学有所本，讲的不是野狐禅；后者则是在继承的基础上所做的创新阐释，可视为接着讲，发前人之未发。本文重点围绕《四论》展开，从四个方面梳理出 DDD 的整个逻辑脉络。 曾见郭象注庄子,却是庄子注郭象。一些领域驱动设计的拥趸者，如果看到本文的论述和自己的理解相左，丝毫不用奇怪，本文阐述的四论，不是我注六经，而是六经注我。 本文是 DDD 系列三篇文章的开篇，为你提纲挈领地梳理出 DDD 的核心脉络。在后两篇文章中，我们还将展开分享 DDD 的系统架构设计与核心概念、关键方法等内容。
如果说计算机工程王冠中有明珠的话，操作系统、数据库、编译器必定是其中最闪耀的那几颗。能够制造打磨出这种明珠的人，做到了其他人做不到的事情，也便成了人们口中的“神”。笔者在学习了“神”们撰写的编译器入门书籍之后，分享一些心得给感兴趣的读者，希望能激发出大家的学习兴趣。
