摘抄大牛的----“评估中间件的靠谱程度”

中间件是否靠谱，往往前期的调查是需要花时间、精力和人力成本去试水的。

如果有这个成本倒是随便试，可是从头来过换别的试试的事情，真的很不好。

看了一下大牛发的文章，很不错，摘抄一下。

1. 集成复杂度。好的中间件的特点是高度模块化（就是说不随便暴露无关的接口），最小侵入（普通的使用不需要你使用继承之类的强耦合关系），容 易集成到完全不同类型的代码库（比如尽可能地使用可移植代码而不是直接调用平台API），对外部环境有极少的假定，极力与其他系统的实现细节解耦。设计良 好的第三方库应尽可能地具有有效的默认行为，需要最小量的配置就可以工作起来。集成的代码接触面积应该最小化（这个接触面积越大越深入，评估周期和维护工 作量就会成倍增长）。如果一个中等水平的程序员做了两天还没让集成能初步跑起来，集成复杂度就值得怀疑了。（需要两天以上时间去集成的库，通常需要n个两 天去维护）
   （俺认为，配置繁杂、接口凌乱的库，往往意味着作者还没想清楚这个库应该被怎么用，应该用于什么场景，该遮的没遮住，不该露的到处走光，还是很容易识别的）
2. 内存管理。关心两点：a. 内存占用是否有不合理的开销 b.
   内存所有权和分配释放的职责是否清楚。理论上，库的作者应该是对库的内存使用情况最了解的人，他应该定制明确的分配和管理策略。当超出预算时，应该能明确
   地通知使用者，从而有机会去处理这类事件，而不是任由自己想分多少就分配多少。（更好的设计是把内存使用设计为可伸缩的，这样调用方有机会在运行时根据需
   要动态去指定内存用量）
   如果一个库不能独立管理一个独立堆或内存池，那至少也要把 alloc/free
   的接口开放出来。（这样至少可以接管一下，有机会决定转发到系统堆还是定制的堆，以及插入一些统计和调试性的代码）最糟糕的情况是，直接到处随意地
   new/delete。这样的话资源的消耗情况就很难控制了。
3. 对大量 I/O
   访问的处理。硬盘/光盘/网络都是有延迟的，所以访问的策略非常重要。一个第三方库永远不应该直接调用系统API去访问外部资源（如声音文件等），调用方
   应该有机会去捕获文件和数据的请求，提供定制的方案，从定制的数据源（如已经缓存到内存中的打包数据）读取。最灵活的方式是库完全不提供任何文件或流的读
   取，只访问给定的内存块，把资源如何获取完全交给调用方开发者处理。最糟糕的中间件，总是假定 POSIX
   文件系统在目标平台是有效的，直接依赖C语言运行时的 FILE 和 fopen() 之类的东东。
4. 日志系统。设计优良的库能够一致地处理运行时的消息，警告和错误，也很容易集成到你已有的日志系统。更好的设计给你一个选项能从高到低（从
   完全静默到最少量的关键错误到完全的调试信息）逐级开启各类信息。当开启静默的选项时，编译期就能把这些额外的调试输出字符串干掉，以避免额外的开销。当
   开启 ‘Noisy
   verbosity‘之类的选项时，系统的各项指标都不断地被输出，通过某段给定的输出，基本能够了解系统当时运行的上下文细节，一些不当的使用也能被及
   时捕获。
5. 错误处理，稳定性，性能开销，工具。通常评估一个技术，这些都是必须考察的指标，俺就不一一赘述了。
6. 客户支持，维护工作量，可移植性等等，这些属于延伸的需求，都很直观，也就略去不提。

摘抄大牛的----“评估中间件的靠谱程度”