哈希游戏- 哈希游戏平台- 哈希游戏官方网站

　　大约自2017年开始，国内中小银行开始铺开JAVA银行核心的建设，这时采用服务注册发现机制JAVA银行核心开始号称为分布式银行核心。随后大行业逐渐建设分布式核心，由于数据量较大，不得不模仿支付宝的单元化架构。在客户数据量达到亿级的时候，IBM的小型机处理起来的确很吃力，而大型机则过于昂贵。“堆x86或RAM服务器”成为了大家不约而同的选择，支付宝率先遇到海量数据问题，所以它先探索出解决单元化解决方案。

　　还记得2016年底我们上线贵州农信核心系统，客户量是7千万，数据库服务器采用IBM的两台E880服务器，配置是80核1T内存。2018年初我们上线个亿，数据库服务器也是采用两台E880服务器，配置是88核1T内存。这样的小型机在国内当时已经是顶配了，我们还是非常担心无法支撑系统上线，经过程序的大量调优后才上线的。对于农信尚且如此，对于国有大行和股份制银行其实是很难支撑的，所以说单元化架构也是大型银行必然的选择。

　　单元化架构的推广离不开布道者的努力，云原生架构的成熟也离不开云厂商的大力宣传。无论是布道还是商业宣传，无疑都大大推动了国内IT技术发展。但是，靠跟风很难做好大型IT系统设计，大型IT系统建设周期和使用周期都很长，一般长达十多年。在十多年间互联网巨头的宣传日新月异，其战略可能发生了巨大调整。犹记得两年前某互联网巨头大力进军银行核心系统，现在已经解散团队、战略收缩，这给正在实施其核心系统的银行带来不少麻烦。

　　阿里的一位老领导曾说：“如果金融系统是IT业的皇冠，那么银行核心系统则是皇冠上的明珠”。银行核心的技术架构是最为规范的，其对技术组件的技术要求也是最为严苛的，本文主要剖析银行核心的架构和组件，期望管中窥豹，看到技术发展的一些脉络。云原生架构分为IaaS、PaaS、SaaS三层，其中IaaS为基础资源层，PaaS为中间件、开发运行运维组件层，SaaS为应用层，最近两年在PaaS层与SaaS层中间出现了aPaaS层。

　　对于私有云来说IaaS层本质是计算、存储、网络的虚拟化管理，公共云的IaaS则是使用这种虚拟化管理方式向大众提供共享计算服务。两者有本质区别，公共云重点采购便捷灵活、’初期成本低，私有云讲究融入企业IT管理现状中，企业人员方便好用。对于大型企业来说，采用云来对整个企业的IT资源进行管理，能大幅度提升资源利用率，这的确是一种不错的选择。目前需要大量算力的应用只有数据处理、风控、客服等，未来随着人工智能应用的普及大型企业对算力的需求会越来越高，采用私有云来对算力进行动态管理和分配是必由之路。

　　量体裁衣自建云国内IaaS做得好的厂商有华为、阿里、腾讯，其中阿里是最早研发云的厂商，其技术体系较成熟，但也比较老。华为和腾讯是基于OpenStack进行深度二开实现的，技术较新，也是比较主流的实现方式。近两年基于OpenStack二开的云厂商如雨后春笋在国内蓬勃发展，这体现云的门槛已经没有几年前那么高，稍微大一点的企业完全可以基于OpenStack构建自己的私有云。OpenStack是一系列IT资源管理的开源软件组合而成。其主要组成部分有负责计算资源管理的Nova、负责对象存储管理的Swift、负责块存储管理的Cinder，以及负责网络的Neutron。

　　在云上要支持动态的扩缩容，容器里的本地磁盘是随时可能被释放的，所以必须有专门的存储管理软件。OpenStack支持对象存储和块存储，对象存储是一种扁平化和离散化管理文件的方式，简单的看就是把文件拆分成多份，分散到各物理存储中存放，以提升读写速率，并能实现备份。由于是采用扁平化的管理结构，文件查找效率也远高于块存储。云上的块存储类似于传统的本地磁盘存储，采用树状的文件目录管理模式，通常挂载为云服务器的本地盘。

