最后是网关层，面向接入银行渠道和接入合作大商户：第1层是报文组装解析层，第2层是适配器层，第3层是路由引擎；由图可见，每家银行的公用逻辑相同，可以通过设计模式封装。不同的是输入参数的获取策略以及输出参数的不同阐释策略。具体实践时代码结构上可以用设计模式来封装；实现代码上每个银行的输入报文的不同，可以用velocity模板来做。在返回报文时，每个银行的错误码和异常处理机制也不一样，可以通过groovy脚本来解析，这样对于接入新银行和商户不用做系统发布，直接配置即可，实现插件化可配置；2015年前公司一个月接一家银行，2016年后可以实现一个月接几十家。
基于这个理念，我们做了一个可视化作战指挥系统。包括三大部分： 研发的可视化： 聚焦统一目标下的交付全链路、全资源可视化；统一目标是指公司的战略目标，从上图可见，战略目标KPI一定极简指标，要定北极星指标，一般我们会定三项，战略目标分解到事业部，事业部分解到研发中心对应具体需求，而需求的整个研发周期已经可视化了，可以清楚知道每一个需求、每天做的事情是不是帮助整个集团在完成战略目标。
运行的可视化：系统上线之后可以看到从机房，到整个调用链，到每个架构域，再到每个具体的系统；以至系统里面的每个模块，都能清楚他们的状态。
管控的可视化： 组件自治，资源弹性调度；每逢大促尤其是洪峰时候，需要执行应急预案，我们就需要知道，执行应急预案之后影响的用户场景，以及各个硬件执行过程当中的操作的步骤。
可视化作战系统架构设计，这里面除了平时的一些常用的技术设计之外，还有三点核心的设计思想：第1点，对研发来说，体现在可视化整个研发生命周期，但是起点与平常不同，平常的起点可能就是一个需求，但这个的起点是战略。第2点，运行时关注不稳定性的因素，去主动分析、依赖分析和变更感知。分析变更感知的前提，是需要对每个系统做SLA；
第3点，为了进行平滑的管控，需要做几个工作：制定应急预案后进行线下，线上的演练，除了线下测试环境的演练外，生产环境也需要实际的演练，比如划拨一定量的生产用户，调度一定量的业务场景，也会自动注入一些故障，尽量让演练流量的结构构成接近真实流量，以保证演练的真实性。如果故障没有经过演练，真实发生是不可控的；故障能否快速恢复，能否自愈，对用户来说是不是感到平滑。
