本文主要介绍得物实时调试的全套解决方案，实现对测试包还原出包环境和无需编译就可以进行断点调试的功能。整体按实时调试方案的可行性分析，方向调研，优化方案设计，推进优化落地，最后在团队推广的流程。本文主要讲4个主要内容，包括:Attach to Process介绍，环境还原，实时调试探索，组件化工程的实时调试。

项目文档是对于项目一个快速了解的一个最好方式，能从中获取到其是所服务的业务，参与开发所具备的知识体系，开发前所需做哪些准备，遇到问题所需询问的时的人员，不仅能帮助新手快速上手，同时也有助于多个项目并行时，相互之间进行切换起到温故的效果。

zookeeper是一个比较成熟的，经过市场验证的分布式协调框架，可以协助我们快速的解决分布式系统中遇到的一些难题。另从上面的介绍中发现，zookeeper的核心是zab，etcd的核心是raft，那可以思考下，还有哪些一致性算法？

异地多活的概念以及为什么要做异地多活这里就不进行概述了。概念性的很多，像什么同城双活、两地三中心、三地五中心等等概念。如果有对这些容灾架构模式感兴趣的可以阅读下这篇文章进行了解：《浅谈业务级灾备的架构模式》。

在我们开发测试过程中，登录验证码几乎随处可见。特别是春节抢票，有没有被12306的验证码搞的崩溃呢？ 教大家一个办法：利用机器学习来自动识别验证码！

大家在逛街，看视频，刷朋友圈时，是否会看到自己一见钟情的鞋子，衣服等商品，却因为不清楚商品的具体系列，款式而苦恼？遇到这种情况大家一般是动口询问，还是到品牌官网或者购物平台海量搜索呢？相信大家都有自己的获取渠道，这里将会为大家介绍一种更直接的拍照搜索方式。

Qiankun是社区的一种微前端框架；MF是模块联邦的意思，在Webpack 5中流行起来的，也属于一种微前端方案。

登录模块对于一个App来说是十分重要的，其中稳定性和用户流畅体验更是重中之重，直接关乎到App用户的增长和留存。接手得物登录模块以后，我陆续发现了一些其中存在的问题，会导致迭代效率变低，稳定性也不能得到很好的保障。所以此次我将针对以上的问题，对登录模块进行升级改造。

MIND多兴趣召回在实践过程中，经过离线和实时两个阶段去执行最终落地，中间的步骤因此记录下来，希望你在阅读到此文能够有所收获。

在我们经历过多次大额资损类故障中和影响业务可用性严重性故障后，我们回顾总结怎么从应急保障中做到快速响应，事前预警后。由被动变主动，向全员承诺发起NOC-SLA保障专项，痛定思痛下定决心将告警发现、处理、止血。

​高质量的3D模型更能激发用户消费的意识，因此提高3D模型的呈现效果就是我们的重点攻坚方向，Filament creator材质编辑工具，可以帮助我们使用不同的渲染引擎材质来呈现球鞋效果，让用户可以通过模型获取更真实的效果。

公司近两年快速发展，社区线C端代码分散在不同仓库中，每个仓库中采用不同的前端框架和选型，且均含有几条业务线的代码，团队整体采用敏捷模式快速迭代，导致开发管理成本较高，升级改造麻烦。比如，所关联的三个仓库中的代码均引了一个内部基础组件库，该组件有非必现bug，导致三个仓库的不同页面均出现了不同表现的异常，由具体负责的不同测试分别报到前端开发，分别沟通、排查、解决并走独立的发布上线流程，耗时耗力。当同一仓库中活跃着不同业务线的开发，一个公共的地方需要修改，开发没有沟通清楚导致冲突线上bug。

此外，公司C端体验分析的统计和报表是应用粒度的，先前代码耦合了其他业务的内容，导致我所在业务线的统计数据不置信。

近期团队对C端项目进行重构，将不同仓库中的代码汇总到一个仓库中管理。以期减少管理成本及方便后续对组内项目做优化和升级改造。

市场上的Mock方案相对较多，得物前端Mooncake平台作为UI测的联调提效工具，通过线上配置平台、代理层，代理注入三层的实现，实现了数据可视化配置和数据转发，提升了前端的联调效率。

​一般来说 IM 产品的用户量和活跃度通常都很大，在一些特殊的时间点经常容易造成流量的波峰，因此技术上需要能够应对突发的量级，同时IM一般主要包含这4个特点：实时性、可靠性、一致性、安全性，对于IM的优化还有很长的路要走。

埋点验证平台在每个阶段遇到的痛点其实都是“埋点数据如何固定”这个问题的一个缩影。业务的快速迭代使得埋点验证过程中积累的mock记录和验证规则这些沉淀产物十分脆弱，即使我们通过多种手段实现了这些数据的手动或自动更新，它们最终也难免会彻底失效。

如果一定要要求分布式锁百分百可靠，那可以选用Zookeeper或者MySQL作为分布式锁，就能完美的解决锁安全的问题，但是选择了一致性那就要失去可用性，所以Zookeeper或者MySQL实现的分布式锁的性能远不如Redis实现的分布式锁。