　　云上的网络是虚拟网络，简单的理解就是利用网络传输软件对物理路由和交换机传入传出的数据进行包头解析，根据包头信息发送到相应的目标服务器上去。相当于在物理网络包头的基础上封装一段软件可以解析的报文头，用该报文头来实现虚拟网络层的数据包传输。这样就能用软件控制网络传输，通过复杂的控制可以模拟出一个虚拟的网络（VPC）。OpenStack是采用Neutron实现的虚拟网络传输，它的功能比较简单，没有较全面的模拟物理网络，目前比较成熟的开源虚拟网络传输软件是Overlay。国内不少云厂商的虚拟路由和虚拟交换机都是基于这个款开源软件打造的。用软件定义路由器和交换机后，就使得在云上部署复杂的软件系统集群，甚至是部署整个机房得以实现。不过，虚拟网络在物理层数据传输是不隔离的，数据传输的安全性是需要重点关注的。

　　人们对效率的追求是永无止境的，人心总是难以满足，这是人的本性，也是技术发展的原始动力。近些年随着各种技术组件越来越多，各大云厂商对PaaS技术组件进步进行了集成，形成了更便捷的应用运行平台，他们把各种技术中间件、监控运维组件等集成在一个统一的运行平台上，让应用只需连接到统一运行平台上，就能使用平台上的所有中间件，省去了大量中间件和运维监控组件的适配调试工作。阿里的SofaStack、腾讯的TSF、aws的BeanStalk就是目前典型的统一运行平台。

　　随着低代码或零代码开发的思想逐渐成熟，云厂商和国内IT服务提供商们发现还能进一步封装和集成通用的技术能力，进一步减低业务开发的复杂度。于是逐渐产生了aPaaS的概念，aPaaS基于PaaS能力进一步集成并且新增服务编排、批量调度、参数缓存、分布式序列、热点资源、对外供数等组件，以及其他辅助业务逻辑实现的技术组件。形成了国内具有特色的大型IT系统开发、运行、维运体系，这些aPaaS组件也许会成为未来10年国内大型IT系统建设的基石。

　　注册中心有满足ACP理论中的AP和CP两种，目前对性能要求较高的都选满足AP的注册中心。注册中心的功能一般有服务注册、服务发现、服务注销、心跳探活、服务订阅、服务查询、服务修改等。在单元化架构下注册中心需要支持单元间注册信息同步，大部分开源注册中心是不支持的。单元间服务切换，开源注册中心也不支持，例如实现当本单元的某个服务存活量低于百分之多少时，流量切换到备单元。另外，一个企业级注册中心，一定要跟企业的运维监控平台打通，这要求注册中心必须提供服务查询、服务修改、服务注销等接口，以便于运维管理集成，获得企业级的服务管理能力。

　　Redis其实是一个很鸡肋的中间件。在分布式单元化的大型IT系统中，一般有几千个JVM节点，每个节点都去访问Redis缓存，其压力显然是很大的，它不适合在大型IT系统当做缓存组件使用。而且Redis在同城双活架构中无法实现双活，缓存刷新也需要根据业务系统情况写代码进行控制。再则，把缓存放在Redis中，必须通过网络去获取，在跨机房访问场景下需要1~2毫秒，在耗时上完全失去了缓存的高效性。其实它只是在小型系统中使用得较多，例如简单的锁场景、简单的抢购场景、简单的技术参数或业务数据缓存场景。

　　目前的中间件是近10年互联网技术发展过程中，前人在解决问题过程中沉淀下来的技术组件，我们在解决我们自己遇到的新问题时，也一定会沉淀一批技术组件。特别是在微服务化、单元化、云原生架构下，我们遇到的问题是10年前的中间无法解决的。其实，在国内银行核心建设过程中已经沉淀了大量新的“中间件”，但因下文中提到的一些原因并没有开源出来。Redis已经是10年前的产物，而且在两地三中心和多地多中心架构下问题频出，性能受网络限制并不高。我们为什么还会奉若神器？也许是人总善于崇拜，不善于创造。

