说是“完美”，其实是吹牛了；
实际一点是：性价比；

每次架构一个系统，就如老衲修炼那样，总要静心，心如止水般的修炼数周，甚至数月；
中间的过程如蝴蝶破茧一样的痛苦纠结；

要不要架构，yes or no ?
不架构：类似于手工制作，虽然可以做的很精细，但是成本太高，质量的好坏和工匠的手艺关系很大；
   架构： 前期有投入，有涅槃重生的一个过程；这是一个风险；而且未必能够架构的合适；

举个例子，假如你是一个做钟表的精湛工匠，一个机械手表需要1200多道工序，每一个步骤都是你亲自认真打磨，自然会造出一块好表；
但是这里有两个问题：
    1.你造这块表非常辛苦；
    2.因为像你这样有精湛水平的人太少，普通人肯定帮不上忙，就算找到跟你旗鼓相当的人帮忙，那个人的要价可能也不菲；所以只能你一个人苦逼的完成所有环节；

所以你就想办法实现把你的一手绝学转换出一种机械化生成的方式；
好处是：1.简化自己的劳动；2.可以找普通的廉价人来帮你干活；
当然，你要构思把那些费劲的工序转换成机械化结构代替，这可能未必能实现的很好；可能误差高于手工；
但是，不能因为这些可能性就因噎废食；
批量生产 和 使用廉价人员（技能要求不强）是必然的趋势；

言归正传：
         对于一个好的设备调度系统，我觉得有几点要做好；

         1.好的通讯机制
          最好使用设备自身的原生协议进行通讯；
           目前大部分设备和上位的通讯的本质都是基于TCP/IP 的socket通讯；但是有些设备厂商不开放协议(但是可以通过一些通讯嗅觉工具监测具体的通讯内容)；
           当时只能通过OPC这样的通用接口方式去处理，也针对OPC的方式做了两版通讯架构；
           但是追求本质的想法，还是有点不能释怀，有空再尝试一下吧，一直找不到志同道合者；绕过OPC这样的”中介“机构，成本和性能上都会有所提高的；

           有个以前的同事一直研究各种数据库的内部结构原理，就像研究猪肉的吃法一样，炖的、炸的，烧的，烤的；各种方式都打通了；
           我们项目中，数据库坏了，往往只能找最近的备份文件恢；他能直接恢复；你不慎删除了，修改了数据，想恢复，他也能；
           你直接把数据库物理文件删除了，他也能通过碎片技术还原；只要不是粉碎文件，他都能修复，反正数据怎么坏了，都能修复；
           这就是认识事物本质的好处；当然很多本质的知识是网上没有的，要有痛苦的摸索过程；

         2. 灵活的调度架构：
               早期项目”硬“开发，想在回想就是hell(地狱)，很痛苦，很不小心写出自己发现不了的漏洞，
              忐忑不安的投入使用，开始往往使用源程序编译成debug的调试模式运行；
                而且谁也帮不了你；后期开始慢慢架构；主要分两块：
                       1.通讯配置；
                       2.事件配置；
                细节不说了，反正用到了很多反射，hash运算，脚本解析之类的东西；就是在一直的琢磨着；
                1993年，英国数学家怀尔斯解决了300多年前的费马大定理的时候，就感叹：每次解决了一个问题后，就要走到另一个黑屋子，一切未知，
                摸索明白后，又要去下一个黑屋子；   总之是一个有点痛苦的过程；
              
          3.  强大的监控：
                 很多人，往往在乎调度的稳定性；有些”洁癖“的人，还计较调度的实时性；
                 但是对于小白客户来说，他最希望看到的是 有个拟人化的监控，能够掌控各种变化状态和异常，并能遥控做一些方便的人工干预；
                 客户对你系统的好坏认识，往往就是你有没有一个好的监控来判断的；就像看见美女大家都会有个好的第一印象；
                  开始做的时候，一下子没弄出特别好的架构，虽然做出来了，但是”手工“成分太多；这就非常消耗成本；
                 就如宋太祖一开始没狠心把燕云十六州拿下，导致后患无穷；
                 所以，痛定思痛，得实现一个先让自己满意的监控架构；
                    
                  每个监控元素都有以下几个属性：
                     text: 显示的文本；比如设备号，托盘号，去向，变化时间等；
                     hint:  鼠标停靠提醒；比如订单，客户，sku，数量等；
                     color: 不同颜色的显示条件；比如，托盘号是99打头的显示蓝色；去向等于当前位置的显示青色；有异常的显示红色；
                     flash： 闪烁条件； 比如：堆垛机正在调度，设备有严重的异常；
                     event: 事件配置，比如：可以修改条码或去向；可以分析当前条码最近日志和库存等；


                 这些属性如何做成合适的配置模式展现出来，也是一个有点痛苦的过程；
                 
                但是，既然有了想法，胜利的曙光也不远了；