中间件设计指南

Posted 2021-05-25 SHAREit技术团队

  本期小编将为您带来中间件的基本概念，及适用场景，实现过程等内容。

中间件设计指南

一、什么是中间件

  所有介于实际应用和底层三方组件之间的可重用模块都可以叫中间件。

  简单的形式可能是一个SDK（客户端/后台），复杂的形式可能包含一些客户端SDK/一些后台SDK/若干长期运行的后台集群/一些使用及开发文档/管理页面等等。

中间件的好处：相对于底层组件(Redis/mysql这种)，中间件抽象层次更高，因此通过重用这些中间件，可以在更高层面构建应用，使得应用构建者的复杂度降低/涉及面减少，从而达到更高效率（更快/更好）。

       相对于具体的应用，中间件适用面更广，可以支撑较宽种类的应用构建，从而提高（多应用的）整体效率。

 

二、中间件与组件化/模块化的区别

这几个概念之间的界限有些模糊。

组件化/模块化比较象同义词，通常着眼于一个系统的内部，指把一个完整的系统分成若干高内聚低耦合的部件。

中间件往往涉及多个独立的完整系统，试图做到跨系统的更大范围内的重用部件。

各种使用广泛的开源组件，从广义上几乎都可以认为是中间件。

 

三、中间件的适用场景

1.更高效的支持多应用开发：重用中间件可以降低总成本，可以加快新应用的上线速度。

2.使得单一应用上下层可独立并行迭代：中间件可以使得应用层和中间件层耦合更松，从而使各自独立迭代的可能性加大。

四、不适合中间件的场景

  1.不关心上下层独立迭代的好处或好处太小。

  2.难以承担短期效率降低。

  3.没有多应用场景，无法获得重用收益。

 

五、开展中间件的时机

  1.项目过于复杂，上下层耦合过多，迭代效率变低，希望可以解耦并独立/并行迭代。

  2.计划开展同一大方向的多个具体应用的开发，希望能重用更多既有项目的成果。

 

六、如何找到可作为中间件的模块

 1.对于多个项目（包括需求范围内的尚未开始但大概率要开始的项目），找寻其公共(相似)部分。注意：支持哪些潜在项目必须是慎重的决策，不是理论上能支持项目都考虑进来(会造成过度设计)。

  2.对于单一复杂项目， 关注由多个不同团队(专职人员)负责的但因为耦合过多经常需要协调(开会/对齐/等待/同步)的模块。

 

七、中间件的三个层次

1.LIB：一些可重用代码，有确定性的API（不会随便改动）及使用文档，并遵循规范的版本升级策略(参见Maven组件的版本号策略)。

2.Server: 可(由使用者)独立部署的后台服务（安装包/二进制包/部署脚本），与之通信的SDK LIB（可能是客户端Lib或服务端Lib或都有)，完善的文档，遵循规范的版本升级策略。

    注：文档通常包括：安装配置文档(Installation Guide) / 运维管理文档(Administrator Guide) / 用户文档(User Guide) / 开发文档(Developer Guide)。

3.Service(SaaS): 以云服务形式提供服务，使用者无需关心运维，对外提供SDK/文档/管理监控配置后台。

     注：升级时需要长期兼容各种旧版本SDK的客户。

 

八、中间件的实现过程

1.粗设计：找到大体范围（参见“如何找到可作为中间件的模块”），评估性价比，决策是否继续。

2.细设计：确定具体的边界，即哪些逻辑归中间件内部，哪些归上层(中间件的客户/使用方)。

     注1：除了API(类/方法等)，还要关注部署时的配置，底层组件依赖。

     注2:  此过程更多关注中间件能提供(以及如何提供)什么服务给客户，不太关注中间件的内部实现细节（当然，要继续评估可行性/性能/性价比等方面）。

3.实现第一版，交付首批客户使用。

4.开始迭代，此后需要遵循规范的版本升级策略。

 

九、就中间件设计须知

1.要面向抽象后客户(或者叫泛化的客户) 设计。 

     中间件往往源自于某一个具体的项目，但设计时需要有意识的摆脱此项目的特殊视角，而要对此项目和将来要支持的其他项目进行抽象，然后针对这些抽象后的需求设计。

     注：因此，项目中各种部件的名称(项目名/组件名/域名/文件名/文档名/包名/类名等等）需要重新审视，从抽象客户的角度重新命名。

2.要阶段性重新思考此中间件的价值。

     中间件的定位/边界一开始是比较模糊的，所以在设计过程中发生的变化，有可能使得此中间件不再满足决策时的期望。

     因此在设计过程中，尤其是边界/设计方案发生变化较大的时候，要再次审视是继续下去还是放弃。

3.要慎重确定设计需求的范围。

     中间件的设计需求(需要满足什么将来的场景)一开始也是模糊的，在设计过程中，会遇到某个特定的需求对设计方案影响较大的情况，此时应该慎重讨论该特殊需求是否要被满足。

     如果轻率的增加这些可能的需求，中间件会变得越来越复杂（将来还不一定真的管用，因为对这些特殊需求的考虑其实并不全面）。

     某种程度上，确定合适的设计需求的范围，是中间件成功的关键。

4.要极为审慎的暴露信息给客户。

     客户每多了解一些“关于中间件”的信息，就可能产生针对这些信息的依赖，而这些依赖会给中间件的独立迭代制造障碍（哪怕客户犯错也没法置之不顾）。

     因此，对于暴露给客户的信息（一般主要通过接口/文档暴露给客户），要逐条审查“是否客户有必要知道”。

 

十、中间件的设计方法论及特点

   和一般的模块化/面向对象/设计模式等方法是类似的，无非抽象/封装/隐藏/分层等等手段。

   但中间件的场景有一些特殊之处：中间件的客户往往由另一个团队/组织(至少是另一拨工作技能不同的人员)。

   这通常意味着：双方的知识领域不同，代码不能共享，难以高频次的沟通(或沟通成本太高)。

   因此：

      1.文档的完备性/简单性要求比较高：从客户的背景知识出发，从客户的视角，遵从客户学习的方式，使用客户的语言，包含客户应该知晓的一切细节，排除客户无需知晓的一切细节。

      2.尽量减少和客户的人工交互。

 SHAREit技术团队