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

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