互联网发展早期，业务场景差异大，试错迭代速度很快。这导致其后台服务使用的语言技术栈、开发框架、通信协议、服务治理系统、运维平台等或多或少存在差异。 业务发展到一定阶段后，跨业务合作越来越多，组织架构调整也愈发频繁。技术体系差异，特别是开发框架的不统一，给业务互通带来巨大成本，也导致开发和运营的效率难以快速提高。 同时，随着云原生技术的发展，业务越来越多地使用开源技术和云组件。拥抱云原生已经是一种主流趋势。 上述问题在腾讯内部也同样存在，且因为规模大、业务类型多，更加难以解决，更必须解决。tRPC 就是在这种背景下诞生的。
最近在 Discord 的技术 blog 看到 Discord 的底层数据存储的演进过程，从最开始的 2015 初用的单个副本集的 MongoDB，2015 年底迁移到 Cassandra，2022 年消息量达到了万亿的级别，他们将存储迁移到 ScyllaDB。本文会介绍 ScyllaDB 的基本架构和原理，分析下 ScyllaDB 能够支持万亿级存储的原因。
冯友兰治哲学，提出“照着讲”和“接着讲”的方法论。近两年，我断断续续梳理出关于领域驱动设计的两个 PPT：《领域驱动设计》和《领域驱动设计四论》。前者的内容主要是关于 DDD 经典著作的读书笔记，可视为照着讲，以证明自己学有所本，讲的不是野狐禅；后者则是在继承的基础上所做的创新阐释，可视为接着讲，发前人之未发。本文重点围绕《四论》展开，从四个方面梳理出 DDD 的整个逻辑脉络。 曾见郭象注庄子,却是庄子注郭象。一些领域驱动设计的拥趸者，如果看到本文的论述和自己的理解相左，丝毫不用奇怪，本文阐述的四论，不是我注六经，而是六经注我。 本文是 DDD 系列三篇文章的开篇，为你提纲挈领地梳理出 DDD 的核心脉络。在后两篇文章中，我们还将展开分享 DDD 的系统架构设计与核心概念、关键方法等内容。
如果说计算机工程王冠中有明珠的话，操作系统、数据库、编译器必定是其中最闪耀的那几颗。能够制造打磨出这种明珠的人，做到了其他人做不到的事情，也便成了人们口中的“神”。笔者在学习了“神”们撰写的编译器入门书籍之后，分享一些心得给感兴趣的读者，希望能激发出大家的学习兴趣。
本文主要接着《鹅厂练习13年 Coding 后，我悟了》的内容给大家带来工程师的自我修养，下面是一些在 review 细节中不能直接使用的原则。更像是一种信念和自我约束。带着这些信念去编写、review 代码，把这些信念在实践中传递下去，将是极有价值的。
随着大模型热度持续，基于大模型的各类应用层出不穷。Langchain 作为一个以 LLM 模型为核心的开发框架，可以帮助我们灵活地创建各类应用，同时也为大模型的应用引入新的安全隐患。从今年 4 月 Langchain 被爆出在野 0day 漏洞开始，各类安全问题不断出现。腾讯安全平台部将持续关注大模型的应用安全，详细解读在大模型应用时代，如何与时俱进地保持安全策略，以保障大模型安全、可靠地应用。
大数据领域流批一体和湖仓一体都是技术演进的趋势，技术大一统是每个 coder 的浪漫。微信实验平台从 2022 年 Q1 开始引入 iceberg 作为湖仓一体解决方案，最早从 0.14.1 版本开始引入到如今的 1.2.2 版本的广泛使用，目标是为了优化现有流程，达到更快(计算时效性)及更省(节省更多资源)。
