选择合适技术的 11 个考量因素

作为软件专业人士或爱好者，我们在技术组件的选择方面感到不知所措。仅看消息队列领域，您就可以从 Kafka、RabbitMQ、ActiveMQ、HornetQ 等中选择，或者使用大型云提供商之一的托管服务。面对所有这些选择，我们如何开始知道哪种选择最适合我们的用例呢？

这是一个困扰我一段时间的话题，并且在最近 PyCon 上我参加的 Apache Kafka “Birds of a Feather” 会议期间浮出水面。这也是我在职业开发人员的职业生涯中能够进行实验并改进我的想法的一个话题。我甚至在一个关于如何为当前规模做出正确选择而又不牺牲成为下一个 Google 的梦想的演讲中谈到了这个问题。

以下是在评估开源软件组件时要考虑的高级标准。在我介绍完开源之后，我将添加更多关于为托管或软件即服务解决方案付费的意义的具体要点。

开源评估标准

1. 项目年龄和成熟度

您正在考虑的项目有多成熟？它仍然处于 beta（或 alpha？）阶段，还是已有十年历史，并准备发布其第三个主要版本（Hadoop！），还是介于两者之间？

您应该赋予此标准的权重取决于此项目在您的架构中将扮演的角色有多关键以及涉及多少代码。例如，如果有人建议使用全新的数据库技术作为主要用户存储后端，我会非常犹豫。对于一个 JavaScript 库，用于在页面的 A/B 测试变体上渲染图像轮播，更新的东西可能可以尝试。

2. 维护

与项目的成熟度几乎密切相关的是，当前的维护几乎是不可协商的。为什么要采用您知道不会看到可靠更新的东西呢？

在大多数情况下，您需要一个开源项目，该项目已经超越了最初开创它的公司或个人，并获得了更广泛社区的支持。足够大的项目最终会发展出自己的基金会来支持它们——例如 Django 软件基金会——但如果情况并非如此，请寻找像 Apache、Linux 基金会或软件自由保护协会等组织的支持。

3. 发布速度和稳定性

在维护这个主题上，考虑一下项目的进展速度。发布频率如何？是否有规律的节奏？在您的内部软件包服务器上维护一个 fork 数月，同时等待上游集成错误修复并进行官方发布，这可能会增加很多开销。

当发布发生时，是否容易分辨出发生了什么变化？项目是否使用语义版本控制或类似的机制来指示是否存在重大更改？是否有长期支持 (LTS) 分支可用，这些分支从主线开发版本接收反向移植的安全性和稳定性补丁？

4. 安全性

至少，搜索 通用漏洞和披露 (CVE) 数据库 中您正在考虑的项目。要问的问题：报告了多少个漏洞？它们是否已解决，以及花费了多长时间？在等待补丁期间，实施解决方法有多困难？当这些补丁到达时，应用它们会有多大的破坏性（例如，将新的资产包上传到您的 CDN 或重启您的整个数据库层）？

如果像我们很多人现在一样，您从事 Web 服务工作，请务必熟悉 开放 Web 应用程序安全项目 记录的攻击和缓解措施，并了解将新代码或系统引入您的环境如何改变您的威胁模型。

5. 标准和项目生态系统

如果存在，此项目是否遵守其概念空间的众所周知的标准？如果新的搜索后端使用 HTTPS 和 JSON 而不是定制的二进制协议，您和您的团队将更容易集成它。

您选择的实现语言中是否有可用的库，还是您需要手动编写“胶水”代码？请记住，如果您的语言的库不存在，对于满足您所有其他要求的项目来说，这绝对是值得权衡的。这也是参与并回馈社区的好方法！

开发人员是否了解并熟悉此项目？如果您需要帮助，是否容易找到了解您选择的技术并可以立即上手的人员？

6. “开箱即用性”

这是我的朋友兼会议组织者 Josh Simmons 在一次关于为什么新开发人员可能会选择 Django 的精彩演讲中使用的一个精彩短语。它大致意味着您使用该软件的最初半小时的体验。

在您的笔记本电脑上安装并运行示例项目有多困难？它是否有挑剔的要求，使其难以在您的持续集成环境中运行？那么投入生产呢——默认配置是否可靠和安全，或者您将花费数周时间来调整变量？

7. 文档

良好的文档绝对是一门艺术，但任何项目都有基本要求

• 首先，文档应该存在。
• 它应该是可搜索和可发现的。
• 文档应保持最新，过时/已弃用的版本应明确标记为如此。

8. 支持和承包商

对于任何大型事业的主要组件，请调查是否存在咨询和支持生态系统。如果您是一家无法负担全职数据库管理员 (DBA) 的小型商店，那么当您的关系数据库在凌晨 2 点崩溃，并且您发现过去一个月的所有备份都已损坏时，与 DBA 公司签订合同可能会产生重大影响。

9. 许可

最后，您应该了解项目发布的许可证，以及它们是否与您自己的许可证兼容。去年，Facebook 重新许可了 React，以回应社区对其许可证与其他开源项目兼容性的担忧。为 iOS 或 MacOS 开发？请记住，GPL 许可的软件与 Apple App Store 的条款不兼容，因此您使用的任何东西都需要在另一种许可证下。

软件即服务评估标准

上述关于开源软件的许多考虑因素也适用于使用托管或托管解决方案。但是，在这些情况下，还有一些其他事项需要考虑。

10. 成本权衡

基于订阅的软件包的明显成本组成部分是货币部分。分析这一点本身就是一篇文章，但最重要的要素是找到一个标准的成本单位（例如，每个处理的请求的成本），以比较可能具有不同定价模式的产品。

然而，除了直接标价之外，还有其他成本

• 您的团队内部构建功能或拼凑现有解决方案并学习如何操作它们需要花费多少时间？
• 当您的团队忙于处理此事时，您从功能开发路线图中失去了什么，您能否承担不起明天就拥有它的后果？

11. 突发的巨大（供应商）存在失败

这 几乎就是字面意思——如果您的项目依赖于第三方服务，如果提供该服务的供应商突然 倒闭 了 呢 ？

如何使用这些标准

这些标准绝不是在考虑软件组件时要考虑的详尽列表。我鼓励您选择对您和您的项目有意义的标准，并添加特定于您情况的其他标准。

对于影响工作范围较小的选择，可以整体考虑它们，并在查看新软件时将它们放在脑海中，但对于较大的决策，值得在电子表格中跟踪标准，并对候选实现进行数值评分，以便在做出决策之前得出总体评分。

祝您狩猎愉快！

现代软件堆栈的几乎每个组件都有无数的开源项目可用——选择范围令人眼花缭乱，尤其是在从头开始或一次做出许多选择时。但是，考虑到上述标准，您应该能够更好地理性地思考您的需求以及您的每个选项可能或可能不适合它们的方式。祝您狩猎愉快！