话题公司 › 信也

公司:信也

信也测试能效工具实践

本文讲述了信也测试能效方面11个平台及工具实践,在测试相关不同的维度阐述了相关工具解决的问题及实现思路。

消费场景审批流的技术实践

随着消费场景线下信贷业务的快速发展及审批流诉求的日益增长,目前基于企业微信的审批流已经无法满足业务期望,需要自主搭建一套适应消费场景线下信贷业务的审批流。

NPS优化用户体验落地实践

本文讲述了NPS诞生的业务背景、系统框架和主要功能,增加了解用户的途径。快捷、简单的创建和投放问卷让用户反馈触手可及,可视化报表指引我们更好满足用户的需求。

资金安全守护利器"魔方卫士"揭秘

本文通过讲述魔方卫士诞生的业务背景,来展开什么是异常放款,异常放款常见的原因都有哪些,通过魔方卫士的系统架构及整体的实现方案,详细介绍魔方卫士是如何来避免三方机构的异常放款。

信也service mesh落地实践分享

信也科技基础架构部为解决服务调用不统一、异构语言和异构框架服务治理等问题,采用istio落地Service Mesh,进行了云原生的落地。本文将分享我们在大规模落地istio过程中遇到的两个挑战。

《sentinel在信也消息中台的应用》

消息中台在处理海量消息发送的时候,多个通道服务可自动切换和探活恢复,我们借助了sentinel的熔断、限流、资源授权以及服务监控方面的能力,实现了一套sentinel在消息中台中的应用。

PRL加密方案在广告投放中的应用

广告生态中,数据安全合规越来越重要,在保证用户安全隐私基础上,再开展广告业务是业内的共识。现阶段在广告投放流程中的RTA(Real-Time API)环节,请求参数中的设备号是以MD5的形式进行交互。MD5又被称为单向散列函数,虽然具有不可逆性(根据 MD5 值计算不出原始数据)及唯一性(不同原始数据会有不同的 MD5 值,碰撞率极低)特点,但还是存在一定被破解的风险,比如暴力穷举、彩虹表法、差分攻击,这就给个人隐私保护带来一定的挑战。

为了进一步保障个人信息安全,字节为广告主提供了PRL加密方案。PRL概念早在2004年就曾出现于数据挖掘的权威论文中,该论文至今已获得230多次引用,足以证明业界对PRL效果的认可,并且优势突出:开源、安全、可扩展,此方案可以保证媒体和广告主双方的信息安全,套用一句我们产品大大的话:采用PRL加密后,你只认识你认识的人。

客服平台揭秘

客服系统是一个企业与客户沟通的桥梁,好的客服系统能帮助公司扩宽市场,维护企业形象,提高客户忠实度,订单转化率。

生产压测揭秘

随着业务规模的发展,许多场景通过测试环境进行性能测试已经不能满足需求,于是生产压测成为了新的选择,本文会对生产压测主要流程进行揭秘,希望会为大家在系统性能评估上有所启发与帮助

APP「一包到底」方案应用实践

基于前端构建产物一包到底贯穿到测试,预发,生产的方案,我们针对借款APP频繁构建的场景做了评估与分析,通过一定的技术手段实现了APP端的「一包到底」方案。

istio进阶:一次边车内存突增问题的排查与解决

近几年 Service Mesh 技术越来越火热,已经逐渐成为了微服务治理领域的事实标准。信也科技为了解决异构语言和异构框架的服务治理问题,统一公司内的微服务治理体系,已采用 istio 落地 Service Mesh 。istio 作为一种新技术,我们在落地的过程中也遇到了诸多挑战,本次将分享一次边车内存突增问题的排查与解决过程。

备份恢复系统之MySQL篇

备份作为容灾的基础,其重要性不言而喻。本文将以我们熟悉的MySQL数据库着手,构建企业级备份恢复系统。 希望能带给大家一些借鉴意义,欢迎大家围观。

信也设计素材库—XUED

信也科技的设计师每月会交付近千张图片,为了将这些设计资产沉淀下来,方便PM使用已有活动图、Banner、弹窗等素材或从中寻找灵感,也方便研发使用已有ICON、Logo,方便设计师管理历史设计素材,大前端团队研发了信也设计素材库。目前每月会上传素材几百张,预计节省设计成本25%,提高研发组件/图标/模块的通用率15%。本文将对设计素材库研发的技术要点做些总结和分享,详情如下。

App启动优化最佳实践

启动流程是用户对我们App的第一体验,打开应用后才能去使用其提供的强大功能,但是就算我们应用的内部界面设计的再精美,功能再强大,如果启动速度过慢,用户第一印象就会很差。笔者在这里总结了一些优化经验,希望可以抛砖引玉。

企微群机器人在日常工作中的实践

随着日常工作节奏的不断加快,各项流程规范的制定,我们经常会遇到信息传递不及时、不到位,流程执行易遗忘的尴尬场面。本文将介绍利用企微群机器人,来辅助我们完成日常工作中的信息同步、消息提醒等,从而降低沟通成本,提升工作效率。

数据水平拆分利器-DataSS

随着业务的增长,数据库会成为我们业务系统的瓶颈,这时我们就会想到分库分表这种手段,以此降低单数据库的负担。

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-22 20:07
浙ICP备14020137号-1 $访客地图$