　　负载均衡是最重要的流量管控组件，也是服务治理的关键节点。有的人认为服务治理可以用一个产品来实现，实则不然。我见到某公司的一个团队花了两年时间做服务治理产品，目前为止还没做出可用的产品。根本原因是服务治理不是一个产品，是一系列的规则和理念。需要全系统甚至全企业的各种技术组件配合完成，服务治理的主角其实是监控运维系统，负载均衡为监控运维系统提供流量控制规则的配置接口，监控运维系统根据监控情况自动或手动调整流量分发规则，才能保障系统长期稳定运行。

　　分布式事务和服务编排有着密不可分的集成关系。某国内互联网巨头的服务编排产品最初没有分布式事务管理，分布式事务管理需要在分布式事务产品中再配置一遍服务流程。我当时给了他们一套分布式事务管理方案，并建议他们直接把分布式事务集成到流程编排中。无论是可视化服务编排，还是硬编码服务编排，只要调用远程服务就需要分布式事务组件管理分布式事务，服务编排可以根据远程调用服务是否为非查询交易，自动开启分布式事务的子事务，再根据交易最终状态调用分布式事务的回滚或提交，如此则实现分布式事务的自动管理。

　　目前，分布式事务必须跟服务编排结合已基本形成共识，但采用哪种分布式事务还存在分歧。分布式事务有XA、AT、SAGA、TCC模式，XA模式性能太低在大型系统中鲜有采用，AT模式在银行核心系统的自动冲正有采用，但由于它需要登记SQL语句执行的前后值，性能也不高，所以只在对性能要求不高的交易的自动冲正中使用。SAGA和TCC是在大型系统中采用得比较多的，其中建设银行、中国银行、邮储银行、民生银行等银行核心采用的是SAGA模式，支付宝、平安银行、四川农信等采用的是TCC模式，大家从采用这两种模式的使用方应该就能感受到两种模式的优劣。

　　从SAGA的事务管理过程不难看到，它是没有隔离性的，也就是交易还没有最终成功前，部分交易结果已经对外暴露，可以被其他交易修改。如果交易失败需要回滚，则可能回滚失败。不过，这种隔离性问题在具体的场景中是可以规避的，例如在银行的转账场景中，可以采用先转出后转入的方式避免银行资损。多借多贷交易中也可以对金额增加方做部分冻结，最后统一解冻的方式规避事务隔离性问。除了个别场景，大部分场景采用SAGA事务是没有隔离性问题的。

　　相对SAGA事务模式TCC事务模式较为复杂，为了隔离性其设计了中间态，在实际的交易开发时中间态不容易界定，并且有些场景是不宜设置中间态的。例如登记明细，不宜登记一条中间状态记录然后再修改为确定态，因为明细表的更新效率很低。另外，在实际使用中，对TCC理解不到位的架构师总喜欢把业务逻辑放到Confirm阶段执行，因为这样比较方便，但实际上Confirm阶段只能技术性的确认资源，不能做业务逻辑处理。如果选用TCC，又因很多操作难以抽象成TCC模型，只能使用SAGA，这意味着选择TCC模型也必须有SAGA模型，这导致系统变成一个混合事务模型，事务管理极其复杂。再加上TCC的二阶段需要大量的一阶段信息，这种信息的传递和存储对系统的开销很高。

