应用于小型银行的核心体系，主要由前台和后台以及若干小前置组成，前台发起交易给后台，后台处理后返回，如果需要外联，后台联动请求给小前置出去。这种架构对于不大于市级规模的银行使用已经足够了，一旦小型银行规模成长为在全国拥有多家分行，比如拥有跨地域开设分行的城市商业银行，各地的业务差异性复杂性给系统架构升级带来了必要性。
       
        适用于第二类规模的核心架构为“前台（以及ATM、网银等）-渠道前置-大前置-后台”，前台发起的交易以及其它渠道诸如网银交易等，由渠道前置统一接入大前置，并分担渠道压力，大前置负责统一调度核心系统交易，同时渠道前置还负责与外联的渠道接入。因为有了大前置，所有周围系统只需要跟大前置做接口，包括通讯接口和报文接口，简化了渠道和后台的技术接口，但也给大前置带来了性能压力，一般采用集群方式。
       
        全国性银行系统架构主要体现在行政区域的前置分级和后台的业务系统化上，一般采用“前台（以及ATM、网银等）-市级渠道前置-省级渠道前置（-地方性业务系统）-综合大前置-各个业务系统”，省市级渠道前置除了分担庞大的交易连接压力外，还担任了级联架构中地方独有业务的大前置角色，对于它来说，地方性业务系统就是本级的后台，综合大前置包容了大前置的交易统一调度功能，还把后台的一些公共的业务逻辑处理移过来，一方面以减少与后台的交互环节，另一方面也达到基础数据统一管理，与前一架构相比较，变化最大的是后台拆分成各个业务系统，比如可以按对公对私拆，也可以按业务拆，还有一个明显的特点是会计核算系统从传统意义后台中分离出来成为一个独立的系统。

        
        系统架构中各部分的技术基础设计原则推荐：
       
        前台作为一个交易发起渠道，是间接面向客户直接面向柜员的系统，因此系统要求主要在于数据域表单的展示和控制，展示主要是静态页面的布局表达，比如某某交易中涉及的业务要素集合布局和显示布局，控制主要是页面中数据域与数据域之间的动态联动关系，比如某某数据域在在哪些情况下是可显示不可用的，某某数据域接收到某某事件后弹出选择窗口。
        一种比较灵活的设计是采用一种通用标记语言（比如XML）来描述静态页面的数据域集合和结构布局，编写显示引擎来输出为最终的页面，这种做法的基本思想是数据和显示分离（一个类似的例子是XML和XLST代替HTML），这在前台开发中大量的页面重构活动中能获得高效的适应性。选用一种脚本语言或者前台平台宿主语言的回调机制来实现页面数据域的控制，如果选用脚本语言，那么此语言必须足够的灵活以能实现各种各样的计算要求，还要设计一种与前台平台宿主环境的数据交换机制。一个页面（可能包含一个或多个交易表单），可能触发若干个数据域控制联动交易，以及最后的最终提交交易。
        简单规模的技术实现可以是字符终端，优势在于简单干净高效；高端实现可以是基于浏览器或者基于C/S的图形界面，优势在于界面美观、便于图片和表单界面同时显示，这在引入凭证影印系统后显得格外重要。
       
        渠道前置主要实现了渠道通讯接入和渠道报文转换，在前述第三种系统架构中还扮演了省市级大前置的角色，面对各种各样的通讯方式和报文格式，系统要求主要在于灵活性和扩展性。
        大陆银行以及各大外联单位的通讯方式主要是TCP、IBM MQ、CICS、Tuxedo、SNA等，前两种在实际应用中占90%以上，TCP主要是因为简单，操作系统直接提供无需安装第三方软件，IBM MQ不说了，你们懂得。报文格式主要是固定长度格式、分隔符格式、8583格式、XML格式等，固定长度格式的优点在于简单，打包解包速度快，缺点是可能会浪费存储空间，一般用于重视处理效率的场合；分隔符格式比较节约存储空间，但是打包解包速度稍慢于固定长度格式，还要注意双字节引起的解包错位问题，而且还要考虑分隔符转义，一般用于字符取值空间比较单纯，数据域长度差异性比较大的场合，人行一代大小额采用的TAG域格式报文是分隔符格式的变种；8583格式是银联卡交易报文接口标准，几乎遍布所有卡交易中，其改造后也可以作为通用交易报文格式使用，其实就是数据字典和固定长度格式结合体；XML格式在目前使用越来越多，特别是在人行项目和财政项目中，其具有自描述性、人可读性，能附带前面几种报文格式所不能包含的大量完备信息，它的缺点是打包解包速度慢，需要安装第三方解析器（比如libxml2、MS XML），因为格式相对复杂而带来的编码难度和繁复度，适用于对效率和稳定性相对要求不高的系统中。
        此外，在上述列举的通讯方式和报文格式外还有很多随时会作为外联接口被要求在渠道前置中支持，所以模块化和可扩展性对于前置系统设计尤为重要。一种普遍采用的思路是把各种各样的通讯细节和报文转换封装成组件，设计统一的数据流和控制流接口，通过动态语言的动态机制或者静态语言的动态链接库动态挂接和卸载，这也是国内各大前置开发商的千篇一律的宣传口号，但是基于该思想最终能实现到怎样层次的灵活性和扩展性就是千姿百态了，这里不便评价。这里还涉及到开发抽象性，即编码和配置的分离（这在通讯组件使用时不是很明显，因为同一种通讯方式的参数大同小异），主要体现在报文转换中，同一种报文格式可以衍生出很多不同布局的具体报文规范，比如一种XML打包解包组件支持的XML层数，支持可重复明细，支持在可选择子树，支持内外XML报文嵌套，支持解析中带文件名的XML树叶的额外处理，支持对XML报文做的签名值再作为XML树叶挂入XML报文中等等，如果XML报文转换组件不够强大灵活到可以支持各类怪异的报文规范，那么在自己能实现的灵活性层次上如何提供外部接口，以最终实现怪异的报文规范，这是个现实问题。有多少开发商能充分考虑客户体验，踏踏实实的投入技术资源实现高层次的灵活性和扩展性，而不是所谓的客户现场定制＝完整的推倒重写在产品宣传中无比强大的组件，这也是个现实问题。
       
        前置系统中一个很重要的功能——特别是在大前置和综合前置中——交易调度，或者叫做交易路由。交易路由的主要功能是根据交易码及其它信息判断交易下一个请求后台或者交易已经完成（成功或者失败），返回交易发起渠道。交易路由控制有很多种实现，最硬的是通过编码实现，也有通过配置完成。交易路由控制中应尽量少掺入业务逻辑处理，简洁、可复用的路由配置是良好的设计开端。
       
        大前置或综合前置作为交易调度中心，应该拥有内部报文格式，与渠道和后台之间只要实现外部报文和内部报文之间的转换就可以了，避免了多种报文对多种报文转换的组合复杂度。当然单纯一进一出的小前置为了简化设计可以不采用内部报文。内部报文格式决定了报文转换组件的接口和数据结构的表达丰富程度，一种简单的设计是创建基于某类业务的小数据字典生成的固定长度格式报文，另一种炫耀的设计的是XML格式。
       
        前置内部数据交换方式很能衡量前置规模，反过来前置规模决定了内部数据交换方式。一般的小前置结构简单，交易量小，采用unix消息队列可以有效简单的流水式传递各进程之间的数据块，当结构变得复杂，交易量较大的场合，应该采用类似IBM MQ之类的消息中间件，后者还有一个显著的好处，它是跨物理机器的，很容易在其上部署集群，这在大前置或综合前置设计中尤为重要。
       
        说到前置就不得不说核心系统数据交换报文格式，在严肃的负载重的环境中，个人还是推荐固定长度格式，因为固定长度格式打包解包效率高、与数据取值空间无关（相反的例子是分隔符格式需要的转义问题）、随机访问数据域定位速度快、设计实现简单，但这种格式主要为高性能系统而选用，便于程序处理，对人不是很友好，所以在一般的系统环境中，可以尝试着采用XML格式，XML格式最大的优点就是自描述性，面向人比较友好，其它都可以作为固定长度格式的反面评价，而且还与具体的第三方解析库相关联。
       
        后台业务系统其实就是一个应用服务器，它接收前置的转发请求，调用业务处理逻辑，最后把处理结果返回给前置。因此可以把后台大致的分为两层：平台层（通讯服务层、报文转换层）和应用层（交易管理层、交易处理层）。
       
        平台层实现的是一个应用服务器框架，包括进程管理、通讯接入、报文调制、与应用层接口、系统错误处理等。在进程框架中，平台应该是一旦成熟很少去编译它，应用通过组件方式动态挂接使用。一种最偷懒的简单设计是完全依靠交易中间件来充当应用服务器。稍稍复杂的设计是守护进程在TCP端口上侦听，一旦有交易请求进来，创建一个子进程负责接待处理，子进程装载覆盖应用代码段映像，把进程控制权交给外部可执行程序，接收通讯报文，转换报文为内部数据结构，业务逻辑处理，转换为通讯报文，返回响应给交易请求端。这种设计简单有效，其实就是cgi的翻版，缺点在于系统fork负载大，不适合于高交易流量系统。更大规模的后台平台设计首先应该更改的是采用长进程组成的进程池，那么覆盖代码段映像也不适用了，改成动态链接库，在系统模型设计上，Apache的Leader-Follow值得借鉴。再大规模肯定要考虑集群，这又要牵涉到数据交换方式，通讯中间件是一个合适的选择方向，平台层和应用层处在不同服务器组内。最大规模的都是大机的世界了，比如AS400，大机里的进程模型等和小机差异很大，只有那个世界的技术人员才有资格谈论这个话题了。
       
        应用层实现的是与平台层接口、数据库事务管理、交易管理和业务处理逻辑等。数据库事务区域大致分为交易流水登记、交易检查、登记簿处理、账务处理、交易流水更新等五大主要事务，交易管理除了管理以上数据库事务外，还兼有公共数据处理、原子交易拆分及内部数据交换等。一种简单的交易管理框架是根据原交易码和预配置的原子交易拆分规则预置子交易执行序列，然后依次执行之，执行前后需要进行原交易报文和子交易报文的数据映射，以期实现子交易的隔离性和独立性。子交易拆分涉及到具体银行的业务逻辑复杂度和架构师的喜好，水很深，不便卖弄。
       
        应用层中的内部数据结构是一个咬牙切齿的话题，在c世界里用的最多的是结构体，但是c的静态编译特性决定了一旦调整结构就要重新编译而带来的一系列问题，特别忘记漏更新了会带来难以预料的后果，但这并不是不能解决，采用抽象数据容器可以使编译器无法染指应用中的数据布局，一种简单的实现是创建一个指针链表，为了提高效率也可以是指针数组，数据容器是个好东西，它所带来的缺点差不多只有两个：实现复杂度、使用复杂度。可能还有其它的方案，但都是可用的，最终使用权在架构师手中，无论他选择哪个方案都不用担心招致反驳。
        应用层中的控制流模型也是一个百争不厌的话题，c世界里，务实主义者完全靠函数调用来实现控制流，这样显得简单直接，先进性主义者喜欢搬弄诸如函数数组之类的高级控制流结构，这样便于实现配置，但归根结底，好用就行。
       
        银行业务分类也是具体结合本银行而各有各的传统分法。粗者直接储蓄、会计了事，细者按业务系统满满的塞满整个屏幕，根据管理学中级联管理层次横向不宜过多不宜过少的原则，一种推荐的分法分会计、存款、贷款、卡、支付结算、代理委托、国际业务。会计从其它业务中剥离出来组成独立的分类乃至账务系统的好处是其它分类只需管好自己的登记簿和流水表就行了。

        金融数据字典是每个银行势在必行的任务，这在整理本行业务结构、技术规范、教育培训等都具有非同寻常的意义。数据字典最重要的信息结构是分类树、中英文对照和名词解释、数据域格式和长度、枚举空间。曾经有公司有雄心发布自己的金融数据字典，最后却落得孤芳自赏，其原因有很多，比如缺乏权威机构的支持，金融数据字典带有浓厚的银行自身业务特色，很难有一个统一的数据字典能放整个行业皆准。不过花点资源，整理出本行数据字典还是很有好处的。

        是否有日志输出意识是一个软件开发人员的成熟指标，是否拥有完备的日志系统是衡量银行核心系统乃至一个软件系统容错性的有力标竿。网上有很多功能丰富的第三方日志函数库，在c世界里，比较有名的有log4c，c++世界的log4cxx、log4cpp等，它们都是参照或借鉴log4j设计。log4c已经停止开发多年，最多只能算是一个半成品，而且谣传可能有内存泄漏嫌疑。
        日志系统作为软件系统的基础构件，稳定性要求非常高，怎样能保证高稳定性？简洁设计。与其引入复杂臃肿的第三方日志系统，还不如多花点资源根据本行技术需求好好开发一套日志系统。小规模日志系统可以是“打开文件－写文件－关闭文件”，简单就是最好的，稍稍复杂的可以创建日志句柄引用不同的日志分类（文件），再加入日志等级等，再复杂的可以通过远程守护实现日志异地落地的日志服务器、日志文件转档等。日志系统的设计一定要控制规模，需求很容易变得很复杂臃肿，只选择最必要的，并考虑一些扩展性，即可。
        监控体系有两部分构成，一是交易简约信息的实时展示，二是系统资源监控。前者可以借日志系统异步发送交易信息实现，并保证一旦出现问题不会影响交易本身。后者一些重要的系统资源有：CPU、内存、磁盘、数据库等，应用资源有进程、IPC、中间件、网络等。

        c#里有一个工具可以读入XML文件，自动生成该XML树类，通过该类可以方便的解析、Dump、存取该XML树数据，这就是自动化数据绑定工具。
        使用自动化数据绑定工具是现代化开发中的一个最重要的特征之一，开发初衷是让程序生成程序，让开发人员从一些机械的重复性高的工作中解脱出来。自动化数据绑定工具在很多领域都有经典的应用，比如固定格式报文数据绑定工具根据定义文件，自动生成宿主语言数据结构和打包解包程序库，使开发人员不需要关心固定长度格式的底层处理，这在报文设计、通讯协议设计等很多场合大大抽象了开发层次、减轻了开发人员工作量