阿里云生态金融科技行业标杆 ——

作者 | 胡阳（视野数科）

2021 年，云原生的商业价值正在被加速释放。

一个公认的事实是，Serverless 是当下云原生方向内绝对的亮点。可以看作，它的出现，让企业用户真正地免除运维负担，更专注于业务本身。换言之，企业可以基于按需付费的模式降本增效，实现技术的商业价值最大化。

在这场技术与商业互补的浪潮中，视野数科是一个鲜明的案例。基于阿里云 Serverless 应用引擎（SAE），视野数科已然全面升级为云原生架构，为金融科技全行业应用云原生提供了最佳业务实践范本。

视野数科成立于 2014 年，是国内首个专注服务于一级市场、公司信贷、产业规划招商、面向多层次资本市场的大数据金融信息服务商。和其他 to C 的运作逻辑不同的是，视野数科将数据产品与金融行业使用场景做了深层绑定，推出了一系列业务功能模块。

伴随业务不断升级，视野数科从为金融机构提供数据信息服务出发，近年来其客户已逐步扩展服务政府、产业园区、大型国企集团等，同时覆盖数据范围也从金融相关数据逐步延伸到产业产品数据、企业经营数据、宏观经济数据、政务数据、政策舆情数据、地理信息数据等，围绕客户数字化转型，为客户提供数据销售、数据整合、数据加工处理、数据中台、系统开发和大数据模型分析咨询服务的整体数据服务解决方案，助力中国产业数字化转型。

在金融数据提供商的角色定位之外，如今的视野数科正在迈入多产品线和多类型服务客群的新发展阶段，成为一个真正的金融产业数据服务方案解决商。

业务痛点当先，优选阿里云 Serverless 方案

在金融行业系统中，大数据的应用场景一直是敏感复杂的代名词。

以数据调用为例，大多数金融机构系统与外网隔离，需要数据服务公司搭建更适合这样场景下的数据服务体系或可以满足客户需求的嵌入式数据功能。对于客户来说，视野数科不仅提供常规的数据文件/数据同步/API 的数据服务方式还可以将数据以 SDK + 嵌入式的方式无缝嵌入到客户内部系统之中。

一方面，这简化了客户的开发成本，另一方面，则大大缩减了客户对大量的外部采购数据的实际使用投入的开发时间。

此外，和众多的金融科技公司一样，视野数科是自建 IDC + 公有云混合部署的模式。而在上云的探索中，视野数科一直是行业的先行者。早在 14 年，视野数科基于阿里云 ECS 服务器，使用开源自建+云产品组合使用，搭建了第一代基础设施云：整个架构以数据为核心，包括 SaaS 化数据服务平台、安全接入和防护、数据服务层，数据处理层、云安全等。

视野数科业务架构图

做为一家科技行业的创业公司来说，在创业之初是需要将业务快速跑起来，最初所有应用都是单体烟囱式架构、手工部署，但基于技术侧的短板，这些架构优化工作一直被耽搁。

但近两年这类基于技术架构的问题被日益凸显。可以看作，数据是企业业务的核心资产，数据的安全、稳定和效率是服务大型客户的关键。在固有的模型下，视野数科测试环境无法获取客户全量真实数据，很多 case 覆盖不到，只能等上线前，在灰度环境（等同预发）频繁发版 & 测试的过程中才暴露了一些问题：

1）开发迭代效率慢：单体烟囱式架构，代码耦合度高，开发效率慢。

2）上线流程复杂，成本高：使用 SVN 代码管理+人工部署，缺少规范化 DevOps 流程，每次上线前研发、质检、运维三个团队在灰度环境都需要大量的协作，来回折腾 20～30 次数据校验，频繁发版测试，开发和运维幸福感很差。

3）容量预估无法自动化：每次客户侧有营销活动/重要事件（如新华财经金融排名等），需提前一周告知视野数科备容 ECS，存在备容不准风险和闲置浪费问题。

针对以上的问题，视野数科自身的技术架构升级已剑在弦上。据了解，视野数科内部曾讨论过两个方案：

方案一：ECS 自建 Docker+开源微服务，发现能快速容器化&提升资源利用率，但底层基础施运维（DockerDaemon 升级、配置管理、镜像仓库管理等）和开发工作量大（微服务组件自研），上线运维风险高。简单 POC 之后，做出集体放弃的决定。

方案二：使用商业化的微服务 PaaS 平台托管应用，发现能降低微服务门槛，能为微服务组件的稳定性兜底，但 ECS 还需要自己运维还是很繁琐，而且整体费用太高超预算。

