故障无处不在，而且无法避免。（分布式计算谬误） 在分布式系统建设的过程中，我们思考的重点不是避免故障，而是拥抱故障，通过构建高可用架构体系来获得优雅应对故障的能力。QQ音乐高可用架构体系包含三个子系统：架构、工具链和可观测性。
OLAP计算引擎是一架机器，而操作这架机器的是编程语言。使用者通过特定语言告诉计算引擎，需要读取哪些数据、以及需要进行什么样的计算。编程语言有很多种，任何人都可以设计出一门编程语言，然后设计对应的编译器做解析。编程语言从分类上来说，可以分为命令式，声明式。 命令式编程语言是我们最常见的编程语言，C/C++/Java等都是命令式编程语言，这类语言明确的告诉机器应该执行什么样的指令，留给编译器优化的空间很小了。 声明式编程描述程序应该获得什么结果，至于如何做到，并不关注细节。SQL就是一种声明式编程语言。例如SQL语句select count(1) from department where kpi =3.25，指明计算kpi=3.25的人数，但不会具体指定如何完成计算。这给后续的优化器留下了很大的操作空间，优化器可以根据SQL的需求和实际的数据做各种各样的探索，寻找到最佳的执行方式。
云网络由物理网络和虚拟网络共同组成，两者都会影响网络性能。过去的研究主要集中于解决物理网络探测，而在虚拟网络探测领域的相应研究则较少。本文将为大家分享一种专为大规模多租户虚拟网络设计的主动探测系统Zoonet，从技术层面解读Zoonet系统的设计背景、面临挑战、技术架构，以及大规模部署的经验分享。
OOM是实例使用内存超过实例规格内存上限导致进程被kill，实例存在秒级的不可用。MySQL的内存管理比较复杂，内存监控需要开启performance schema查询(默认关闭)，会带来额外的内存消耗和性能损失，在不开启performance schema情况下排查内存使用情况又比较困难。本文将基于TDSQL-C（基于MySQL5.7）总结一下在线上经常出现的一些OOM的场景、排查手段及相应的优化方案。
将某个通用解决方案包装成成熟的工具包，是每一个技术建设工作者必须思考且必须解决的问题。本文从业内流行的既有工具包入手，解析实现思路，沉淀一般方法。为技术建设的初学者提供一些实践思路的参考。尤其是文中提倡的“去中心化”的协作模式，和“关键链路+开发接口”的开发模式，具有一定的实际落地意义。当然本文在行文中，不可避免存在一定主观偏见性，读者可酌情阅读。
本文主要介绍超大数据规模场景下分布式消息中间件在vivo的应用实践。 在线业务侧主要从RocketMQ集群部署架构、平台系统架构、日常运维操作平台、监控告警一体化实践以及vivo如何通过建设AMQP消息网关的方式完成所有在线业务服务从RabbitMQ到RocketMQ的业务无感迁移，实现了在线业务消息中间件组件的统一。 大数据侧主要从资源隔离、流量均衡、智能动态限流、集群治理四个维度介绍Kafka在vivo的最佳实践以及Kafka核心技术架构在超大数据规模场景下的缺陷以及未来对Pulsar组件的长线规划和建设。
2022 年，架构领域发生了哪些值得关注的事情？一位架构师必备哪些技能？2023年哪些架构趋势需要掌握？Nacos 和 MSE 创始人、阿里云高级技术专家彦林做客 InfoQ 直播间，为我们带来 2023 年的架构师发展指南。
之前看过杨振宁的一个采访，说他最大的成就，不是获得了诺贝尔奖的研究，而是之前的一个普通理论的研究：他坚信事物是遵循一定规律的，不是大家认为的不可捉摸，花了7年时间，陆陆续续，终于找到了一个很好的解释，并且幸运的是，这个研究结果可以覆盖非常多的场景。 当我看到这个采访的时候，内心触动到的一个点是：尝试寻求表象背后的规律或者通用解释，是能够帮助更多的人、产生更大的影响的，这也应该是我们应该努力并坚持的方向。