　　我为大型IT系统招聘人员的时候，如果是互联网IT架构背景的人，我一般都要给他讲“造轮子”的道理。目前大部分PaaS层组件基本上是国内互联网大厂用开源软件改造的。互联网技术界流传着一句话：“不重复造轮子”，这几乎成为了所有互联网软件架构师的“圣经”。前几年互联网2.0在蓬勃发展，互联网公司采用的是丛林法则，讲究的是快速做出能挣钱的产品，砍掉赔钱的产品，其大部分IT系统的生命周期很短。然而大型IT系统的生命周期都是10年左右。当我们做一个生命周期较长的大型IT系统时，我们还是拿“开源的轮子”拼凑吗？是利用开源深度改造成本高，还是根据技术原理和自身需求进行开发成本高？在大型IT系统生命周期内“开源的轮子”如何更新升级和修复BUG，它闭源了怎么办？这些问题都是值得仔细评估的，而不是一句“不重复造轮子”就能定论的。

　　每个大型企业都有自己的IT历史、有自己的IT沉淀、有自己的IT规范、有自己的管理规范、有自己的团队分工。这些是企业的历史渊源，部分是企业的包袱，部分是企业的资产和骄傲。“开源的轮子”要想完美的架在每一个大型企业下，是不可能的。所以很多大型企业在建大型IT系统的时候尽量都不直接使用“开源的轮子”，他们会根据自身需要新造轮子或深度改造“开源的轮子”，通常会请大量外包人员帮自己造轮子。 帮大型企业造轮子是个“苦力活”，互联网巨头们并不愿意做这种生意，他们愿意做的是那种没有边际成本、可以无限复制的标品售卖，至于需要定制的部分交给合作伙伴吧。无论是开源组织、还是有标准产品的大厂，他们都会告诉我们不要重复造轮子，直接使用他们的“轮子”。作为“轮子”使用方自然不能人云亦云，需要根据企业现状和未来规划判定轮子是否合适。对于生命周期较长的大型IT系统，需要根据未来的运维和运营需要来决定是否要“量体裁衣造轮子”。

　　其实国内银行核心系统在建设过程中，各软件服务商已经沉淀了一套能提升业务逻辑开发和运行效率的aPaaS层和工具链体系，这些基本上是他们自己造的“轮子”。这些软件若开源出来，国内也许能形成独立完整的软件开发、运行及运维体系。但这些都是商业化产品，而非开源的demo级软件，这些产品的开源有诸多困难。最大的问题是商业资产外流，如果是国企央企还会涉及国有资产流失问题。其次是国内没有形成完善的版权机制和共识，开源软件的盈利模式没有形成。再次，是产品级的技术组件比demo级的开源组件重很多，绑定了很多特定的应用场景，这不利于其开源推广使用。只有把这些问题解决了，国内才能形成一套面向当前问题和未来发展的技术组件体系。

　　很多人喜欢把系统的各种缓存混为一谈，总是在全局缓存中加入交易级缓存，在交易级缓存中考虑如何实现全局缓存。分布式系统中分为全局缓存、交易级缓存，交易级缓存又分为组合交易缓存和基础交易缓存。组合交易缓存是跨远程调用的，其缓存需要在远程节点间用返回报文和请求报文传递，即联机引擎自动把缓存内容封装在上一个节点的返回报文中，在下一个节点通过请求报文传入，自动解析到内存中，从而实现上一个远程节点的缓内容传递到下一个节点的缓存中。基础交易的缓存相对简单，只需在程序中借助ThreadLocal实现。

　　参数缓存同只针对全局缓存，主要实现需要按版本管理的业务参数的全局缓存。如果多个技术参数也需要按版本发布，开源的配置中心是难以实现的，这时也可以用参数缓存同步。参数缓存同步的功能有缓存查询、缓存加载、缓存更新、缓存同步、缓存核对、缓存版本管理、缓存版本回滚等。支持版本管理，包括按版本发布、按版本回退、按版本核对缓存信息。还支持参数缓存的灰度发布，即指定IP端口的发布。为了实现贯彻监和控一体化的理念，参数缓存同步提供缓存查询、核对、手工刷新接口，以便运维管控平台集成。

