技术开发 频道

东方金科基于开源的开发平台建设之路

  李家智 ,就职于东方金科,现任架构师一职。作为行业享有盛名的大咖,李家智行事低调,对工作热情饱满,多次受邀作为嘉宾出席各类大会,并发表了精彩演讲。2018年10月17日,李家智 受邀参加了由IT168主办的《SACC 2018第十届系统架构师大会》,并发表了精彩演讲,以下内容根据 SACC大会实录整理。

  什么是金融公司里的IT公司?

  东方金科东方金科是东方邦信融通控股全资子公司,是中国东方资产管理公司旗下唯一一家科技公司,也是典型的金融公司的IT公司。

  中国东方资产管理股份有限公司,成立于1999年,注册资本为100亿元人民币,处置中行剥离出的政策性不良资产。2016年, 经国务院批准中国东方改制为股份有限公司。2017年,在主管监管部门的支持和指导下,中国东方顺利完成引入战略投资者工作,成功引入全国社会保障基金理事会、中国电信集团有限公司、国新资本有限公司、上海电气集团股份有限公司等四家投资者。

  截至2017年末,中国东方集团总资产超过9,800亿元,在国内中心城市设有25家分公司和1家经营部,业务涵盖不良资产、保险、银行、证券、信托、普惠金融、信用评级,国际业务等。

  金融公司里的IT公司通常有三种运营方式:

  第一种是信科部门独立运营,比如:建信金融,还有民生科技等。因IT部门具有特殊性,独立运营有利于做得更专业,薪酬能够更加市场化,有利于留住更多IT人才。

  第二种是拆分运营,比如:兴业数金、招银云创。将本行的IT系统、金融云、运营和维护能力输出给中小型金融机构。

  第三种是新建子公司,成立互联网金融综合平台,像光大云付一样。与互联网公司相比,这类公司更了解银行,对银行的要求理解得更为深刻,对监管的要求和规则执行得更到位。

  基于开源的开发平台如何构建?

  对于金融企业来说,大家都在强调要有自己的开发平台。为什么这样做?

  东方金科架构师李家智的看法是:首先,是政策原因,技术必须要自主可控。其次,历史原因。资产公司的IT信息化建设发展较晚,早期的系统都是交给第三方厂商完成。新的技术创新环境会推动科技企业自己做开发平台,和第三方厂商协作完成。

  现在的东方金科仍然是以第三方合作厂商为主,东方金科辅助厂商去共同研发。希望未来能以东方金科研发的开发平台为主,和厂商协作,来交付金融系统。

  开发平台早期是像“火锅”,有底料,有牛、羊肉,有配菜,根据金融系统的不同需求,提供不同的产品。未来随着金融系统的成熟发展,其开发平台也会发生变化,这种变化更像是各种品牌的汽车。有奥迪的不同款型,也有保时捷,它们虽然都是汽车,但是都来自于同一款大众MLP平台。未来,金融系统的开发平台也要这样做。

  金融系统的开发平台应该自下向上构建,每一层都可以以项目的形式落地。第一层是开发规范和管理规范;第二层是技术框架和UI库;第三层是业务参考模型;第四层是服务和组件;第五层是开发平台;第六层是可视化开发平台。

  在技术框架的选择上,东方金科是在公司内部业务基础上定义的一套后台系统,有业务参考模型,包括用户决策权限什么,有服务组件,有文档预览服务,还有处理服务组件,包括各种UI控件、Java控件,在这基础上构建了自己的开发平台。金融企业应用的业务参考模型,流程相比于互联网企业同样的模型和流程,更有深度。

  在团队架构方面,包括几大部分。

  第一,是信息科技部,负责指导监督计划执行,还有成果落地。因为开发平台并不是一蹴而就的,它的每一部分成果都可以在项目中使用,所以这部分由信息科技部去指导,由项目经理负责去落地。

  第二,是三方咨询团队,是由东方资产聘请的第三方公司负责做技术咨询和技术评审。

  第三,是金科技术委员会,也做技术支持,技术评审,这是一个内部的委员会。当然东方资产也有个技术委员会,级别更高,有些内部解决不了的问题,就会往更高的技术部门去汇报。

  第四,是项目群中项目经理,负责开发平台已有部分成果落地。

  第五,是PMO监督计划执行。

  第六,是技术创新部,负责研发开发平台,同时也同其他团队做一些协作,比如UI前端以及互联网技术合作等。

  在开源技术框架构建时,东方金科踩过很多坑。

  第一个坑是,是否采用Spring Boot。虽然,现在看采用Spring Boot毋庸置疑。但是两年前,争议非常大。自有技术框架在公司群众基础好,呼声高,Spring Boot 了解人少。但是最后的结论是,采用Spring Boot。自有技术呼声败给了时间的流逝,Spring Boot开始碾压式的流行。

  第二个坑,平台是否需要支持可视化开发?当时,公司上下都对这个功能曾非常有兴趣。后来调研了商业软件,觉得开发效率提升有限。业务逻辑过于复杂,可视化做不到。最后的结论是:不做可视化开发,做代码生成。

  第三个坑是,是否为业务人员提供完善的流程设计器?业务人员直接参与流程的定制和部署,这是一个美好愿望。但是流程过于复杂,不支持直接部署,业务人员更倾向于提供需求,而不直接参与流程定制。所以,最后做了不需要完善的面向业务人员的流程设计器。

  第四个坑是,工作流是否需具备固定的用户模型?集团层级复杂,汇报路径多样。工作流应用到各个项目中的用户模型不一致。最后的结论是,工作流不具有固定用户模型,有业务端解释用户模型而不是工作流。

  第五个坑是,UI组件库是什么样式?视觉团队提供了素色的一个版本,但是总裁喜欢活泼一点。互联网研发团队也有自己的风格偏好,比如,字体大,间距大。企业应用研发团队认为页面内容需要密集展现。大家一致认为应该以业务需求为导向,但是对于开发平台,业务人员根本没空。最后,先有一个风格再说,技术上必须易于调整。

  第六个坑是,前端框架用哪个?React,Vue,Angular 小规模用过 , Bootstrap+JQuery 前端人员非常熟悉。3个月的React使用失败,现有React组件库无法支撑金融后台UI系统需求。传统企业应用公司,开发模式决定了前端人员一直储备不足。最后只能回到传统开发模式,使用Bootstrap+JQuery。

  第七个坑是,用成熟的商业开发平台还是自研?商业和开源产品都调研过。商用产品价格不菲,从十万到百万、千万。并且,商业产品落地成本较高,部分产品商用技术较为落后,不支持系统拆分。最终选择了自研,好处是成本小,贴近业务需求。

  第八个坑是,开发平台如何落地?金融系统规模较大,不会轻易更换技术。并且融系统数量有限,能使用机会不多,不同于互联网系统,东方金科的选择是“零敲牛皮糖”。

  第九个坑是,阿里开发手册还是唯品会开发规范?“孤尽”名气大,“江南白衣” 也不是浪得虚名。唯品会开发规范和落地结合,与Clean Code和 Effective Java结合也很紧密。结论是,选用唯品会开发规范,并取得授权。

  第十个坑是,怎么解决技术偏好之争?当时的分歧主要有三个:分歧一:项目骨干之间技术之争;分歧二:技术委员会之间技术之争;分歧三:与咨询公司的技术之争。结论是,选择正流行的开源技术,因为能自主掌控的技术就是可选技术。

  第十一个坑是,企业是否需要统一的组织架构视图?每个系统,无论大小,都有一个用户和组织机构模型,每个系统都会重复建设,但是每个系统关注的组织机构模型“深度”不一样。最终决定是,每个系统暂时拥有各自的组织机构模型,开发平台根据“深度”要求定制模型。

  第十二个坑是,遗留系统问题。作为以业务驱动为主的公司,技术创新非常尴尬。研发人员不足,研发投入不足,研发成果落地困难,研发和项目群关系尚未理顺。

  为什么会选择Spring Boot 2 ?

  之所以选择Spring Boot 2,是因为它是现成的技术框架,凝聚着国内千万软件企业曾经的努力结果。另外,Spring Boot的开发特别简单。虽然Spring Boot有着自己的问题,比如对配置的依赖,后期扩展很难。但是,它能简化部署,还能进行部署监控等。最重要的是,Spring Boot改变了应用系统组织方式,能将系统拆分成小系统或者微服务。

  举一个例子,Spring Boot能让单元测试更加简单。现在单元测试面临的现状是,大部分程序员一直宣称自己做了单元测试,但实际上这是一个假的单元测试。因为单元测试有个特点是,必须是可以重复测试,但实际上据我所知,很多单测试都无法重复的。

  Spring Boot让测试变成非常简单,比如它可以通过注解,来模拟一个无法测试的内容,或者还未完成类。比如我们的积分系统管理,管理是一种设置,是一个没办法去做的单元测试。我们可以模拟一下,比如说模拟一个用户输入,模拟用户输出,这样去测试。还可以模拟各种情况,比如模拟异常或者模拟调用次数。

  企业应用很多测试会涉及到数据库,大多数会选择最初始化的一个数据库脚本去做测试。但是这样会有两个问题。第一个问题就是条款本身不是特别直观,尤其对于企业数据来说,它会产生大量的数据。如果用生物小本模拟,其实对于维护来说不是特别直观。第二个问题,你在单元测试完毕需要去做比较验证的时候,也需要写大量的代码去比较验证。如果从数据库取数据,还要看接口是不是一样,所以说我们在开发平台也做了一定程度增强。用Excel来模拟一个测数据,比如包含注册,我们也可以应用库的一个其他的一个基础的测数据。

  我们调试了各个表数据表数据可以调用的方法,也可以定义变量,在测试完毕过后,可以将数据库数据跟Excel数据进行比较。这样单元测试代码量就非常小,而且非常容易维护。无论是开发人员或者项目经理,或者需求人员,都能看明白你要测试什么,结果是什么,所以我们增强了数据模拟和测试验证。

  Activiti 流程引擎的重要性

  Activiti是流程引擎,采用它,是因为它是基于BPMN2.0,成熟可靠。并且,它的设计是将运行流程和历史流程分开,能支持数十万流程的同时运行。还有,国内有很多Activiti扩展的文章和工具。

  如果没有接触过工作流,想象中的工作流程应该是按照环节划分,以单线形式进行设计。实际应用中,系统里面能审批的流程非常少,这并不意味着企业没有决策执行,只是能落地到流程的内容很少。普通的流程跳转是正常流程,节点之间需要添加连线,任务撤回是不可能的,流程结束不可能恢复。但是国内应用很任性,流程节点可以任意跳,任意回退,不必要定义连线,只要新任务未处理,就可以撤回,结束的流程也能起死回生,并且可以回到任意节点。

  有人可能会说,为什么要回溯,能不能重新发一个流程?对于东方资产来说,重新发一个流程的成本非常大,环节特别多,会经过很多公司,甚至还涉及到很多总裁、经理、委员会的审批等。

  Activiti流程引擎能大大降低了流程的复杂度。

  那么,开源开发平台到底要怎样构建?最后总结一点,企业要基于开源技术自己干构建,并且整个开发平台要自下而上,逐层构建。

0
相关文章

    澳门威尼斯人官方网站