最终，在一次技术沟通会上了解到 SAE，结合公司当时的技术背景，发现 SAE 和公司的技术升级改造有很高的契合度，不改代码、不改变应用现有的部署方式，享受到微服务 + Serverless + K8s 的完整体验，开箱即用，也免去后期的运维。视野数科开启了架构升级的践行之路。

技术架构全面升级

工欲善其事,必先利其器。在正式迁移业务之前，视野数科做的第一件事就是标准化上线流程，期望通过持续集成来减负。

1）从 0 到 1 打造 Git + Jenkins + SAE 的云原生 DevOps 体系。

2）通过 SAE 低门槛完成微服务架构转型，一步升级为微服务 + K8s + Serverless 架构。

前期挑选了主线产品—防爬识别应用的新版本，尝试做微服务拆分。拆分后基于 Spring Cloud 标准开发，然后部署到 SAE。过程中发现 SAE 对 Java 微服务的支持实在是太全了：完全不需要客户考虑数据隔离、分布式事务、熔断设计、限流降级等，也无需担心社区维护力度有限二次定制开发的问题，开箱即用，极大提升了开发效率。而且在开源基础上，SAE 通过深度集成 MSE，提供了无损上下线、服务鉴权、全链路灰度等高级服务治理能力。帮助客户屏蔽 K8s 技术细节，让客户零门槛容器化，无感拥抱 K8s。

在实践 SAE 的过程中，采用了独立业务 + 用户灰度的策略，逐渐放大流量，将一部分业务陆续上线，然后再迁移历史存量应用。

持续演进，打造金融级云平台

因为金融行业的特殊性，在将 ECS 架构升级为 Serverless 架构的过程中，其实一开始很担心 SAE 不能匹配金融安全合规监管需求。但经过和 SAE 同学沟通确认，以及 SAE 产品的不断演进，彻底打消了视野的顾虑。

1）等保合规：在 ECS 模式下使用的云盾、防火墙、DDOS、保垒机等安全防护产品还继续可以使用，SAE 也提供入侵检测和漏洞扫描。SAE 后来也支持了容器镜像服务企业版部署应用，支持镜像安全扫描及多维度漏洞报告，保障存储及内容安全。

2）安全隔离：SAE 同学告知用户流量侧无倾入，选择 JDK 为 Dragonwell 后续还能支持通信加密。底层基于安全沙箱容器 + VPC 网络，能实现系统 + 网络 + 数据的多重安全隔离。

3）操作审计：在 SAE 上的一些操作，可以通过 SAE 独有的发布单回溯变更历史    。同时 SAE 也对接了云产品操作审计，能查询云上所有的操作行为日志和增删改查事件。

4）权限管控：SAE 还解决了一个老大难的问题：权限隔离和审批。以往 ECS 模式下，尤其是新人到岗或者跨团队联调时，配置用户组、RAM 权限，新机器登陆连接方式，非常繁琐，账号管理人员也时常会成为瓶颈。更重要的是运维操作没有审批，风险不可控，开发都有机器的用户名和密码，发布比较随意。使用 SAE 后，以应用粒度添加权限，一个应用添加一次即可，省心省力。SAE 还通过主子账号设计了运维审批流程，有效收敛了线上随意发布带来的质量风险。

运维效率提升 60%，效果显著

通过和 SAE 平台不断的磨合验证，视野数科的一部分应用已经陆续迁移到 SAE。整个迁移过程平滑，无任何改造成本，零故障，并且只投入了 1 个研发人员。接下来计划将整体架构全面迁移到 SAE，充分享受云原生技术红利。

打造金融科技行业标杆，企业大数据大有可为

就当下而言，金融、工业、农业等很多行业正走在数字化的快车道之上。

其中金融行业足够特殊。一方面其数据源比较标准化，另一方面金融数据覆盖面和应用面相对较广泛，行业对数据的认可度较高。如今视野数科基于对核心金融机构服务的经验，已经在行业有口皆碑，其数据质量获得了行业一致好评。

据了解，当下视野数科已经打造了多条产品线，既有“无场景”化的数据查询平台，也有基于特定业务场景化的业务功能化平台。除了业界标准的数据外，其还为不同数据划分了更深层次，更全面的标签。

值得称道的是，视野数科面向国民经济的 100 多个产业链，6000 多个细分行业和接近 10 万种的“产品服务”分类投入了大量的研究力量，并产出了较为精准完善的产业分类体系。凭借对数据标签的深层次挖掘，构建出了其对各类企业相关数据的深层次加工和再计算能力。