　　在单元化架构中获取全局唯一且递增的序号并不容易，在Oracle数据库中获取序列比较简单，调用一个数据库函数即可，然而在单元化架构下需要用一个序列生成组件进行产生序列号。其主要原因是去Oracle数据库后国产数据库没有那么高性能的序列生成能力。个别国产数据库的Proxy有序列生成能力，但高并发下效率低，而且偶尔会重复；其次，单元化系统的吞吐量一般大于集中式系统，需要的序号生成能力也是大于原来集中式的，这加大了序号生成的难度。所以分布式序列应运而生，也可以说是在新架构下为了解决新问题，我们不得不创造这个技术组件。

　　异步处理的热点资源方案可以与TCC或SAGA两种记账方式进行整合。按照TCC的流程对热点资源的操作进行拆分，把对热点资源竞争态的判断操作与TCC的Try进行整合，把对热点资源交易数据确认的动作放在CONFIRM(确认阶段)，把对交易数据状态回滚状态的动作放在CANCLE(取消阶段)，最后由异步任务对交易确认后的记录进行汇总更新到热点资源值中去；热点资源与SAGA记账的整合也是类似步骤，但执行SAGA的DO接接口的时候可以省去资源确认步骤，执行UNDO节点的时候反向登记一笔交易记录。

　　热点资源引擎通过分析传统的热点处理模式，通过剥离传统的热点记账的业务逻辑，抽象出一个通用的热点资源技术组件，用于解决热点资源计算这个行业级难题。热点资源引擎分为分同步处理、异步处理、热点资源监控、并行处理框架四个模块。同步处理包含增减的热点值、热点资源值查询、维护热点值状态、清除热点记录等接口；异步处理包含异步汇总余额、异步更新交易后余额、异步汇总限额等功能；热点资源监控包括热点事件识别、热点资源设置、热点资源取消、热点事件扫描等；并行处理框架是针对热点资源需要极高的异步汇总效率，而打造的一个基于令牌桶机制的并行处理框架，该框架除了能高效的调度异步处理任务，在高可用方面也做了很多考量。

　　数据聚合有数据捕获、数据同步、同步模板配置、数据分库分表、同步任务管理等功能。数据捕获是通过数据捕获SDK拦截应用系统的DAO层，对数据的增删改操作进行进行拦截，触发异步的方式查询操作结果数据同步到数据聚合服务端。数据同步是在数据同步服务端根据数据同步模板对数据进行解析，并且落库聚合库。在数据存入聚合库的时候可以按照配置策略对数据进行分库分表，以支持海量数据的聚合，并且能高效的更新不同维度进行查询。

　　目前主流的拆分单元是按客户拆分的，当上送客户号时直接采用客户号取hash，后取绝对值，再对单元总数取模获取一个数字，这个数字则可以对应着单元号。在最初的支付宝中方案中，交易都是上送客户号的，所以它的单元路由相对简单。在银行的交易中，有些交易并没有上送客户号。单元路由是在交易没有上送客户号的情况下，根据账号、证件类型和证件号码、手机号等信息找到客户号，再根据客户算出分片号，以确定该笔交易路由到哪个单元。这需要建立客户号与账户、证件号、手机号之间的关系，在国产数据库下保存这个对应关系的表本身又需要进行分库分表。这样就逐渐增加的单元路由的复杂度，复杂度增加后自然就需要一个独立的技术组件来进行封装，这也是单元化路由在银行核心项目中被完整创造出来的原因之一。

　　但是，目前并没有公司把它当做一个平台来规划和设计，甚至有的公司把它当做流程引擎的扩展，把分布式事务、分布式锁等复杂组件简单的往上集成，使整个联机引擎复杂极高，且没有清晰的设计和架构。在南方某股份制银行核心项目中，80%以上的问题产生于联机引擎。联机引擎设计之初并不是“复杂的组件”，而是封装交易处理流程中的公共处理的组件，主要目的是提供标准的公共逻辑处理层，让具体的业务开发人员不用重复写每只交易的公共逻辑，降低业务开发难度，提升项目质量。

