原帖由 yg 于 2007-8-14 23:05 发表 http://bbs.chinaunix.net/images/common/back.gif
其实很蛇足，既增加了应用结构的复杂性，增加了出错的环节，也为系统引进了一个性能瓶颈，除了一个理由，真的没有存在的必要。特别是中小系统，要慎重考虑。
多一个接点,复杂程度大不只一倍,如果综合前置只做格式转换与通讯路由还好点,要是加入什么复杂的逻辑,难度就大了.
比如一个记帐交易,只在后台处理的话,帐务失败事务就回滚. 很简单.如果是通过中台过来,在中台有一些逻辑,后台只有帐务,那么就要考虑后台失败,中台又收不到回应的情况.还要考虑后台中台都成功,第三方又收不到回应的情况,要考虑后台成功,中台收不到回应的情况等等. 后台与中台的对帐又要考虑,中台和第三方的对帐也要考虑.
复杂到鬼一样.
刚入行我也不太懂前置的概念
正在看一个所谓的前置，感觉很不错，支持
一听到前置我就想吐了。
原帖由 lionheart_gw 于 2007-10-20 00:16 发表 http://bbs.chinaunix.net/images/common/back.gif
多一个接点,复杂程度大不只一倍,如果综合前置只做格式转换与通讯路由还好点,要是加入什么复杂的逻辑,难度就大了.
比如一个记帐交易,只在后台处理的话,帐务失败事务就回滚. 很简单.如果是通过中台过来,在中 ...
其实这里可以考虑一个后台与前置系统的一个冲正处理，我以前就做过所谓中台有逻辑的处理，并不是很复杂。理清楚了很easy，
[ 本帖最后由 flf21 于 2007-11-22 11:50 编辑 ]
原帖由 lionheart_gw 于 2007-10-20 00:16 发表 http://bbs.chinaunix.net/images/common/back.gif
多一个接点,复杂程度大不只一倍,如果综合前置只做格式转换与通讯路由还好点,要是加入什么复杂的逻辑,难度就大了.
比如一个记帐交易,只在后台处理的话,帐务失败事务就回滚. 很简单.如果是通过中台过来,在中 ...
既然要处理业务逻辑，考虑是要全面，综合前置也需要记流水的，涉及第三方支付的交易很多需要对账。综合前置的主要功能是通讯，加解密，格式转换，交易分发，监控管理。前置作为一个后台主机的缓冲，应该分担一部分业务逻辑。而且新增一个业务，后台只提供标准交易，改动越少越好。关于性能方面，能否考虑负载均衡，一个模块专门做通讯，一个集群服务提供业务逻辑的实现。
前置，简单的理解就是通信模块，收发数据。
有自己的规约。
想不顶的不大可能了.呵呵^^^^^^^^^
应该画个具体的拓扑图，讨论起来更明了。
我就弄不明白了，一说到前置就要把交换功能和业务逻辑功能混在一起？！
现在都什么时代了？小农经济不提倡了！该分工细作的就该分工细作！
有一个问题是大家都忘记或故意不正面考虑的，那就是前置的定位。弄个前置的目的是为了啥啊？是为了做业务？还是为了做交换？OK，做业务和做交换两者都是需求，那么，做业务和做交换是一码事么？是不是非弄一个平台来实现？
回头来看看所谓综合前置的历史，确实是从最初的林林总总小前置（这里面有应对交换要求的，也有应对业务逻辑要求的）发展到集业务和交换一体化的，平台级的所谓综合的前置，但是那个时期对于业务逻辑的要求相对简单，而实际上，复杂业务逻辑的应用到目前为止，也没有哪家银行真正的做到全部在所谓综合前置上开发运行。
想说的很多，但懒的写了。有点郁闷。。。。