描述问题 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：
职责分离，提升扩展性
架构升级的时候，可以分别进行优化