　　2018年我们在民生科技做分布式核心研发，那时没人知道在分布式核心中日终批量如何运行。于是我把银行核心日终批量的70多个作业全部梳理和分析了一遍，最终我们论证通过了一种分布式核心系统跑批的方式：先收集待处理数据集，然后把待处理数据集逐条封装成请求报文，通过联机请求触发联机交易去处理日终批量逻辑，也就是现在大家说的”批转联”。批转联中的收集待处理数据集对应着集中式系统日终作业中的大循环的循环数据集，其循环内的逻辑则需要封装为联机交易逻辑。

　　批量引擎与集中式的批量平台相比较，除了批转联的整体思路改变，其中的流程控制还是跟集中式的控制逻辑一样。在任务分发和管理方面也需要做相应的改变，任务分发需要支持按单元分发，任务状态管理需要根据批转联任务执行情况来处理任务状态。批量引擎在分布式单元化架构中对其高可用方面也提出了新的要求。任务拆分均匀程度和吞吐量也有了更高的要求。一个新问题的解决，人们总是倾向于原有方案中做修改，以期解决新问题。在银行核心系统做分布式改造的初期就是如此往下推进批处理问题解决的。

　　目前市面上的批量引擎主要基于spring batch或xxl-job二开而成。其功能主要有作业定义、作业向执行机分发、单元化的作业分发、企业级系统间的作业分发；还有持作业状态管理，由下层批量任务控制器反馈作业执行状态并进行持久化存储供状态查询，以及按单元查询和统计。在流程控制方面，联机引擎有作业流程控制，包括基于作业依赖和时间依赖以及事件触发等多种作业调度编排方式；在流程控制中有分支流程、串行流程、并发流程、循环流程等，批量作业的操作有中断、恢复、跳过等。批量引擎对批量任务的数据段进行分片，分片策略通常有分段、一致性哈希、取模、按单元等方式。

　　基于spring batch开发的批量调度引擎，一般采用开源软件比较简单和轻量级的特点，不会记录业务处理详细记录，只记录任务处理的chunk数据，而且它进行多次拆分，任务能较均为的分散到执行器中。这类调度引擎效率通常比较高，缺点就是任务记录较为简单，任务拆分逻辑比较抽象没有业务含义，很难适应大型业务系统建设中进行大规模开发。在大型系统的开发中，除了要求效率，而且还要求有详细的操作过程记录和批处理情况记录，相应的记录势必会造成性能下降，这是批量调度引擎设计时需要权衡。

　　文件引擎的处理步骤通常是：文件上传、文件通知、文件解析落库、文件内容校验（文件头处理）、文件内容执行（文件体处理）、文件处理结果核验（文件处理）、回执文件等。在文件引擎中必须有文件批类型管理和文件批次管理，文件批类型管理用于创建、修改文件批对应的文件模板、上送/返回文件路径、挂载文件头体尾处理逻辑、设置文件批的优先级、控制文件批量访问渠道等等；文件批次管理则是管理具体的次运行的文件批任务，包括批次的状态、批次的流程控制、批次信息的查询等。

　　联机网关一般有转换层，包括接口协议转换、接口报文映射、业务相应码转换、简单逻辑转换；接口管理，包括接口定义、接口维护、接口删除、接口查询，以及企业级接口同步；服务治理，包括限流、熔断、降级，开源的网关是通常是服务级的，通常需要做到一定改造才能实现接口级服务治理。造成这个问题的原因是互联网架构师认为的服务通常是一个接口，而大型金融系统的架构认为的服务通常是一个微服务；服务控制，包括访问鉴权、黑白名单；以及参数映射、服务分组管理、路由转发、灰度。

