架构师训练营第四周作业

用户头像
张锐
关注
发布于: 2020 年 06 月 30 日

一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述。



以在唯品会的工作经验,金融团队的风控数据平台变迁为例,说明架构变迁如下:

风控系统依赖很多外部数据作为风控决策的输入,我们特此开发出了网关对接外部数据源。数据服务最开始的版本耦合在风控业务系统中,风控业务直接和网关交互获取外部数据。这样方案主要的目的在于:

1.方案简单,快速上线;

2.独立出网关,系统和外部隔离,提升安全性

但是缺点也显而易见:

1.访问网关代码重复开发

2.多个入库入口,调用外部数据源落库记录格式不规范

3.关系型数据库难支持可变维度的缓存查询

针对以上3点,引入了数据组件的概念,避免数据重复的访问代码,以及支持多维度查询:

通过jar包的方式规范网关调用,同时在jar包中规范日志打印以及落表格式,保障同一个数据源存储结构相同。并且通过mysql binlog方式接入到elastic search中,支持多维度查询作为数据缓存使用。方案优点:

1.统一数据调用

2.统一数据存储

3.引入es来解决多维度查询

缺点:

1.接入新数据源需要升级jar包,需要推动依赖方升级(虽然依赖方只有我们自己,大概2~3个应用集成该jar,升级发布依然很麻烦)

2.没有办法做到细粒度的数据治理(比如调用量统计、业务级别的数据降级等)

于是想法是把数据单独抽取出来做微服务,服务级别提供组件数据,数据服务升级不会再影响上游系统。另外也能在服务级别统计调用量、数据质量,做数据质量监控和告警:

经过三个大版本的迭代,唯品金融风控数据平台已经初具模样。其中的发展过程中,我们使用es来支持非结构化数据的查询;我们用微服务的方式替代jar包,为后续的数据流控、降级等高可用方案上提供了基础和土壤。

关于流量控制的技术选型:前期我们使用了Hystrix的线程池模式来进行业务级别的数据流量隔离和熔断。上线后发现系统的瓶颈在于线程池的大小设置和队列长度设置。设置不合理直接导致oom或请求排队等待时间过长。由于受限于jvm内存大小,外部流量控制问题最后转为了在可用jvm内存下的hystrix最佳实践(当出线上问题时,都还没达到外部数据源本身限制的QPS)。所以最终摒弃了该方案,后续调研了阿里巴巴开源限流框架sentinel,支持集群流控(hystrix只有单机流控)和信号量级别隔离(基于并发量,轻量级不占系统资源,虽然hystrix也支持信号量隔离,但是hystrix的信号量隔离没办法处理timeout等外部超时事件,所以使用场景一般在jvm内部逻辑单元运算次数隔离,而sentinel也能处理timeout事件然后fast fail)。

用户头像

张锐

关注

还未添加个人签名 2018.08.07 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第四周作业