历数那些失败的项目(1)---M...

它虽然只是一个平台的众多业务组件中的一个，但是绝对是一个伟大的产品，不论是从业务需求上还是业务模型上。

介绍：

嵌入式，C/C++，平台产品，高并发，高稳定，高可靠，重启经历时间要求即刻

结局：
核心C代码从8W裁剪到3W。另外，由于组件本身承载的业务比较复杂，限定了它只适合特定的复杂业务，难于大量推广。

分析原因
1. 系统复杂
    各种重发，配置重发，维护重发，多线程操作，维护太多的消息队列，另外，对消息的处理没有分级，导致响应消息优先级低，没有及时清除队列，，继续重发，继续收到响应消息。。。
    锁操作粒度太细，增加了复杂度
    消息通道没有分开。业务数据，系统数据都是走同一路线（系统里边也有很多类型的数据），经常业务的数据流量将占满网卡。。。
    系统有太多的对象，用户又可以直接使用这些对象，导致删除后的操作会引起时段错误。
2. 系统的可显示性和可运维性做的不够
    本身设计非常不透明了，多队列，多线程，各种状态，N多对象。却没有增加一些渠道去查询这些信息，比如重发失败率，队列长度，对象特点，各种状态情况。
    每次需要了解都需要debug。。。经常要彻夜的帮忙定位问题。
3. 失败情况下的自检和自恢复不够
   需要手工的下达校验同步，但是对需要N年不重启尽量不干涉的系统来说，这个运维操作有点扰人。。。

收获：
1. 优化点其实就在你忽视的小细节里边的。
   用工具分析具体耗时点（那些被调用最多的函数），才进行相关优化
2. 解决上述问题...
3. 通过一个元数据描述和相关工具，来建立系统模型（各种文件，内存DB ORM，内存DB数据字典，元数据文件，配置恢复依赖文件，SQL，相关的类定义文件)