　　网关虽然有很多功能，其中重点还是协议转换和报文转换，支持的协议类型是判定网关能力的重要考量点。协议转换和报文转换的效率也是网关最重要的性能指标，一个高性能的网关，做一个50参数的协议和报文转换耗时不应超过5ms，为了提高性能，有些网关还采用了只解析报文头的方式。甚至有些网关在RPC协议中，通过查找字节码方式截取报文头进行解析，以极高的效率做报文转换、协议转换，以及流量控制。有TCP协议的握手机制非常消耗性能，有的网关直接采用长连接的方式。总之，网关是一个系统的门户，对稳定性和高效性要求极高，采用多少性能优化措施都不为过。

　　消息网关与联机网关很类似，除了报文来源是消息体，其他的都可以复用联机网关能力。不过，需要处理好消息消费失败的场景，消费失败分为业务系统消费失败和网关组件消费失败，两种情况需要采用不同方式进行处理。外呼网关其实就是联机网关的反方向处理流程，但其需要一个SDK把系统内的请求转发到外呼网关中，外呼网关也应该跟联机网关和消息网关分开部署，以便灵活控制系统流入流量和流出流量。文件网关与联机网关有一定区别，首先是其不适合跟联机网关和消息网关部署在一起，通常会跟文件引擎或文件批量部署在一起。

　　国内大型金额机构和头部IT服务商在信创和云原生转型过程中，沉淀的这些aPaaS中间件如果开源出来，国内将形成新一代中间件，这代中间件将支持着我国大型IT系统在未来10年高效平稳运行。至于国外开源的注册中心、配置中心、MQ消息、Redis缓存等产品，没必要照抄一遍。因为这些产品在单元化、云原生架构下，以及大型系统的应用场景中需要进行深度的改造才能使用，不如根据新架构、新技术及信创要求研发新的产品，去解决我们遇到的新问题，只有这样我们才能摆脱“技术跟屁虫”的窘境。

　　大型IT系统有很多复杂的模块，其逻辑复杂性高，而且特别集中，这类模块通常可以抽象成一个引擎。例如限额引擎、规则引擎、热点资源引擎等。限额引擎专门用于控制各种额度以及数值的最大值、最小值。规则引擎则用于控制系统中各种状态变化和流转的，热点资源引擎则是上文在aPaaS中阐述的一个技术组件。在银行核心这种标准的系统中，这类引擎很常见。抽象成引擎后其参数可以由专门的引擎管控端进行配置，限额引擎和规则引擎基本上可以把系统中各种额度限制和状态流转都配置出来，通过改变配置就能改变各种数值的限制和状态的变更，这样的系统运行起来就非常灵活，实现真正的敏捷。

　　2013年的时候我们本土化改造Oracle的一款银行核心系统Flexcuble。这是国内引入的首款Java银行核心，这款产品异常复杂，本土化改造量很大，实施成本非常高，但还是拿下了好几个客户，其中有一个股份制银行和两个农信。Flexcuble的最大亮点就是产品工厂做得特别好，当时国内核心普片还在做参数中心的时候，它已经把银行核心系统的参数进行整理归类，形成了产品工厂。产品工厂能让产品研发人员快速的配置出市场所需的产品，这才是真正的敏捷，这种敏捷是敏捷开发无法企及的，对于对稳定性、安全性要求较高的系统应该追求这种敏捷，而不是敏捷开发。

　　Flexcuble等国外产品的引进，给国内银行核心系统厂商做了些参考，使后来国内新研发的java核心系统从面向参数设计演变成了面向产品设计。以往面向参数设计的系统也能做到很高的灵活度，但没有对参数按业务属性进行整理，甚至有些核心系统的参数直接是键值对形式的，取名也比较偏技术。产品人员根本看不懂，也配置不明白。所以真正的产品工厂是要采用业务语言描述，产品人员能看懂、能配置。这一波银行核心建设主要是信创推动，业务人员很少参与，个别项目业务人员甚至明确不参与。这种情况下新建的核心系统，是否有产品工厂似乎也没人关心。

