标签墙

架构设计

敏感数据处理

背景 大多数应用或多或少都会涉及到敏感数据处理,比如用户的手机号、身份证号,甚至银行卡账号。作为应用的开发者,如何 安全地 维护这些敏感数据呢? 这里讨论的安全不是指服务器如何保护,而是在数据库层面做敏感数据的分离: * 业务库中不保存敏感数据,只保存混淆过的数据,比如电话字段保存的是 133****9961,在数据层面就进行脱敏 * 敏感数据统一保存在另一个库中,有应用调用一个服务来建立原值和混淆值的映射关系 * 业务库中因为保存的是脱敏过的数据,通过只读复制镜像可以很方便地提供给其他服务使用,比如 OLAP * 除了技术开发上方便,运维上也方便了很多,降低了敏感数据被暴露到外部的可能性 ### 技术设计 提供服务接口给应用存取敏感数据,本质上是一个 KV 存取服务。 1462956107181 一些细节: * 表 protyle 的 domain 字段用于标识该记录的作用域,在一个作用域上相同的值要保证唯一 * 表 protyle 的 ha....

More...

基于数据库复制的技术架构讨论

背景 这里的数据库复制指的是将 业务数据库实例上的库通过同步机制(比如 MySQL binlog)实时(比如最大延迟为 3s)复制到其他数据库实例上,这些实例库只做查询,不做数据写入。 这套架构设计的主要优势: * 各业务应用能够方便地在自己的 DB 实例上进行业务查询,比如通过 join 主业务库 * 在不明确业务边界、没有梳理好业务对应技术模块时可以最小成本进行变更或扩展 * 实现读写分离,提升性能 ### 一些问题 实际在实施过程中主要遇到两个问题: 1. 不可能实时完成数据同步,将造成业务上面的不一致,比如调用主库服务更新数据后,在业务库上不能实时查询到已更新的数据 2. 很难保证高可用(在使用阿里 DTS 时出现过多次问题,自己做主从可能会好一些) 为了满足业务发展,复制库的数量会逐步增多(比如新开一个产品可能就需要多复制一套库),以上两个问题可能会导致严重的故障, [CAP] 不能兼得。 ### 服务化 基于数据库复制架构的核心理念是将数据源暴露给应用,开发者直接针对数据源进行开发,是一种非常直接的方式。 但随着业务的逐渐清晰,一些业务逻辑是可以抽....

More...

呼叫中心架构设计

从呼叫模式上看,目前业界大多数采用的是“回拨”模式,即由呼叫中心发起两路呼叫,然后将两路进行连通。

More...