架构师训练营第四周作业

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



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

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

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）。