插件的设计能带来许多好处： 1: 它可以极大地提升软件的可扩展性。很多工程工具都提供了插件能力给开发者，借助社区力量基于插件扩展各种原本不具备的能力，从而极大地提升了生命力； 2: 它可以让主体程序和插件代码解耦，保持主体程序的稳定。可以想象如果 webpack 不是通过插件来扩展能力，那当我们需要某个当前版本不具备的能力时，只能不断地升级 webpack，而这种升级则很容易引入不稳定因素。 3: 它可以帮助我们控制主体程序复杂度。借助插件，我们可以很好地把能力分而治之，化整为零，从而有效地控制系统整体的复杂度。 4: 它可以帮助我们控制程序体积，做到按需引用。由于插件是可以独立地动态加载，我们可以针对性地选择我们需要的插件能力。我们也可以设想，VsCode 如果是把各种能力都由自己完成，其软件大小会是怎样的规模（其实也不会是现在的形态了，比如针对各个编程领域提供一个应用包）。
前端界有两个“教派”，一个叫 Vue，一个叫 React。Vue 的成员看不起 React，React 成员鄙视 Vue，他们认为手中的“教义”就是真理，可以消灭世界一切苦难。 但正如没有绝对的真理，也没有绝对完美的系统框架，我们需要一双明辨是非的眼睛去解析所面对的难题，带我们找到正确的方法，解决所面对的困难。我们需要抱着怀疑的眼光去看待现代前端开发框架，它们真的能解决我们的问题吗？答案是肯定的，也是否定的。框架并不能独立的发挥作用，其中开发者是一个很大的变量，而开发者这个最大的变量才是最终影响问题是否能够被解决的重要因素。 本文从对现代前端框架的“崇拜”现象，引出了前端开发面临的过于强调工具本身，忽视了开发者怎么写好代码才是影响代码质量的本质问题，最后给出了一种我认为可解决业务型前端项目的代码架构方案（也可以说是一种开发思想），希望能给大家带来一些思路和帮助。
本文不对 raft 算法从头到尾细细讲解，而是以 raft 算法论文为起点，逐步解读 raft 算法的理论，帮助读者理解 raft 算法的正确性。然后，etcd 不仅是 raft 算法最为热门的工程实现，同时也是云原生 kubernetes 的核心存储，本文也对 etcd 的底层实现进行剖析，让读者在使用 etcd 组件的过程中能够做到心中有数。对 raft 算法足够熟悉的同学，也可以直接阅读 etcd 工程实现那块内容。
change buffer（在 MySQL 5.6 之前叫 insert buffer，简称 ibuf ）是 InnoDB 5.5 引入的一种优化策略，若二级索引页不在 buffer pool 中，则将针对二级索引页的操作暂时缓存起来，等到该页从磁盘读到 buffer pool 中时再批量的（batch）apply 这些操作，从而达到减少磁盘 I/O 的目的。具体一点就是： 事务 1 执行写操作（e.g update），但针对的二级索引页 P1 并不在 buffer pool 中 于是 client 1 将这个操作缓存到 change buffer 里，即添加一个 entry（ibuf insert） 事务 2 需要读操作，将 P1 读到 buffer pool 中 将 change buffer 里相关的缓存的操作全部合并（merge）至 P1（ibuf merge） 将 P1 返回给用户线程
11月3日，在2022云栖大会上，阿里达摩院联手 CCF 开源发展委员会共同推出了 AI 模型社区“魔搭”ModelScope，旨在降低 AI 的应用门槛。 AI 模型较为复杂，尤其是要应用于行业场景，往往需要重新训练，这使得 AI 只掌握在少数算法人员手中，难以走向大众化。而新推出的魔搭社区 ModelScope，践行模型即服务的新理念（Model as a Service），提供众多预训练基础模型，只需针对具体场景再稍作调优，就能快速投入使用。 达摩院率先向魔搭社区贡献 300 多个经过验证的优质 AI 模型，超过 1/3 为中文模型，全面开源开放，并且把模型变为直接可用的服务。社区首批开源模型包括视觉、语音、自然语言处理、多模态等 AI 主要方向，并向 AI for Science 等新领域积极探索，覆盖的主流任务超过 60 个。模型均经过专家筛选和效果验证，包括 150 多个 SOTA（业界领先）模型和 10 多个大模型，全面开源且开放使用。 本文，阿里达摩院开放视觉智能负责人谢宣松，深入解析了魔搭社区里首批开源的101个视觉 AI 模型。
随着业务的发展，用户量和业务复杂度逐渐增加，系统为了支撑更大的流量需要做很多优化，比如升级服务器配置提升性能。在软件方面，我们会采用微服务架构，对业务服务进行微服务化拆分，水平扩容等来提升系统性能，以及解决业务的复杂性问题。 在微服务架构下，一个业务服务会拆分多个微服务，各个服务之间相互通信完成整体的功能。另外，为了避免单点
2021年下半年以来，在新冠疫情和互联网政策的冲击之下，各大互联网公司都在进行降本增效。降本增效的一大核心手段就是优化计算资源成本，本文将以腾讯某内部 Kubernetes/TKE 业务为案例，详细阐述如何从 0到1（成本数据采集与分析、优化措施、行业现状与方案选型、方案设计与实现、落地与效果、总结）进行大规模、高可靠、高效率的成本优化的实践，并在这过程中实现了零故障突发，CPU 最高节省70%，Memory 节省50%的成果。本文所介绍的成本优化整体方案实现是腾讯云开源项目 Crane 的内部雏形版，我们在内部成功实践的基础上，将相关设计方案与最佳实践进一步输出给对外开源项目 Crane（https://github.com/gocrane/crane)，致力于为云原生广大用户提供云成本优化一站式解决方案。
要确保Kafka在使用过程中的稳定性，需要从kafka在业务中的使用周期进行依次保障。主要可以分为：事先预防（通过规范的使用、开发，预防问题产生）、运行时监控（保障集群稳定，出问题能及时发现）、故障时解决（有完整的应急预案）这三阶段。
淘宝主搜索是一个典型的多阶段检索系统，主要分为召回、粗排、精排等阶段。召回阶段，由文本召回、个性化等多路召回构成，输出商品量级约10^5；粗排阶段，需要从三路召回集合中分别进行筛选，筛选出10^3量级提供给精排；后续经过精排等阶段再进行筛选输出约top10曝光给用户。（注：下文中10、10^3、10^5等均代表数量级，数值只作为示意，只有其相对大小具备参照意义）
