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

　　李家智 ,就职于东方金科,现任架构师一职。作为行业享有盛名的大咖，李家智行事低调，对工作热情饱满，多次受邀作为嘉宾出席各类大会，并发表了精彩演讲。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。

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

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

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!