构建SOA架构时应该注意的问题?

交行531核心系统用的是soa架构，不敢妄谈soa架构需要注意的问题，只说说我们系统目前的问题。问题1：组件设计大多不合理，因为我们有一个组件复用度的考评，导致有些组件包含的功能太多，反而不容易维护。问题2：性能问题，组件化后，一个交易往往会在不同组件中反复读相同的表记录，举个栗子，我们的卡取款交易，在卡信息查询组件读一下卡信息，卡行为检查组件会查一下卡信息，卡支取组件再读一遍，收费的时候再读一次，对高蘋交易来说非常可怕，现在我们对这类交易去组件化以后cpu时间可以直接减少30%。问题3∶复用度高了版本更新是个问题，经常要停机，好在db2 11解决了bind的问题。问题4∶原本我们认为不太会要变更的组件因为业务需求变了要经常变更。

这个问题太大，构建SOA架构需要战略、业务、技术的有效推动和协同。而目前银行在SOA架构转型往往普遍面临战略和业务的推动和配合不足，所以简单说说几个近期考虑的技术层面问题：

1）设计建立适合银行自身的，合理完善的组件架构模型（概念级）；

2）组件间的集成交互是要构建的最重要基础能力，除Esb外，也建议大家研究一下互联网企业的RPC+消息中间件模式；

3）服务无状态的问题，服务无状态很重要，但状态去哪儿了？缓存或数据库存储状态、BPM维护状态、通过分布式事务管理支持事务状态等都应该要支持；

4）切入点的问题，银行传统业务复杂多样且稳定性要求太高，选择新渠道新业务尝试SOA是合理的切入点，例如互联网金融，也即是建立架构混合模式逐步演进；

5）关于新技术和人员管理，Gartner近期提成双模式IT团队的观点，同事新技术团队采用DevOps是合理和确有必要的。

其他方面还可以谈很多，基于篇幅不多说了。

要分两部分来进行讲解：

1 原有系统架构中的集成需求

当SOA架构师分析原有系统中的集成需求的时候，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，我们必须考虑一些更加具体的集成的类型，这主要包括以下几个方面：应用程序集成的需求，终端用户界面集成的需求，流程集成的需求以及已有系统信息集成的需求。当SOA架构师分析和评估现有系统中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在任何种类的企业中都有一定程度的体现。针对不同的企业类型，这些集成方式可能是简化的，或者没有明确地进行定义的。因而，SOA架构师在着手设计新的体系结构框架时，必须要全面的考虑所有可能的集成需求。例如，在一些类型的企业系统环境中可能只有很少的数据源类型，因此，系统中对消息集成的需求就可能会很简单，但在一些特定的系统中，例如航运系统中的EDI（Electronic Data Interchange 电子数据交换）系统，会有大量的电子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这种情况下整个系统对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构建的系统架构能够随着企业的成长和变化成功地继续得以保持，则整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成。

2 服务粒度的控制以及无状态服务的设计

当SOA架构师构建一个企业级的SOA系统架构的时候，关于系统中最重要的元素，也就是SOA系统中的服务的构建有两点需要特别注意的地方：首先是对于服务粒度的控制，另外就是对于无状态服务的设计。

SOA是将业务敏捷和快速创新视为目标的架构设计方法,强调跨业务组建域的系统间的松耦合和服务复用,但不提倡为了SOA而SOA,不论是点对点,EAI,还是SOA,都是要实现系统整合的手段,如果选择构建SOA架构，需要有足够的业务驱动力，需要评估SOA架构对现有架构及应用的改造复杂度，需要明确各SOA功能组件的功能定位以及对总体架构的影响，需要对服务进行定义和规约，需要设计可落地的服务治理的手段和工具,需要考虑数据标准等等，我们需要认识到SOA服务的积累是一个过程，所以SOA架构的成本曲线有可能是先高后低的，如果经过积累，SOA架构将发挥其满足业务敏捷、快速创新、降低成本的目标。