同步转异步+RPC的一个POS行业应用-业务模型介绍

最近在做一个挺有意思的POS消费项目，工作量不太大，但涉及的技术运用还挺有意思的。

可能有人奇怪，POS项目怎么用到JAVA语言了，先来简单介绍下这个项目背景：

改造前：收银机下单，POS机下单并刷卡支付

改造后：收银机跟POS连线，收银台直接下单并触发POS刷卡支付动作

这里就涉及一个关键问题，POS机只能单线程工作，就是一个时刻只能干一件事情，比如打印，刷卡，跟卡主机通讯，都必须是一件件做。这样就导致一个问题，POS机不能做SERVER，接受收银台发出的指令。于是乎，我们做了这样一个方案：做一个独立的SERVER，收银台和POS都连接SERVER，收银台发送指令给SERVER，然后SERVER再把指令转发给POS。流程图应该是这样子（懒得画图了：-P）：收银台<=>SERVER<=>POS。

这里就有一个很有意思的事情，假设现在顾客加完油，需要付款，整个工作流程是这样：

1、收银员在收银台录入订单，点击刷卡按钮

2、收银台向SERVER发送刷卡指令

3、SERVER把指令转发给POS（注意：POS开机后，处于就绪状态，保持跟SERVER一个长连接）

4、POS收到刷卡指令后，先断开跟POS连接，然后启动刷卡器执行刷卡动作

5、顾客刷卡后，POS重新连接上SERVER，把卡片信息返回给SERVER，SERVER再把信息返给收银台（注意：整个过程，收银台一直处于阻塞等待状态，等待返回卡片信息。这里就是有意思的地方，收银台工作在同步模式，POS工作在异步模式）

6、收银台收到卡片信息后，收银员点击支付按钮

7、然后收银台再次发送支付指令给SERVER，SERVER把指令转发给POS（此时，POS一直跟SERVER保持长连接），POS断开跟SERVER的连接，连接卡主机，把卡片信息和商品信息发送给卡主机进行支付，卡主机执行支付后，返回相应支付信息给POS，POS断开跟卡主机的连接，POS重新连接上SERVER，把支付完成信息发给SERVER，SERVER再把信息转发给收银台，然后POS启动打印机打印小票

8、整个支付过程，终于完成

大家看到了吧，POS一直都是一个时刻，只能做一件事，跟这个连接上了，断开后，再跟别人连接，断开后再打印，够忙乎的：）。

综合整个业务需求，这里就说说涉及到的一些技术要点吧：

1、技术选型

因为收银台是用JAVA语言开发，所以SERVER我们也采用了JAVA开发

2、SERVER通讯框架

NETTY，大家都应该比较熟悉。其实选择NETTY也不是什么特殊原因，用mina也行，主要是貌似现在很流行，用了它感觉马上变得高大上：）。不过因为NETTY API很多，实际使用中，会碰到很多问题需要注意，后期给我们带来不少麻烦。

这里还有一个要求：一个POS可以绑定多台收银机，也就是多台收银机公用一个POS。多台收银机，可以分别绑定不同POS。即一台收银机，对应一个POS。

3、同步转异步

从上面业务流程分析可知，收银机连上SERVER一直是同步在工作，一直等待着POS返回结果。而POS则是异步去一个个地处理事情，最后返回结果。要实现同步转异步，我使用了Condition和Lock。

4、收银台跟SERVER通讯方式

为了解耦收银台和SERVER，便于以后升级维护，SERVER会先封装好POS操作的API，收银台使用RPC进行调用。

5、RPC实现方式

原先打算采用RMI，因为都是局域网内部通讯，比较单一，不存在性能问题。结果甲方大石压死蟹，说RMI不好维护。。。。。。要用socket通讯（难道RMI不是基于SOCKET的？）。。。。。。最后只能无语地接受，用了他所谓的SOCKET通讯，自己去实现了RPC。

原先以为简单介绍下业务模型，结果发现说了那么多。。。。。。下一篇将会介绍核心技术实现细节，待续。。。