中间件选型标准和流程

2018年10月19日系统架构和设计

中间件选型

一、选型流程

对于重大组件、中间件的选型，首先要明确短期、中长期的需求，根据需求，列出一些重点考虑的需求特性，根据这些特性，列出一些测试用例，在选型时，用这些测试用例对入围产品进行测试，根据测试结果来评判各个产品的优劣以及与需求的匹配程度。（对应下面的第3、4项）

1 初步收集和整理需求，可以参考比较主流的方案和中间件的功能

------>相关资料------->

2 召集领导、技术骨干、架构师等，讨论需求和使用中间件的必要性

------> (1) 需要自研-------> <自研流程......>

------> (2) 选用中间件-------> 由领导发起中间件选型任务（主要由基础技术平台来具体负责）

3 （选型负责人）广泛调研和收集符合需求的中间件，发布初步《调研报告》，召开讨论会

-----> (1) 不符合要求，需要自研-------> <自研流程......>

-----> (2) 决定选出2到4款拿来做最终的对比测试

4 发起对比测试（根据具体情况进行，可能涉及到性能、稳定性、安全性等各个方面，如果测试复杂，需要性能测试团队参与）

5 编写中立的《选型报告》和《测试结论》，完成后，召开讨论和评审会议，决定要用哪一款中间件

-----> (1) 所有备选的中间件，都不完全满足需求，需要二次开发或者调整需求 -------> <领导做决定......>

-----> (2) 决定选择某一个款中间件 ------->

6 由基础技术平台负责该中间件的部署或二次开发 - the end

注意，1、对于第一点 - “需求的提出和收集”，可以由任何方面发起，包括研发组、架构组、基础技术组等。

2、选型负责人，主要由基础技术平台来具体负责，一般来说，必须是高级工程师以上，有丰富经验的一线架构师来负责，《调研报告》、《选型报告》、《测试结论》等文档，必须是专业的，能说服人的，没有这个效果就得重写！

二、重大版本更新流程

1 由版本更新的发起方（例如基础技术平台，或者业务需求方也可以提出更新）来确定更新内容，召开讨论会议，收集反馈意见并决定是否有升级的必要

--------> (1) 决定暂不升级

--------> (2) 决定升级

2 中间的负责人，准备好新版本（可能还包括二次开发），新版本准备好后，发起测试，通过测试后，发布测试结论；

3 制定升级计划（如有必要，可以召集使用方开会确定升级计划），并准备升级手册和资料；

4 由基础技术平台负责该中间件的新版本部署 - the end

三、选型标准

列表和举例如下：

标准	说明	SpringMVC	ZolltyMVC
满足需求	能否满足功能需求及技术指标（比如性能要求）（满足眼前的需求）；能否适应未来的发展，满足未来的需求（适可而止，不一定是越多越好）。	很多，很强，以至于一般都用不完也很难一一列举完。（10分）	涵盖MVC的基本功能，包括Bean管理/依赖注入、RequestMapping、Restful、拦截器、模型驱动和多视图等。（6分）
成熟度	产品正式版本发布时间和次数；产品是否被长期、广泛的在生产环境使用；是否经过业界各种复杂场景及苛刻要求的验证；在互联网上的资料是否丰富。	开源10多年；发布的版本数以百计；被全世界广泛使用、占有率绝对第一；网上文档和资料非常丰富；（10分）	发布已有5年，有十余个版本，使用案例很少，仅仅有3、5个小项目在用，市场检验不足；文档资料很少。（3分）
可靠性	产品bug数量多少；正式版本是否被发现有严重bug；是否有安全漏洞和隐患；产品是否经过测试和质量、安全上的检测；是否具备容灾能力（比如支持集群、副本等）；	稳定可靠，十几年来，被无数公司使用，很少发现严重缺陷和不稳定的情况。（10分）	简单使用来看，还算稳定可靠，但是没有经过太多场景的检验。（6分）
产品活力	是否开源；如果开源，参与开发的人有多少，是否深入，是否活跃；用户和各种参与者人数多少，是否活跃； bug修复频率，版本发布的频率和稳定性，是否有过停止更新，或者经常发布延期等情况。	代码和资料完全开源；已形成广大的社区，拥有大量的维护者和开发者；近十几年，一直再不停的维护更新，每年都会有很多个版本发布；（10分）	代码和资料完全开源；只有一个维护和开发者，且很少有人关注和互动；近几年来更新频率很低，大概1年左右发布一次版本。（3分）
业界案例	业界的主流方案是什么？最先进的方案又是什么？业界的流行趋势是什么？业界（国内、外）知名公司是怎么做的，他们的方案是什么？
口碑和行业认可度	有多少公司也采用了这种产品、技术或方案，效果和口碑如何？
服务支持能力	开源还是商业？能否得到官方及时有力的支持？
可维护性	是否容易安装/升级/更新；是否容易日常维护；是否有安装和维护等操作说明文档；是否支持监控；是否支持灰度发布、平滑升级。
可测试性	对其本身或相关的功能，是否容易测试，是否容易定位问题；是否支持自动化测试。
性能效率	响应时间、吞吐量、并发、资源利用率等，是否在同类产品中胜出；是否支持通过水平扩展、负载均衡等方式来提高性能。	由于本身比较复杂，性能效率不算高，但是从各大公司的使用来看，能满足99.99%的场景。	简单轻量，对比来看，各方面的性能效率很高。
安全性	功能上是否有各种安全策略和保障（比如支持认证、加密等，支持防SQL注入、重放攻击等）是否暴露出有安全漏洞或隐患是否经过安全上的检测；	被广泛使用，几乎没有安全方面的漏洞和隐患。	简单使用来看，还算安全，但是没有经过太多的测试检验。
二次开发	采用的什么编程语言和核心技术，是否能够掌握，掌握的难度如何；代码和文档是否清晰，有无代码注释、设计说明、二次开发说明等。	完全开源，容易进行二次开发，但是由于功能过剩、又有强大的社区支持，几乎不需要自己进行二次开发和维护。	完全开源，代码简单，容易进行二次开发、扩展。
功能的可扩展性	设计上是否具备功能上或代码级别的可扩展能力；扩展是否方便。
易用性	教程、详细说明文档、API文档、参考示例等是否齐全、完善、清晰易懂；是否容易上手使用；其功能和设计，是否容易理解。	由于功能强大，设计和代码比较复杂，但是由于文档和资料非常丰富，易用性比较好。	由于功能简单、代码少，复杂度不高，易用性很好。
复杂度和冗余度	在满足需求的情况下，复杂度越低越好（衡量复杂度的方式，包括代码量、步骤的多少等数据指标）；是否有大量冗余、很可能用不上的功能，且会对资源利用和易用性等方面造成不好的影响；性能上是否远远超过预期且会造成一些不必要的浪费和其他方面负面的影响。
法律风险	是否开源，开源的协议是什么

总的来说，SpringMVC在功能性、产品成熟度和活力上胜出，而ZolltyMVC在性能效率、复杂度和易用性上胜出。

注意，1、此列表仅为示例，每一项写得并不详细，正式的调研报告和选型报告，应该详细列举每一项的对比数据（以数据说话，每一项约2页左右）。

2、限于格式，这里没有列出每一项的权重。在实际对比时，可以给每一项，根据自身的需求，来确定每一项的权重，然后分别乘以每一项得分，所有项得分相加，得出总分数。

一个真实案例：分布式文件存储系统选型