dryr

浅谈与CTG通讯的J2EE系统部署架构

当前金融、电信等行业的IT系统中，常常会使用主机来实现核心系统，而通过J2EE、.net等技术来实现外围应用，外围系统必然与核心的主机系统之间有着接口、数据等方面的交互，对时效要求比较高的部分，一般需要在外围系统与核心主机系统之间形成实时的交互接口，来满足业务的需要。外围系统与核心主机系统之间一般需要通过CTG（cics transaction gateway）来完成通讯和交互，本文主要探究一下与CTG通讯的J2EE系统的部署架构，CTG与主机系统间的部署架构不在本文讨论范围之内。
在探究与CTG通讯的J2EE系统的部署架构前，我们先来说明一下此类系统的技术架构，一般的技术架构如下图：

这里稍微解释一下，DAO分为两部分，一部分DAO是连接DB的，另一部分DAO则是连接CTG的（通过ctg与主机通讯）。这里的DB是指业务系统本身的数据库。
一般情况下这类J2EE系统的部署架构会将除展现层+service层+dao层打包在同一个包中，部署为一个业务应用，这个应用通过jdbc数据源与DB连接，通过cics配置文件（通过socket去连接）或通过j2c连接工厂去连接，如下图：

 在这种部署架构中，业务系统与CTG的连接会被业务系统部署的服务器绑定，即业务系统部署在集群中的哪几个服务器，则这几个服务器必须与CTG连接，这一方面大大增加了配置工作量（假设每个业务系统都需要连接CTG，则每台应用服务器都必须配置与CTG的连接参数），另一方面对所有的应用服务器都暴露了CTG参数，降低了安全性。另外，业务系统与CTG的连接因为业务系统部署的应用服务器数量而导致产生性能瓶颈，一个业务系统如果部署在两台应用服务器上，则此业务系统只能通过这两台应用服务器去连接CTG，如果此业务系统与CTG之间存在大量的连接需求，则可能会导致性能瓶颈，这时候只能通过添加业务系统部署的应用服务器来解决，但业务系统本身性能并没有达到瓶颈，所以增加部署的应用服务器这种办法存在很大的浪费，但这又是唯一的办法。
基于以上问题，我们需要分析一下业务系统的各个层次，以及这个部署架构，来试着找出另一种部署架构以解决上述的问题。先来看看与CTG连接的dao层，dao层有两个功能，第一个功能是为service层提供数据对象服务，另一个功能是连接CTG调用主机接口。我们考察连接CTG这个功能，这个功能的本质就是封装了CTG的调用，使CTG调用对业务系统透明，将业务数据传递给CTG，本身不存在业务逻辑，只是一个简单的通讯转发的功能。我们再来考察一下这个部署架构，这个部署之所以有上述的问题存在，其中最主要是因为在部署上，将业务系统与CTG连接这块通讯功能绑在一起了，我们如果能将CTG连接通讯功能从业务系统中分离出来，也就可以解决上述问题了。
结合对dao层和部署架构的分析，将CTG连接通讯功能从业务系统中分离出来，独立部署，将可以解决上述问题，优化部署架构。将CTG连接通讯功能独立部署后，需要考虑业务系统与CTG通讯功能之间使用什么协议通讯，一般情况下可以使用EJB或webservice，具体使用何种需要从性能、安全和成本上综合考虑，一般情况下如果对性能要求比较高会选择EJB，需要降低成本则会考虑webservice，安全性方面因为一般业务系统和CTG都会部署在同一网络中（或通过专线光纤等安全性非常高的方式连接的网络）所以两种方式相差不大。
改良后的系统部署架构图如下：

 在此系统部署架构中，将CTG通讯功能独立为CTG通讯组件，进行独立部署，业务系统需要知道CTG通讯组件的位置（比如使用EJB，则需要知道CTG接口的EJB的jndi）来调用CTG通讯组件提供的服务，但无需知道CTG连接参数，CTG对业务系统来讲透明；在CTG通讯组件中，需要配置CTG的连接参数与CTG，建立为所有业务系统共享的连接池。按改良后的系统部署架构，业务系统无需知道CTG位置，也无需配置CTG连接参数（不过需要配置CTG通讯组件的连接参数）；如果业务系统与CTG的连接通讯比较多，达到了性能瓶颈，则我们可以增加CTG通讯组件的部署数量来提升性能，其他都不需要变更（这里说明一下，如果给CTG通讯组件集群一个统一的VIP或域名，再在内部进行负载均衡，则CTG通讯组件的部署数量增加后，对其他部署单元完全透明；但如果没有给CTG通讯组件集群配置一个统一的VIP或域名，则需要修改业务系统中的CTG通讯组件连接参数）。