聊到插件化架构，我们更多想到的是「构建阶段」的插件机制（不限于webpack、babel），而umi提供的「运行时阶段」的插件机制就比较少见了。

在前端的业务中，经常会出现需要计时的场景。比如页面中需要统计停留时长，以达成一些活动任务的要求；又比如页面需要进行倒计时，用来预热一些特定时刻才能开启的活动；再比如页面中需要展示一些动画，用于使页面看起来更美观。这样的场景数不胜数，覆盖了可以说是几乎所有的行业，其中是以电商、游戏中最为常见。

度量系统前端重构：如何将前端开发成本减少到最小，并且做到能够快速实现，快速复制。

在公司使用RocketMQ的时候发现事务消息不是社区版的,而是自研版本。

这就引发了强烈的好奇,为什么要自己研发一套呢? 和社区版的又有什么不同呢?

基于前面umi插件机制的原理可以了解到，umi是一个插件化的企业级前端框架，它配备了完善的插件体系，这也使得umi具有很好的可扩展性。umi的全部功能都是由插件完成的，构建功能同样是以插件的形式完成的。下面一起来了解下umi的构建原理。

实战案例讲解设计的数据分析、思路和模型。

客服IM系统是转转自研的在线客服系统，是用户和转转客服沟通的重要工具，主要包括机器人客服、人工客服、会话分配、技能组管理等功能。在这套系统中，我们使用了很多开源框架和中间件，今天讲一下WebSocket在客服IM系统中的应用。

插件化架构在如今的许多前端主流框架中都能看到它的身影。今天我们以 umi 框架为主，来看看插件化架构的实现思路。

近几年，短视频是最热门的广告传播媒介，各大广告主为了用户增长和留存，都在极力深耕短视频广告(分为效果广告和品牌广告)。当流量时代过渡到“留量”时代，提升内容共生力成为短视频吸引注意力和增强传播效果的有力手段。

之前的文章《估价器测试方案在测试过程的落地提效》中，已经对估价器系统进行了简单的介绍，分析了在测试估价器需求时遇到的问题，也逐一介绍了前期的调研成果、第一版工具的实现思路和落地效果。

但是，第一期工具仍存在待解决和优化问题。针对这些问题，本期文章将介绍一下具体是怎么解决的，以及进一步的优化。

umi是一个插件化的企业级前端应用框架，在开发中后台项目中应用颇广，确实带来了许多便利。由于这个契机，便有了我们接下来的“umi3源码解析”系列。

从现有方案可以看出，现在PHP调用Java接口步骤是很繁琐的，开发效率偏低。而且还有两个问题：泛型无法解析、不便本地调试。所以要进行重构来解决这些问题。

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

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

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

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

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

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