设想，打开一个 APP，我们会看到什么？答案是：内容信息。

例如当我们打开转转 APP 时，目光所及的首页、商品列表页、商品详情页...以上我们简称为信息聚合场景。在电商 APP 中，此类信息聚合场景往往需要聚合多种数据源才能完成最终渲染，这也意味着在微服务架构中，服务端响应一次用户请求需要聚合 N 个内部 RPC 请求响应的数据才能完成最终响应。

而为了尽快响应用户请求，往往需要通过某些方式异步发起多个 RPC 请求来获取结果数据，我们把这样的过程称为并发场景。

单机锁主要是为了同步同一进程中各个线程之间的操作。大多数互联网系统都是分布式部署的，当某个资源在多系统之间具有共享性的时候，为了保证大家访问这个资源数据是一致的，那么就必须要求在同一时刻只能被一个客户端处理，不能并发的执行，否者就会出现同一时刻有人写有人读，大家访问到的数据就不一致了。分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。

本文介绍58信安基于Flink实现低代码实时数仓构建系统，我们将数仓构建这一过程进行抽象，通过工程化的思想去解决，将固有领域问题交给系统，让开发人员关注数据本身，解放人力缩短数仓构建周期。

项目管理中，人员、关键时间节点、耗时等数据是业务团队比较关心的，这些数据需要每位同学手动录入，有一定时间成本。今天给大家介绍下2种降低数据维护成本的技术提效实践～

通过介绍神奇管家的设计与实现，为大家进一步认识和理解零信任提供了真实可靠的参考案例。

Sequelize 是一个基于 promise 的 Node.js ORM,它具有强大的事务支持, 关联关系, 预读和延迟加载,读取复制等功能。本文希望通过下面的知识讲解及一些实战经验分享，给予即将入门或正在学习的同学一些帮助。

商品系统作为电商中的核心系统之一，其重要性不言而喻。互联网业务上的高性能、高并发、高可用在商品系统上体现的淋漓尽致。除了引入分布式缓存以及分库分表的优化之外，本文从数据的角度阐述了商品系统的优化，以提高商品系统的并发能力和性能。

竞品分析时不知道用什么方法？作者总结了8种常用方法和其适用场景。

实现多项目的分模块打包，且项目之间共享组件和依赖，运行、打包时互不干扰。

转转作为国内头部的二手闲置交易平台，从2015年成立至今，业务模式由C2C拓展至B2C、C2B、B2B、C2B2C等多模式并存的新格局，品类覆盖手机3C、图书、游戏、奢侈品等三十余大类。

转转目前采用的是中台业务架构模式，中台（全文默认指交易中台）负责提供通用，稳定的交易能力，灵活快速响应前台业务需求；业务负责前台探索持续创新，为用户提供有价值的服务。

介绍在Vue中3种页面级别前端灰度新功能的方案。

最近也许是“幸存者偏差”的原因，频繁看到不同技术公众号发布的关于《分库分表》的测试方案分享，21 年下半年中台订单侧也做了一次分库分表的技术改造，由于 21 年年底项目忙，一直没有系统性的整理一下，趁着最近有点空闲，来一次沉浸式总结；按照最简单的叙述，分为“事前”、“事中”、“事后”做一次回顾。

转转推送系统（后面简称系统）在早期设计中主要考虑了三个核心指标：

• 吞吐量：指系统在单位时间内能够发送多少消息的能力。
• 扩展性：指系统在快速支持更多APP主体、发送策略、发送通道、通道策略等能力上的难易程度。
• 性能：指系统API的接口耗时。

为了同时满足三个核心指标，我们在系统中大量采用了异步、并发、批量等设计。这些设计虽然很好满足了系统设计指标，但是同时也给系统带来了较高的复杂度，再加之一些环境因素（如测试环境的不稳定），导致业务方（指系统使用方）在接入测试中经常需要系统人员协助定位问题，这种状况既降低了业务方的开发效率又增加了系统的维护成本。

为了解决业务方的接入测试问题，在之后的系统演进中我们又增加了第四个指标：易测性，希望通过这个指标来提高系统的可测试性和降低系统测试成本。本文将重点讲述我们在系统易测性指标上的一些设计经验供大家参考。

瀑布流是大家日常开发过程中经常遇到的一个场景，我们公司内部的组件库中也提供了一些解决方案。但这些方案适用场景都很单一，且每个实现方案都或多或少存在一些问题，基于此，我们设计与开发了一个兼容多场景的瀑布流组件。

公司现在访问测试环境方式，使用线上域名，本地配置host，通过host控制访问不同的环境。这种使用方式，存在诸多问题，比如：

• 忘修改host，或浏览器存在socket缓存，host没生效。会访问更改线上数据，风险大。
• 需要频繁配置修改host，产品，运营，测试在测试环境作业中效率较低。
• 与第三方联调时，每次更换测试环境，都需要运维同学更改nginx配置。

如何将游戏类运营活动赋予新的玩法，打破老套运营方式给予用户新鲜感？