　　适配层包括对外接口的适配层，以及数据模型持久化的适配层。也就是在对外接口层到业务逻辑层之间加入一层适配层，让定制化版本在适配中进行改动。另外，核心业务逻辑要与数据模型解耦，避免不同版本对存储的信息有不同的要求，导致数据模型改变，从而改动核心业务逻辑。这要求业务逻辑不能直接操作数据模型，而是操作业务逻辑所需的实体模型，在业务逻辑层和持久化层中间加适配层，做定制化版本的持久化层适配，以保护核心业务逻辑稳定。

　　aws的云平台中有一款很优秀的产品叫Beanstalk，它对环境的封装就非常好，可谓是真正的大师级产品。真正的技术大师不会把技术菜单和按钮摆满屏幕，而是把用户直接意图所需的操作放在最显著的位置，用户在没有阅读操作手册的情况下，凭借直接意图就知道点哪个按钮。顺着用户意图逐渐要求客户去补充相关配置和信息，并且给出很多的默认配置，尽量降低用户的知识要求。反观国内大厂的同类产品，把所有菜单都展示出来，菜单栏上几十个菜单，必须认真研读其操作手册，理解其中复杂的关系后才能勉强会用，要想熟练掌握必须考一个证书才行。有的产品有导航式引导，但它是引导客户进行基础参数配置的，而不是用户的直接意图，用户一开始就很疑惑为什么要配置那些繁琐的配置，而且用户必须要看操作手册才知道如何配置。

　　数据的权利大致可分为所有权、管理权、使用权。数据的所有权理应属于相应的个人或机构，管理权则属于管理相关数据的机构或个人，使用权属于被数据所有人授权使用的机构或个人。这三种权利需要严格区分和保障，数据所有者有权对自身数据的使用授权进行管理及享受数据使用的收益，数据不应被数据管理者擅自使用，数据更不能被数据管理者默认占有，数据管理者只要数据除存储加工处理权利不应有使用权利。只要有对这些权利进行严格规范和管理，人们才能在这个数字化的世界中安全生存。

　　那么大型IT系统如何做到真敏捷？如何具有更强的适应性？以确保在未来的竞争中适合并且生存下来。我想其设计理念应该是离不开上面谈到的基础理论的。根据上述理论：“事物总是以自身存在为目的，进行对外作用和对内调整”，IT系统满足这个理论则可经久不衰，满足这个理论这需要三个模块或部分：内部调整部分、输出部分、接入部分。理论上，一个IT系统只要这三个模块足够强大，那么它就有对未来环境的强大适应能力，并且能真正敏捷的支持业务发展。

　　在当前技术条件下，做好内部调整部分可以是做好系统的参数化、引擎化、可视化流程编排、产品工厂等方面；输出部分则可以有对外供数、数据聚合、数据清洗和分析等，也可以有系统监控、自检、外呼等，还可以有系统运行效能、运行成本等；输入部分目前大家比较注重联机网关、消息网关、Mesh等，其实还应有IT系统对业务变迁的感知，比如“业技一体化”之类的技术和理念，它弥合了业务与IT实现间的鸿沟，让IT随业务而动，此乃真敏捷。

　　人其实本身就是一个非常完美的系统，其大脑类似于一个强大的控制引擎。人的身体构造本身几万年来都没太多变化，变化比较大的是其大脑里的思想。通过快速改变大脑的思想来适应环境，使人这个“超级系统”存在了几万年。对应这人的一些特征，系统设计时应该为其设计各种参数引擎、流程编排器、产品工厂等，以提升系统对内的调整能力；其次还需要有对外的感知部分，比如同业的同类系统业务开展情况，通过一些公开的数据进行分析，以调整快速调整自身产品参数，确保产品比同业产品更受市场欢迎；再则需要对外输出模块，以便和外部系统协同，例如向监控系统输出系统运行状态，以及向数据下游系统提供丰富的数据。只有对内可调整维度足够多、调整幅度足够大，对外作用精准有效的系统才能在长时间内更好的适应环境。未来，采用深度神经网络作为控制引擎的系统也许更能适应环境。