金融系统IT系统的架构前端体系特点 （一）

                                        金融系统IT系统的架构前端体系特点 （一）    

                                                                                                                                  文：一苇渡江

1、前端的逻辑，需要兼容机构个性化，渠道个性化，系统个性化等组合维度的复杂性。
      1）金融系统IT通常受制监管的平台的约束，很多数据需要上传到平台，各个地方政府由于地区差异等（各自表现自己的政绩，在信息化上的与众不同），各平台的数据已经接口差异非常大，集中平台与分省平台并存，而且升级的速度各有差异。为了兼容这些省份，产生非常多的机构个性化。
     2）为了提倡不同渠道上差异，鼓励某些线上的渠道，保协或监管层会在某些渠道下调优惠或者便捷投保方式，会有渠道个性化，加大了保险公司，银行，证券，基金等IT系统的复杂程度。     
    3）企业内部人员流动及分化，随着规模的扩大，产生非常多系统管理不同的领域，例如业务员划归业务员管理系统，内勤回归内勤的管理系统，但最终是汇流到核心系统。
    故，核心系统汇流统一的流程，屏蔽着机构个性化，渠道个性化，系统个性化的差异，而金融IT系统的前端，需要接纳这些个性化的需求，而且有一个要求，就是改动某个渠道前端逻辑，不能影响非改动渠道的正常逻辑。

2、前端的业务逻辑复杂，代码大，查问题复杂难。
     1）金融系统原本就为业务服务，直接给业务提供价值的。而金融类的系统或者手机端往往都是嵌入大类的业务逻辑判断，前后端校验。前后端的校验的一致性，避免维护两套校验逻辑，否则容易发生维护不一致的情况。

     2）而我所在的金融公司又是经常上需求大类修改系统业务逻辑的情况，前端改动频繁，就对前端的质量体系提出更高的要求，并且生产一旦发生问题，需要在10分钟或者30分钟以内马上恢复或者修复，否则直接损失钱的问题。特别是有些需求是放在同一个版本中，而版本的部分需求经常受监管的要求，例如某某平台4月1号升级新功能必须使用，不能回滚。若回滚版本经常需要十几个关联系统一并关联需求的影响而回滚，造成波浪式回滚的。
     3）前端还是后端问题，在核心系统只能修复，不能回滚的。因为回滚的风险更高。上面提到的业务特点的复杂性，对前端代码质量的把控上，前端开发人员提出更高的要求，风险意识，设计意识，对问题快速定位，分析影响，修复方案的锻炼，要求非常高。

 

3、前端逻辑重，DOM节点数庞大，联动多，页面大，性能要求高。
      1）金融IT系统部分是对内的，部分是对外，绝大部分是有需要各种权限限制，必须登录以后操作。由于数据录入项多，业务越是大，体系越是庞大，逻辑会越多。由于业务的特殊性，经常需要多个模块之间有联动，若分页操作，经常需要翻屏，所以业务也不接受分页分屏的思维。不能分屏，只能集中，所以业务经常需要集中处理，页面或前端JS就带来非常多挑战。

      2）如何将业务所需的众多字段，众多的业务联动逻辑或者资源能够充分放在一个资源有限的沙箱式浏览器中，并且充分发挥浏览器性能，并且保持流畅，又要保持高度可维护性，成为前端开发人员最大的命题。在解决放的问题，还要解决要命的性能问题。

      3）“一卡车的沙子都积压在一个手推车里”，还要手推车要跑得像卡车一样的速度与安全性，十分考验前端设计人员的功力。

 

4、安全与部署的双重要求
        金融IT系统对信息安全的要求基本是比较高，包括一些敏感信息屏蔽，收集信息的屏蔽与展示，XSS与SQL注入的等要求，在信息安全是要求比较高的，对应金融企业客户信息的泄露是致命的。而前端常用一些数据储存，都是不能放类似cookies这一类储存与存放数据客户端。

        对前端的数据的统一风格的校验，也是特别的严格。过于代码的校验严格，很容易造成前端维护上的困难。部署若是复杂，类似各种静态NAS储存前端静态资源，缓存类的数据都会给部署带来很多的挑战。

      

       我们的前端架构师或者核心开发人员就是要解决上面的问题。下一篇就是探讨一下我们的解决方案以及前端性能优化过程的解决方案。

 

       如需转载，请注明作者一苇渡江，附带链接。保留追究原创法律追究权利。