在日常进行业务需求的开发时，经常会遇到需要绘制图表的场景，其中我们使用频率最高的图表库是 ECharts[1]。ECharts 作为市面上最成熟的图表库之一，主要面向 Web 端使用，官方对小程序端也提供了解决方案，而在 RN 的开发场景中却没有比较好的实现方法，面对这种情况以前我们的解决方案有： 1.放弃 ECharts，使用针对RN原生开发的图表库，如 react-native-charts-wrapper、victory-native 等 2.通过 Webview 来使用 web 端的 ECahrts，如 react-native-echarts-pro[2]、native-echarts 等 方案1，RN 现有图表库的样式与交互与 ECahrts 相比有较大差距，图表的丰富性也不足，尤其是有多端需求的场景下，需要为 RN 单独进行UI交互设计，设计与实现成本高。 方案2，通过 Webview 的方式，当页面上有多个图表或者图表元素过多时，会遇到性能方面的瓶颈，比如安卓端的大数据量面积图、单轴散点图等会有白屏现象，而且正常渲染过程中也会有比较明显的卡顿、掉帧的情况。 所以，
2022年8月，58同城TEG-AI Lab语音技术团队完成了WeNet端到端语音识别的大规模落地，替换了此前基于Kaldi的系统，并针对业务需求对识别效果和推理速度展开优化，取得了优异的效果，当前录音文件识别引擎处理语音时长达1000万小时/年，流式语音识别引擎支持语音对话量超过5000万次/年，详细工作可以参考《58同城：WeNet端到端语音识别大规模落地方案[1]》。 在优化工作中，我们复现了Efficient Conformer[2]模型，在实际场景数据上，与Kaldi最优模型相比，识别效果上CER绝对降低3%，解码性能提升61%。与Conformer相比，识别效果上CER从10.01%降低至9.30%，解码性能提升10%，结合int8量化，解码性能可提升60%。我们也在AISHELL-1公开数据集上进行了评测，CER为4.56%（No LM）。模型代码已开源至WeNet[3]。 本文主要介绍我们对Efficient Conformer的复现工作，包含：模型介绍、模型实现、流式推理支持以及相关实验结果。
深度学习推理平台在架构上属于WPAI的子平台，旨在将算法人员使用深度学习框架训练出来的模型部署到生产环境，提供高性能、高可用的在线推理服务。总体架构如下图所示，底层依托于Kubernetes和Docker，实现了对GPU/CPU等资源的统一调度和管理，网关侧搭配Istio实现了推理服务发现和流量治理功能；算法层集成了TensorFlow、PyTorch和PaddlePaddle等优秀的深度学习框架，同时也支持用户自定义服务；应用层从模型管理、部署、推理加速和服务高可用保障等方向都提供了一系列功能。支撑了58同城在图像、NLP、语音、搜索、推荐、广告、风控领域内的各类AI应用，目前已上线模型数1000+，峰值节点数4000+，日均流量30亿。本文主要介绍深度学习推理平台推理架构的演进过程，以及新架构下在流量治理建设和可观测性建设方面的设计细节。
北斗前端监控系统是 58 内部的一个线上质量监控排查解决方案，用于帮助用户大幅提升定位问题和优化项目的效率。系统共分为数据收集（SDK）、数据处理（Java）、数据存储（Druid、……）、数据分析（Node.js）、数据展示(React) 5 层模型。Node.js 作为系统中的数据分析层，提供各种数据分析和应用的方式。 在一期之后，系统的基础功能已经完备。平台可以收集 5 种类型、30 多种指标的数据，已经具备了很强的数据收集能力，数据应用的方式却很匮乏。 所以在二期开发时，我们计划在 Node 端加入多种数据应用的方式。实时告警，就是其中之一。 简单分析需求，服务端需要以一定的频次（例如每分钟）监测不同项目中用户配置关注的指标数值。当数值出现异常时，给用户发送邮件、短信等告警信息用于警示。 而其中的重点，就是如何在 Node.js 中设计并实现定时任务系统？
WLock为⽤户提供了秘钥作为集群分配、锁操作、隔离、权限控制的租户单位。为了保证数据的强一致性与服务吞吐能力，每个节点采用多Paxos分组并行向所有副本同步锁状态数据。业务接入前，首先会创建秘钥，并为秘钥分配可用的服务集群（通常包含5个节点）。在生产环境，如果为每个接入的业务独立部署集群，随着接入量的增多，存在管理不便以及资源浪费的问题。所以WLock采用的是多租户共用一个集群的部署方式，但这种方式必须要解决多个秘钥的租户因调用量参差不同而相互影响的问题。
1.服务架构的发展历程 2.ServiceMesh是如何工作的？有哪些业界落地案例 3.Web治理插件在58服务治理中的如何运作的 4.对58的服务Mesh化的期待
移动互联网进入存量时代，随着人口红利减退，充分盘活、经营现有流量便成为了各行各业全新的机遇与挑战。各大公司都在内卷发力，对 App 包大小、启动速度、性能做持续优化。 App 包体积和用户转换率成负相关，包体积越小、用户下载时长越短，用户转换率越高。而随着国内用户的增量见顶，越来越多的应用选择出海，开发对应的海外版，Google Play 应用市场目前强制要求超过 100MB 的应用只能使用 AAB 扩展文件方式上传，Google Play 会为我们的应用托管 AAB 扩展文件，进行自定义分发和动态交付。
App 启动是指用户从 App 之外的场景进入到当前 App 中的过程，按照 App 的进程是否存在以及主 Activity 的生命周期状态，App 启动主要包括冷启动、温启动和热启动三种。启动优化主要是针对冷启动过程，目标是减少用户从桌面点击 icon 启动 App 到展示出 App 主页的首帧画面或者从其他应用调起 App 首次启动到展示出业务的落地页首帧过程的耗时。 关于 App 启动优化的原理和检测工具的介绍，网上已经有很多分享的资料，有的分享技术深入内容全面但理论性太强不便于在项目中实践，有的只讲了某些方面的优化细节而不成体系。每个 App 都有自己特有的业务逻辑和代码实现，有必要针对自身 App 的特点，系统地把细碎的优化方法组织起来，形成一套适合本 App 维护的完整的优化方案体系。本文将主要介绍我们团队在 58同城 App 中进行启动优化的实践。
为了更好的吸引流量并提升产品指标，针对各种节日及租房流量高峰期，房产每年共有几十场运营活动，包含租房、公寓、商业地产等不同业务，这些运营活动项目花费大量的人力物力资源投入。 尤其房产部门每年有两次比较大的运营活动，春节后复工时期及七月毕业生走向社会时期，是租房的两大高峰期，因此每年的这两个时期都需要组织大型运营活动。那么运营活动有哪些特点呢？
