VICA全称VAT Invoice Client Platform（增值税发票客户端平台），顾名思义就是公司增值税发票业务相关处理的客户端集成平台。在VICA出现之前，公司发票开具的技术主要是依赖于ActiveX控件，因为在航信或者百旺的单机开票中需要浏览器与本地开票的COM组件交互，这给我们带来了一系列的限制：必须使用IE浏览器；必须开放满足ActiveX在IE上加载的权限；开票的业务必须发生在启用IE的开票机上。这些限制严重的阻碍了公司业务的深耕与推广，我们面临的需求很明确：1.解耦IE浏览器，不再限制对浏览器的使用； 2：部署实施简化，对客户端权限设置大幅降低；3：解耦开票机，支持分布式共享开票，以上就是研发VICA的初始需求。在后续的发展过程中，我们发现公司不少产品都需要对接VICA并提出了各自的需求，因为VICA在设计上的一个额外重心：必须支持定制化。
现在让我们来看一看VICA的单机版物理架构图1：
其中右侧的ACME和简税就是公司的两大业务产品线，左侧部分就是我们今天重点说的VICA。
VICA由客户端和服务器组成，客户端采用.Net的Winform技术构建，服务器端又由三部分组成：1.Socket服务（Netty）; 2.轻量级Http服务（Vert.x）;3 更新服务（Spring Boot）
通常Socket服务与Http服务在单服务器模式下集成在一个进程中，更新服务则挂在独立的进程中。调用流程：业务产品线调用VICA开放的http发票接口，http服务将接收到的请求转交给Socket服务并在其中封装成命令推送至指定的客户端，客户端接受并处理命令，最后将处理结果通过回调的方式返回给各个业务产品线。
为了满足互联网产品线的需求，我们还设计了分布式版本的物理架构图2：
我们在单机版的物理架构图中扩展了4个设备节点：1.socket负载均衡，应对大量客户端连接的压力；2. Web负载均衡，应对外部App的高并发压力； 3. 服务总线与Redis缓存服务，用于解耦socket服务和web服务，确保职责范围内的压力不直接向后传递。这种架构较好的满足了高并发带来的压力，解决了互联网产品线的需求，但是增加了部署的复杂度，不适用于一般的企业项目的部署。图1和图2解决了各个产品线的不同调用需求，但是部署逻辑上是不一致的，这为开发带来了额外的工作量和非一致性框架，在一个Team里这个问题需要尽可能的避免，我们下一步的工作就是为单机版和分布式版VICA提供框架一致性编程。
了解完VICA在物理架构上的大概情况后，我们把介绍重点转向客户端，客户端上真正实现了对发票业务的支持，通过Winform封装组件DLL，各个产品线不用再依赖于ActiveX的开票方式，极大的简化了用户环境上的权限设置，并且做到了业务系统与开票系统分布式办公的可能。VICA架构图3：
作为一个客户端平台，VICA基于平台+插件的机制做了分层处理，在平台层上专注于客户端程序的通信与协议解析，插件加载，更新服务，队列服务等基础功能的实现并向上层开放编程SDK，在插件层则承载了具体功能的实现；整个框架充分使用依赖倒置原则，在平台上提供了大量的依赖注入点，插件与平台解耦，通过侵入式的向平台注入多态实现来完成各个产品线在VICA上的功能实现，真正做到即插即用，一致性编程，发布时确认而非编译时确认版本等优点。在命令处理上，客户端提供了三层队列来分割一次命令的处理：请求队列，响应队列，尾队列。请求队列负责缓存用户请求，并在入队的前后完成对命令有效性，排队约束，开票防重复等工作；响应队列则负责缓存用户待回调的命令结果，提供了单线程会回调和多线程回调的机制；尾队列主要缓存回调失败的结果并根据一定的策略进行定时回调，确保将命令结果务必返回给各个业务产品线。
未完待续。。。