论文部分内容阅读
为了应对中国全面开放金融行业以来，面临的更加复杂而激烈的竞争压力，国内银行纷纷实现以SOA基本架构思想为基础，以面向客户服务为中心的核心业务系统，同时满足稳定性、灵活性和拓展性等多方面的需求。毋庸置疑，现代银行的业务运营过程已经与IT应用系统的支撑水乳交融、无法分离，IT应用系统的交付能否与业务需求协调一致，是银行业务服务的根本保证。
目前，国内银行业的新一轮IT技术变革正在如火如荼进行之中，面向服务的架构（SOA，Service Oriented Architecture）这个关键要素，亟需被重新审视、理解和运用，从本质上为企业架构的设计与管理提供支撑和帮助。
作为一个与业务管理相结合的企业架构模型，SOA在1996年由Garnter提出，而随着XML、SCA、SDO、WS-POLICY等工业标准的推进，逐步被专家学者、软件厂商、企业所接受，成为2000年后最主要的企业架构模型。时隔多年，很多观点认为SOA的方法、技术都已经成熟了，甚至说现在已步入了后SOA时代。而事实上，不论是银行业或是其他大规模的以IT技术为支撑的行业，仍在SOA的发展方向上不断探索，道路依然长远。
诉求和必要性
相比上一轮银行IT大规模建设以“大集中”为鲜明主题，此轮IT建设则是以架构的合理性、灵活性和可管理性为主题。从需求上，可以归纳为以下几个方面：
业务灵活性需要。国内金融的快速发展导致银行的数量和规模均在不断增长，银行从最早的存贷业务走向多元化，随着利率市场化等宏观政策不断开放，银行间的业务竞争将白热化。灵活适应市场需求而快速开发新产品是未来银行的核心竞争力之一，如何从传统的业务、讨论、计划、评审、开发、测试、投产的标准建设模式中，加速业务需求的实现并增加自主管理性，是业务部门的关注点。
可管理性需要。业务管理方面，在传统的业务实现中，业务人员主要负责需求整理和接受测试，其余的实现、管理等均由IT人员负责，业务实现和运行情况只能通过固化的系统界面或定制化报表来获得。随着精细化管理的深入和风险管控粒度的加强，业务和管理部门希望能够更为实时地了解业务运行状况，甚至可以对具体业务进行规则化干预，从而了解分析业务运行状况、个性化用户体验或是加强风险控制等。
IT管理方面，主要体现在全行级应用治理、IT服务水平治理、IT监管和审计上。
全行级应用治理：现有的IT架构中，主要通过各系统群中的前置系统来监控系统间的交互数据，存在较多局限性，也难以提升到企业级的视角。在新一轮银行IT建设中，IT部门的管理者更希望能够掌握IT架构的整体视图，从不同切面（如业务架构、应用架构、数据架构、安全架构等）了解IT架构演进状态并进行应用管理，同时还能获得各业务/应用的运行情况，从而进行合理规划和治理。此外，以往银行采用分而治之的策略实现IT对业务的支撑，即业务部门对应不同的IT服务条线，根据不同的业务要求进行系统实现和管理，长此以往，导致很多功能的重复建设；随着系统建设数量和规模的增加，功能一致性和数据一致性保障的复杂度越来越高。因此，银行也迫切需要改变这一局面，对系统功能在企业级角度进行整合，提高复用度，减少重复建设和一致性保障难度。
IT服务水平治理：在IT治理的范畴中，服务水平约定（SLA，Service Level Agreement）是一个关键度量指标，传统的IT架构中SLA指标少，颗粒粗。当一些大中型银行的IT运营到达一定规模和成熟度时，服务水平约定的作用将凸显，SLA将多达成百上千项，乃至成为IT部门内考核/核算、与业务部门合作的重要客观依据，也为IT管理提供了标准化手段。
IT监管和审计：银行IT部门经常要面对监管机构的各类检查和审计工作，由于其复杂性、临时性和多元化，相关人员往往措手不及。如果IT运行和应用管理的粒度和广度能够更加细化和自动化，那么审计和统计工作也就能够简化很多。
技术架构
在SOA环境下，银行内主要业务交易系统间的关系，可分为服务请求方、服务枢纽和服务提供方三层。服务枢纽有别于传统银行IT架构中的大前置，强调在全行视角下，将所有解耦后的服务进行灵活组合、调度及统一管理。
企业服务总线：支持对各服务提供方服务的注册和发布，负责对服务请求方请求的路由、格式转换、访问控制和流量控制，提供对所有注册服务的服务质量管理；组合服务：提供对细粒度服务的编排组合，以可视化和配置化方式实现对服务的灵活组合，形成基于短流程（无人工参与、基于交易、非持久化）的粗粒度服务，并发布在企业服务总线上供请求方调用；业务流程管理：提供基于长流程（有人工参与、持久化）的编排组合，组合的服务来自于企业服务总线上的任意服务，也包括业务流程管理中自身的其他流程，提供面向业务和IT人员的可视化流程定义、执行、管理和优化；数据总线：负责非实时的批量数据交互和转换，及其调度管理、数据共享等。
由于所有实时服务的路由都经过企业服务总线，因此便于从全行角度实施企业服务总线的服务监控和治理，以准实时的方式进行监控和统计分析，并提供服务水平约定的考核，以及基于日志的业务事件捕获和分析。在架构上，服务治理也可以通过服务提供方、系统、服务请求方、业务种类等维度，对全行应用的交互进行管理和优化。企业服务总线之上的组合服务、业务流程管理，因其可视化编排和配置化定义的特点，极大地满足了业务部门对业务灵活性的需要，并使其参与到设计和管理中去，运用业务活动监控和流程优化，进一步满足业务运营的合理性和效率最大化。数据总线则提供对数据分析、数据同步等的支撑能力，结合ODS/数据仓库为审计、运营绩效等提供灵活的数据分析手段。
虽然这样的服务化支撑架构能够较好地解决上一节中提到的主要问题，但SOA架构建设是一个“牵一发动全身”的浩大而又缜密的工程，除了各部门的密切配合、各级人员对SOA理念的深入认识之外，更需要关注SOA实施过程的关键问题。 关键环节
SOA是一个松耦合的组件架构，但必须是有序和可管理的。在实施SOA的过程中，业务组件和系统功能随业务流程梳理逐步分解或整合，这对传统的业务部门各自实现系统并进行管理的方式形成冲击。对于整合后的一些公有组件和功能，必须有明确的职能部门管理和协调，例如企业客户信息管理、公共主数据、基础平台等。而对于新兴的跨业务部门的组合产品、服务流程或交叉营销等，也需要有明确的业务部门来进行牵头协调。
SOA的实施改变了IT管理模式，从应用系统管理演变成对服务的管理，SOA提升业务功能的灵活性，但同时也会增加功能集成的复杂度。银行以往管理应用的方式都是以系统为最小单位的，出错时也是首先定位到交易所在的系统或前置系统，再进行排查。而在SOA化后，一个交易可演化成由若干个系统或功能组件共同提供业务流，当这样的交易在全行交易占较大比重时，其管理复杂度将极大提升。此外，根据IT系统设计的思想，在交易完成链路中的节点越多，则风险越大。因此，在跨应用的服务形成时，需要着重考虑服务的完整性和可靠性，可以在统一流水、事务及补偿机制、数据同步、日志记录等方面的设计上进行强化。
SOA提倡信息系统建设的标准化，但是以效率为前提。虽然没有严格定义，在技术框架上，SOA通常会和WebService联系在一起。早期的WebService是为了解决互联网环境中远程服务的功能集成问题而设计的，因此提供了一整套对于远程服务的定义描述、探索发现、注册发布、调用等规范，为潜在/未知的服务调用者提供标准化的便利。对于银行内部而言，在企业服务总线架构下，所有的服务请求方和提供方对于行内人员均是已知的，而从IT系统建设流程上，任何服务调用也必须经过严格的设计论证和测试后方可投产。因此从机制和效率角度，可以对企业内的WebService进行精简和定制，去除探索发现等不必要的环节，合理利用WS-SECURITY、WS-ADDRESSING中的必要机制，提高开发效率以及报文传输和处理效率。
另一方面，SOA的标准化也是一个长期的过渡过程。受早期相对落后的通讯带宽和处理机制制约的影响，目前银行业系统间交易的主要通讯方式仍以TCP协议加之二进制报文形式进行，以高效为主要前提。虽然目前主流的服务器配置以及网络带宽都有了成倍提升，但从TCP上的二进制报文转换到HTTP的SOAP报文，其平均长度将至少增加5倍。此外，由于服务功能的细化分解，增加了系统间的交互次数，一个传统交易平均会分拆成3次以上服务交互，因此从全行角度，整个架构中的通讯量至少要提升15倍。加之业务变化和增长，如何保证SOA架构下的效率是重中之重，特别是跨网络区域的交互，例如双中心间，或总分行间的交易或数据传递。精简SOAP报文中的命名空间和标签名称、提高服务的自包含性、选择合理的服务粒度，都可用于减少系统解耦带来的压力。
SOA是一个去中心化的架构，但对于抽象出的公共组件，实际却是功能集中的。松耦合是SOA的最主要特性之一，从单个系统角度来看，传统的应用被分解为可以自包含的多个细粒度服务，供其他系统调用。对整体架构而言，只有对解耦后的服务进行复用，才能体现SOA的真正价值。那么，对于被抽象后的公共组件，被复用得越多，从单点上看就是集中化的，例如企业客户信息主数据、业务流程引擎、规则引擎、认证授权、报表分析等等。那么对于这些以往分散在各个应用系统内的功能组件，在SOA标准化之后，在性能、稳定性、功能接口的完整性、数据一致性等方面将有更高要求。
演进路线
全行级的规划。架构体系的升级离不开全面的规划设计，SOA是一个自上而下与自下而上相互结合的体系，必须要进行全行业务、流程、交易、系统功能等的完整梳理，抽象出适用于该行的设计原则，明确全行的业务和功能板块，以及相互之间的关系，从而形成一个分工明确、相互支撑、职能合理的全行架构体系。
基础设施先行。如果现有体系架构中并未涉及SOA特征的基础设施建设，那么在新的IT体系建设中，建议首先考虑基础系统建设，如企业服务总线、服务组合、业务流程管理等。这些系统涉及范围广，也影响到相关系统的接口及流程设计，提前建设将减少业务系统建设或改造的复杂度。同时，这些基础设施的建设也能够在新旧架构过渡中，起到至关重要的作用。
循序渐进地演进。稳步前进是银行IT建设的一个重要原则，任何IT建设都需要考虑循序渐进的过程，实现现有系统逐步向SOA化体系过渡。同时需要尽可能减少过渡方案本身对周边系统的影响，利用SOA的基础设施、设计好各板块的推进策略及项目建设的关联关系，这些都成为稳步推进的必要手段。
目前，国内银行业的新一轮IT技术变革正在如火如荼进行之中，面向服务的架构（SOA，Service Oriented Architecture）这个关键要素，亟需被重新审视、理解和运用，从本质上为企业架构的设计与管理提供支撑和帮助。
作为一个与业务管理相结合的企业架构模型，SOA在1996年由Garnter提出，而随着XML、SCA、SDO、WS-POLICY等工业标准的推进，逐步被专家学者、软件厂商、企业所接受，成为2000年后最主要的企业架构模型。时隔多年，很多观点认为SOA的方法、技术都已经成熟了，甚至说现在已步入了后SOA时代。而事实上，不论是银行业或是其他大规模的以IT技术为支撑的行业，仍在SOA的发展方向上不断探索，道路依然长远。
诉求和必要性
相比上一轮银行IT大规模建设以“大集中”为鲜明主题，此轮IT建设则是以架构的合理性、灵活性和可管理性为主题。从需求上，可以归纳为以下几个方面：
业务灵活性需要。国内金融的快速发展导致银行的数量和规模均在不断增长，银行从最早的存贷业务走向多元化，随着利率市场化等宏观政策不断开放，银行间的业务竞争将白热化。灵活适应市场需求而快速开发新产品是未来银行的核心竞争力之一，如何从传统的业务、讨论、计划、评审、开发、测试、投产的标准建设模式中，加速业务需求的实现并增加自主管理性，是业务部门的关注点。
可管理性需要。业务管理方面，在传统的业务实现中，业务人员主要负责需求整理和接受测试，其余的实现、管理等均由IT人员负责，业务实现和运行情况只能通过固化的系统界面或定制化报表来获得。随着精细化管理的深入和风险管控粒度的加强，业务和管理部门希望能够更为实时地了解业务运行状况，甚至可以对具体业务进行规则化干预，从而了解分析业务运行状况、个性化用户体验或是加强风险控制等。
IT管理方面，主要体现在全行级应用治理、IT服务水平治理、IT监管和审计上。
全行级应用治理：现有的IT架构中，主要通过各系统群中的前置系统来监控系统间的交互数据，存在较多局限性，也难以提升到企业级的视角。在新一轮银行IT建设中，IT部门的管理者更希望能够掌握IT架构的整体视图，从不同切面（如业务架构、应用架构、数据架构、安全架构等）了解IT架构演进状态并进行应用管理，同时还能获得各业务/应用的运行情况，从而进行合理规划和治理。此外，以往银行采用分而治之的策略实现IT对业务的支撑，即业务部门对应不同的IT服务条线，根据不同的业务要求进行系统实现和管理，长此以往，导致很多功能的重复建设；随着系统建设数量和规模的增加，功能一致性和数据一致性保障的复杂度越来越高。因此，银行也迫切需要改变这一局面，对系统功能在企业级角度进行整合，提高复用度，减少重复建设和一致性保障难度。
IT服务水平治理：在IT治理的范畴中，服务水平约定（SLA，Service Level Agreement）是一个关键度量指标，传统的IT架构中SLA指标少，颗粒粗。当一些大中型银行的IT运营到达一定规模和成熟度时，服务水平约定的作用将凸显，SLA将多达成百上千项，乃至成为IT部门内考核/核算、与业务部门合作的重要客观依据，也为IT管理提供了标准化手段。
IT监管和审计：银行IT部门经常要面对监管机构的各类检查和审计工作，由于其复杂性、临时性和多元化，相关人员往往措手不及。如果IT运行和应用管理的粒度和广度能够更加细化和自动化，那么审计和统计工作也就能够简化很多。
技术架构
在SOA环境下，银行内主要业务交易系统间的关系，可分为服务请求方、服务枢纽和服务提供方三层。服务枢纽有别于传统银行IT架构中的大前置，强调在全行视角下，将所有解耦后的服务进行灵活组合、调度及统一管理。
企业服务总线：支持对各服务提供方服务的注册和发布，负责对服务请求方请求的路由、格式转换、访问控制和流量控制，提供对所有注册服务的服务质量管理；组合服务：提供对细粒度服务的编排组合，以可视化和配置化方式实现对服务的灵活组合，形成基于短流程（无人工参与、基于交易、非持久化）的粗粒度服务，并发布在企业服务总线上供请求方调用；业务流程管理：提供基于长流程（有人工参与、持久化）的编排组合，组合的服务来自于企业服务总线上的任意服务，也包括业务流程管理中自身的其他流程，提供面向业务和IT人员的可视化流程定义、执行、管理和优化；数据总线：负责非实时的批量数据交互和转换，及其调度管理、数据共享等。
由于所有实时服务的路由都经过企业服务总线，因此便于从全行角度实施企业服务总线的服务监控和治理，以准实时的方式进行监控和统计分析，并提供服务水平约定的考核，以及基于日志的业务事件捕获和分析。在架构上，服务治理也可以通过服务提供方、系统、服务请求方、业务种类等维度，对全行应用的交互进行管理和优化。企业服务总线之上的组合服务、业务流程管理，因其可视化编排和配置化定义的特点，极大地满足了业务部门对业务灵活性的需要，并使其参与到设计和管理中去，运用业务活动监控和流程优化，进一步满足业务运营的合理性和效率最大化。数据总线则提供对数据分析、数据同步等的支撑能力，结合ODS/数据仓库为审计、运营绩效等提供灵活的数据分析手段。
虽然这样的服务化支撑架构能够较好地解决上一节中提到的主要问题，但SOA架构建设是一个“牵一发动全身”的浩大而又缜密的工程，除了各部门的密切配合、各级人员对SOA理念的深入认识之外，更需要关注SOA实施过程的关键问题。 关键环节
SOA是一个松耦合的组件架构，但必须是有序和可管理的。在实施SOA的过程中，业务组件和系统功能随业务流程梳理逐步分解或整合，这对传统的业务部门各自实现系统并进行管理的方式形成冲击。对于整合后的一些公有组件和功能，必须有明确的职能部门管理和协调，例如企业客户信息管理、公共主数据、基础平台等。而对于新兴的跨业务部门的组合产品、服务流程或交叉营销等，也需要有明确的业务部门来进行牵头协调。
SOA的实施改变了IT管理模式，从应用系统管理演变成对服务的管理，SOA提升业务功能的灵活性，但同时也会增加功能集成的复杂度。银行以往管理应用的方式都是以系统为最小单位的，出错时也是首先定位到交易所在的系统或前置系统，再进行排查。而在SOA化后，一个交易可演化成由若干个系统或功能组件共同提供业务流，当这样的交易在全行交易占较大比重时，其管理复杂度将极大提升。此外，根据IT系统设计的思想，在交易完成链路中的节点越多，则风险越大。因此，在跨应用的服务形成时，需要着重考虑服务的完整性和可靠性，可以在统一流水、事务及补偿机制、数据同步、日志记录等方面的设计上进行强化。
SOA提倡信息系统建设的标准化，但是以效率为前提。虽然没有严格定义，在技术框架上，SOA通常会和WebService联系在一起。早期的WebService是为了解决互联网环境中远程服务的功能集成问题而设计的，因此提供了一整套对于远程服务的定义描述、探索发现、注册发布、调用等规范，为潜在/未知的服务调用者提供标准化的便利。对于银行内部而言，在企业服务总线架构下，所有的服务请求方和提供方对于行内人员均是已知的，而从IT系统建设流程上，任何服务调用也必须经过严格的设计论证和测试后方可投产。因此从机制和效率角度，可以对企业内的WebService进行精简和定制，去除探索发现等不必要的环节，合理利用WS-SECURITY、WS-ADDRESSING中的必要机制，提高开发效率以及报文传输和处理效率。
另一方面，SOA的标准化也是一个长期的过渡过程。受早期相对落后的通讯带宽和处理机制制约的影响，目前银行业系统间交易的主要通讯方式仍以TCP协议加之二进制报文形式进行，以高效为主要前提。虽然目前主流的服务器配置以及网络带宽都有了成倍提升，但从TCP上的二进制报文转换到HTTP的SOAP报文，其平均长度将至少增加5倍。此外，由于服务功能的细化分解，增加了系统间的交互次数，一个传统交易平均会分拆成3次以上服务交互，因此从全行角度，整个架构中的通讯量至少要提升15倍。加之业务变化和增长，如何保证SOA架构下的效率是重中之重，特别是跨网络区域的交互，例如双中心间，或总分行间的交易或数据传递。精简SOAP报文中的命名空间和标签名称、提高服务的自包含性、选择合理的服务粒度，都可用于减少系统解耦带来的压力。
SOA是一个去中心化的架构，但对于抽象出的公共组件，实际却是功能集中的。松耦合是SOA的最主要特性之一，从单个系统角度来看，传统的应用被分解为可以自包含的多个细粒度服务，供其他系统调用。对整体架构而言，只有对解耦后的服务进行复用，才能体现SOA的真正价值。那么，对于被抽象后的公共组件，被复用得越多，从单点上看就是集中化的，例如企业客户信息主数据、业务流程引擎、规则引擎、认证授权、报表分析等等。那么对于这些以往分散在各个应用系统内的功能组件，在SOA标准化之后，在性能、稳定性、功能接口的完整性、数据一致性等方面将有更高要求。
演进路线
全行级的规划。架构体系的升级离不开全面的规划设计，SOA是一个自上而下与自下而上相互结合的体系，必须要进行全行业务、流程、交易、系统功能等的完整梳理，抽象出适用于该行的设计原则，明确全行的业务和功能板块，以及相互之间的关系，从而形成一个分工明确、相互支撑、职能合理的全行架构体系。
基础设施先行。如果现有体系架构中并未涉及SOA特征的基础设施建设，那么在新的IT体系建设中，建议首先考虑基础系统建设，如企业服务总线、服务组合、业务流程管理等。这些系统涉及范围广，也影响到相关系统的接口及流程设计，提前建设将减少业务系统建设或改造的复杂度。同时，这些基础设施的建设也能够在新旧架构过渡中，起到至关重要的作用。
循序渐进地演进。稳步前进是银行IT建设的一个重要原则，任何IT建设都需要考虑循序渐进的过程，实现现有系统逐步向SOA化体系过渡。同时需要尽可能减少过渡方案本身对周边系统的影响，利用SOA的基础设施、设计好各板块的推进策略及项目建设的关联关系，这些都成为稳步推进的必要手段。