erlang的学习也算是告一段落了，要开始实战应用了。
当初学erlang的目的就是用来做DB API的。 可接受 HTTP, TCP, UDP的请求。
根据的erlang的特性，构思了一个初步的架构方案。
如下图所示：
、
其中 Communicator 用来处理各种请求，根据业务逻辑决定 开放 HTTP，TCP，UDP这其中的哪种或者哪几种通信方式。
Communicator也负责处理协议的编码、解码。
其中 Holder 是松耦合的独立进程，用于处理具体的业务逻辑。 可根据使用情况，对某些Holder进行合并处理。 Holder之间也可以通过 IPC或者RPC的方式进行通信，通信协议遵循 erlang OTP默认规范。（gen_server）。
至于Mod1..ModN处理数据的读取，查询。所有Mod都针对单表进行操作，若需要进行联合查询，放在Holder中处理。
数据存储方式：ETS|DETS + MySQL。 目前的存储方式暂定如此。
===================================================
介绍完毕，现在记录下自己为什么这么设计
===================================================
首先，erlang的RPC,IPC是一大特点，而且创建进程开销极小。利用这一特点，可以把单表的存储操作模块看作是 流水线上的一个工人，也就是Mod。 而Holder是各条流水线，一条流水线上可以只有1个Mod进行操作，也可以多个Mod合作操作。 流水线之间也可以有协作关系。
Communicator 不关心具体的业务逻辑操作，只会根据定义的 消息ID 和 Holder中函数的映射，调用Holder中的函数进行业务逻辑处理。
这样设计的优点是所有的业务逻辑够分散，绝对的松耦合，缺点是涉及到多个hodler之间的无序业务逻辑需要在 业务逻辑拆分上进行一定的处理。
总而言之，这个架构只是个初步构想，而且想要应用这个架构达到想要的性能和开发便捷性，需要在业务逻辑的拆分上具备一定的行业经验。 不适合初学者。