产品之惑--稳定性

产品名称：为方便交流给产品起一个名字：“UP”，全称Ugly Product。

产品定义：UP是一个服务性产品，集成不同厂家的硬件产品来供应用层使用，我们给硬件起名叫C，全称Card（一张嵌入式卡）

产品现状：

协议层

1.既然是集成不同厂家的硬件产品，就需要对同类硬件提取通用功能，并形成一个硬件接入规范,定义为CP（Card Protocol）

2.既然是一个服务性产品，肯定需要一套协议，所以定义一套产品协议，协议名字叫UPP（Ugly Product Protocol）

此时的UP变成了如下结构：

UPP-->CP-->Card

架构

3.既然是一个服务性产品，必定要考虑到高并发访问，因此将产品分为简单的两个模块（从最简单开始，这是从复杂的回归）

一个是对外提供服务的接口服务，我们起名叫Server

一个是向硬件下发消息的服务，我们起名叫Sender

此时的UP变成了如下结构：

UPP-->Server-->Sender-->CP-->Card
                                  -->CP-->Card

部署

4.既然是一个集成类产品，必定会遇到复杂的硬件环境，所以部署方案，要一对多方案，一个Server，多个Sender

此时的UP变成了如下结构：

UPP-->Server-->Sender-->CP-->Card
                                  -->CP-->Card
                   -->Sender-->CP-->Card
                                  -->CP-->Card

架构图

 

稳定性出现的地方

1.CP层，

超时，Sender到Card一个来回发生的周期太长，发生原因可能是网络延时大，也有可能是Card厂家提供的二次开发包出现的延迟（Sender与Card之间通信可能是串口，无线，CDMA，RJ45等，之间也可能出现防火墙）
异常，Sender同时对应的多个Card发送时，可能造成异常情况出现，导致下发失败，发生原因可能是资源竞争，可能是内部异常（最后迫不得已同一个Sender同步向多个Card发送，唯有增加Sender数量，减少Sender对应的Card来提高并发行，减少等待）

2.Sender层

多线程的下发，在一个Sender带几百个Card，每一个Card一个线程时，造成多线程带来的异常

讨论后的解决方案

1.对各个厂家的Card形成一个测试报告，功能性，时效性，多线程下稳定性，成功率，大数据包的发送时长，将测试报告提供给客户采购参照，对比不同厂家，形成一个长期合作伙伴。
2.在32位机下分多个Sender部署，（很多厂家的二次开发包不支持64位），32位系统一个进程最大2GB内存，一个线程栈1MB，所以大约可启动2000个线程，在c#里最好用线程池管理线程。