后台分布式架构形形色色，特别是微服务和云原生的兴起，诞生了一批批经典的分布式架构，然而在公司内部，或者其他大型互联网企业，都是抛出自己的架构，从接入层，逻辑层，数据层都各有特点，但这些系统设计中到底是出于何种考量，有没有一些参考的脉络呢，本文将从云原生和微服务，有状态服务，无状态服务以及分布式系统等维度探讨这些脉络。
Pulsar Meetup 2024 北京站已经成功落下帷幕。在本次盛会中，腾讯云的高级工程师韩明泽和王震江为与会者带来了精彩的演讲。他们围绕多网接入、集群迁移以及高可用最佳实践这三大核心议题，深入剖析了《腾讯云上基于 Apache Pulsar 的大规模生产实践》，为听众呈现了一场知识与经验交织的盛宴。
Swift Macro 在 Swift 5.9 版本中正式引入，且需配合 Xcode 15 使用。Swift Macro 作为一种新的设计方法，致力于帮开发者降低编写重复代码的繁琐，以更为简洁优雅的方式去实现。 在 OC 中，有大家熟知的宏 #define，但是在 Swift 5.9之前我们无法像使用 OC 一样去定义宏，在 Swift 中没有这种宏的概念，只能通过静态方法去模拟宏从而达到目的。 OC 宏的实现原理是纯文本的替换,在编译之前通过预处理器帮我们对标记了 #define 的表达式进行展开替换,但是纯文本替换会产生一系列问题，比如 命名冲突，类型检查，调试问题等。
百度MEG上一代大数据产品存在平台分散、质量不均和易用性差等问题，导致开发效率低下、学习成本高，业务需求响应迟缓。为了解决这些问题，百度MEG内部开发了图灵3.0生态系统，包括Turing Data Engine(TDE)计算引擎、Turing Data Studio(TDS)数据开发治理平台和Turing Data Analysis(TDA)可视化BI产品。依托图灵3.0生态，我们进而形成了一套新的开发范式——"OneData+开发范式"，其关键在于可视化分析与数据集的构建。 TDE-ClickHouse作为图灵3.0生态中重要的基础引擎之一，专注于为业务提供海量数据下的自助秒级分析能力。通过高性能的数据查询能力与高效的数据导入通路，支持业务更及时、敏捷地对海量数据进行分析；通过稳定可靠的分布式架构，在减少资源和运维成本的同时，严控引擎侧的数据质量。
刚工作时，代码写得不太好，师兄每次 CR 代码，总是会指着屏幕里的一坨代码说 “把它抽成一个类或函数”；“为什么呢？写在一起不是挺好的吗？” 我反问道；师兄老道地回答 “为了方便复用”；我仿佛若有所得，回到工位上把那些很长的代码全部抽象成了类和函数，感觉今天又有所成长。 但是随着工作经验的增加，我对此又产生了困惑。随着业务发展得越来越复杂，我当初写的那个类被大量复用，为了适应不同的场景，里面充满了 if...else...；最能代表复用的业务中台，因为分支太多，发布和开发无比复杂，很小的一个改动却需要拉一堆团队讨论。 所以类和函数的存在究竟是为了什么？只有站在更高的视角才能解决我的困惑，这也是本文的内容。根据奥卡姆剃刀原则，本文其实用一句话就能概括， 它也是 《复杂软件设计之道》 中我最喜欢的一句话 ：类和函数不是为了复用而存在，而是他们本来就 “应该” 在那里。
Tritonserver是Nvidia推出的基于GPU和CPU的在线推理服务解决方案，因其具有高性能的并发处理和支持几乎所有主流机器学习框架模型的特点，是目前云端的GPU服务高效部署的主流方案。 Tritonserver的部署是以模型仓库(Model Repository)的形式体现的，即需要模型文件和配置文件，且按一定的格式放置如下，根目录下每个模型有各自的文件夹。
