项目解决方案记录

描述问题 STAR法则：

situation

task

action

result

 

1、对话平台

a、资源模版子系统

situation

大量的规则代码，耦合，低效

task

业务层面进行抽象，规则抽象成模版，降低系统耦合

1.流程“嵌入”在多个应用程序代码中，流程无法复用，重复开发

2.围绕输入/输出、SLA等存在紧密耦合和假设，使得难以使用业务需求的变化

服务开放平台： 把现有的服务接口通过统一的开放平台暴露给合作方。

API GateWay： 把现有的service服务，通过公共的http 网关暴露http接口，不需要每一个团队再自己搭建web 服务。

泛化需求的标准化对接：集团内部使用的通用场景，服务之间的调用都可以使用，去除强制依赖服务方的api jar包。

action

配置管理平台

配置api

result

提升效率 pm rd

 

b、服务泛化依赖

situation

平台有很多接口和下游业务接口紧耦合的状态，需要了解业务细节、关注业务接口升级、强依赖api

task

适配器在平台？ 在业务方？ 都不太友好

接触耦合，加一层服务泛化能力，平台不再关注业务细节

参考 netflix conductor

action

业务描述语言DSL

泛化调用

result

关注自身 ，接触耦合

 

c、画像子系统

situation

查询画像接口

task

响应慢

action

同步转异步，串行转并行，循环转批量

result

接口响应变快

架构合理性高

 

2、鉴权

situation

语言平台内部的鉴权

task

成本第 高效率

action

auth2 客户端方案

读：降级

写：限流、缓存分桶

可靠性：local file

result

满足

 

3、理财

situation

理财超卖

task

额度控制

action

精准 分布式锁  高并发情况下影响性能 悲观锁

非精准  trick方案

result

非精准

 

4、低价提醒

situation

给用户推送低价

task

db瓶颈

action

定时 变成 mq驱动

result

瓶颈 和 实时性

 

 

5、缓存大key 优化

https://juejin.im/post/5c19be51f265da615c593351

https://tech.meituan.com/2017/03/17/cache-about.html

https://www.cnblogs.com/rjzheng/p/10874537.html

https://www.jianshu.com/p/176c8f8b8eb1

hot key

big key

https://gitee.com/itopener/springboot

https://my.oschina.net/dengfuwei/blog/1616221

总结：

Spring cache：

aop： 解耦业务逻辑和缓存实现

可扩展：  cache 、 cacheManager

自定义逻辑：

接入cat监控、熔断降级策略、多级缓存

解决： 击穿 穿透 雪崩

支持设置有效期、过期时间

https://www.jianshu.com/p/275cb42080d9

 

缓存读：

cache only

read throuth

缓存更新：

主动mq

定时任务

被动发起

 

 

6、 信贷B端业务 CQRS改造

S：
信贷的CRM系统，维护了信贷业务的核心数据（还款方式、利率等）
老的架构单一，所有功能耦合在一个服务里
BD： 写数据（增加、修改、删除）
各个不同业务方： 读取数据，线上接口方式
问题：
可用性、扩展性、效率低

T：
系统重构
指导的方法论是： 读写拆分，CQRS

A：
CRM单体系统 -> CRM Command System + CRM Query System

Command System：
数据录入
事件通知 databus组件

Query System：
构建数据查询视图 db + redis + es

数据保障机制：
数据同步依赖中间件，需要提供兜底的方案
延迟检测job + 补偿Job（只覆盖了核心部分）

R：
职责分离，提升扩展性
架构升级的时候，可以分别进行优化