使用开源项目：成功秘诀或未减轻的灾难

选择正确的开源项目感觉就像是扫雷的游戏-一个错误的举动，并且蒸蒸日上！ 您的系统死了。

在软件开发领域有一个普遍的原则-DRY，即不要重复自己。 开源项目的主要目的是共享，以避免所有人在制造引擎时都制造轮子。 对于像互联网和信息技术这样快节奏的行业来说，速度就是一切。 开源资源节省了人力和时间，同时加快了业务发展的步伐。 不去爱的种种？

但是，地面现实并不总是那么漂亮。 基于开放源代码的项目会带来一系列问题，例如停机或数据丢失。 在某些情况下，各种各样的开放源代码项目可能会造成真正的头痛。 应该使用MySQL还是PostgreSQL？ 是Memcached还是Redis？ 角还是反应？

根据我与UC浏览器团队合作和开发开放源代码项目的经验，这里有一些想法，观察和个人课程。

选择阶段

根据业务需求选择基础项目

由于许多开放源代码选项往往相似（但同时又如此不同！），因此在选择新手时，我们总是面临困境。 为了简化流程并确保选择的结果适合最终目的，我们选择更加关注它如何满足平台需求，而不是单纯的选择。

在社交平台上工作的过程中，我们发现了一个名为TT（东京暴君）的开源解决方案，该解决方案完全替代了具有缓存的Memcache和具有持久性存储的MySQL。 认为这是一个了不起的解决方案，所以我们广泛使用它-后来才意识到它不能完全替代MySQL，而且它看似出色的功能非常有bug，并且需要很长时间才能熟悉。

如果企业需要1,000 TPS，则具有20,000 TPS的解决方案与具有50,000 TPS的解决方案之间几乎没有什么区别。 将来可以为更高的TPS数量重构系统体系结构，但是UNIX编程哲学指出，过早的优化是万恶之源。

评估项目成熟度

在性能，功能和新功能方面，新的开源项目通常会声称比以前的项目好得多。 尽管很诱人，但它们都将带有错误。 编程人才不能保证项目在其第一版中就是完美的。 在Windows，Linux和MySQL上工作的开发人员是业内最好的，但他们仍然为其项目发布更新和错误修复。 年轻的开源项目在应用于生产环境时会带来新的风险，其中最不严重的是系统停机（已经相当严重），最坏的情况是不可逆的数据丢失（一场噩梦）。

在使用TT时，发生了电源故障，导致文件损坏，无法通过重新启动系统来恢复。 值得庆幸的是，我们的日常备份实践节省了一天的时间，但是在电源出现故障的那一天，我们仍然丢失了数据。 之后，我们花了很多时间浏览源代码，并通过自己编写新工具来恢复数据。 值得庆幸的是，这些数据本质上不是财务数据。 否则我们会遇到大麻烦。

那么，如何检查开源项目是否成熟？ 查找以下内容：

1. 版本号

除非完全有必要，否则请避免使用版本0.X的项目，而应选择版本至少为1.X的项目。 更高的数字总是更安全的选择。

2. 使用该项目的公司数量

开源项目通常会在项目主页上列出使用它们的公司。 寻找使用该项目的所有大型知名公司以及总数。

3. 社区参与

查看使用该项目的社区是否处于活动状态，帖子数，回复数，对问题的响应时间。

不要忘记操作和维护功能

当我们选择一个开源项目时，我们通常会更多地关注诸如性能和可靠性之类的技术指标，而不是其促进运维的能力。 但是，操作和维护是将任何解决方案应用到在线生产环境中必不可少的部分。 没有这个，涉及故障排除的任何实例都可能陷入冰雹玛丽时间。

您可以通过研究以下方面来检查项目的运维能力：

1. 开源解决方案的日志是否完整 ：某些开源解决方案的日志文件非常简短，仅用于启动和停止的几行。 这使得出现问题时难以调查和解决问题。

2. 开源解决方案是否具有维护工具 ：命令行和管理控制台可帮助查看系统的运行状况

3. 开源解决方案是否具有实时检测能力 ：包括故障检测和恢复，警报，切换等。

活动使用阶段

深入研究，精心测试

在观看了一些演示之后，许多人只是简单地复制和粘贴开源代码并将其部署到在线应用程序中。 这是危及主系统健康及其可靠性的可靠方法，类似于翻阅驾驶员手册后跟上汽车的方向盘。

我想到了一些轶事。 一次，一个团队决定在没有完全弄清楚倒排索引并保留默认配置值的情况下，对突发事件使用Elasticsearch。 他们在第一次运行时就将其投入使用，并意识到节点ping时间过长，消除异常节点的速度太慢。 结果？ 整个站点崩溃了。

还有一次，许多团队在没有充分研究MySQL的情况下开始使用MySQL。 最终，业务部门抱怨MySQL运行太慢。 罪魁祸首？ 最关键的参数（例如innodb_buffer_pool_size，sync_binlog，innodb_log_file_size）配置错误或根本未配置，导致性能不佳。

在研究和测试项目时：

1.通过阅读设计文件和可用的白皮书，以完全理解该项目的原理

2.检查每个配置的作用和影响，并确定关键配置项

3.对多种情况进行性能测试

4.进行压力测试，使您连续运行项目数天。 观察CPU，内存，磁盘IO和其他指示器的波动。

5.进行故障测试：终止，掉电，重启，切换等。

仔细应用并分阶段发布

一旦学习和测试的第一阶段已经过去并且所有问题都已解决，我们能否简单地继续前进？ 还没那么快，海岸还没有清理。 即使进行了深入的研究和多次测试，也必须保持谨慎，因为它们只能降低风险，而不能消除风险。

当我们使用TT时，实际上是安排专家在执行代码之前先看一下代码并进行一些测试。 即使花了一个月的时间，我们上线后仍然遇到许多问题。 在线生产环境是一个复杂的野兽，最好谨慎使用。 根据我们的经验，最有效的方法是将该项目用于辅助业务而不是核心业务，然后逐步将其推广到更重要的部分。

期望最好，为最坏做好准备

即使一切似乎都进展顺利，也还不是时候放松一下，尤其是在开始使用一个新的开源项目之后。 如果运气必须转过脸，那么一个人可能会遇到一个没有修复的错误，或更糟糕的是，世界上其他任何人都尚未遇到的错误。 这种情况可能会对业务造成致命打击，尤其是在涉及存储故障的情况下。

一些同事知道的一家企业在MongoDB上经历了令人痛苦的经历。 当计算机故障时，他们丢失了部分关键数据后，他们尝试将其恢复为无效。 更糟糕的是他们没有备份。 故事在我们自己的办公室中迅速传播，从那时起，O＆M团队就反对使用MongoDB的所有建议（甚至用于试用）。

尽管仅仅是因为这可能有点极端而完全反对一个项目，但这个故事仍然可以被唤醒：在将开源项目用于重要业务或数据时，明智的做法是保留一个更成熟的解决方案作为备份，而不是备份出问题时要拧紧双手。 例如，如果一个人主要使用Redis，他们可以保留MySQL进行存储备份。 尽管这会增加成本和复杂性，但这是防范故障风险的必要保证。

修改和二次开发阶段

尽可能保持纯净

当我们发现开放源代码项目的某些方面不能满足我们的需求时，很自然会被迫做出更改。 如何进行此类更改是主要挑战。

一种方法是分配一些人员，以适合专业业务需求的方式彻底改造项目，但这出于两个原因并不理想。 首先，这样的投资太高了。 一个与Redis一样重要的开源解决方案将需要至少两个人在四个星期的时间内进行完全修改。 其次，进行过多的修改会消除遵循和合并开源项目的演变版本的能力。

这使得开发辅助系统（如监视和负载平衡）变得更加可行。 例如，如果我们要向Redis添加集群功能，则无需更改其实现。 相反，添加代理层可以帮助达到相同的目的（Twitter的Twemproxy遵循相同的原则）。 自从Redis开始使用v3.0提供集群功能以来，我们要做的就是从原始解决方案切换到Redis 3.0。

但是，如果您真的想更改开源系统，该怎么办？ 您可以直接提出要求或向开发人员报告错误，但是不能保证他们会迅速做出响应。 所采用的方法实际上取决于当前问题的紧迫性。 对于不太紧急的情况，最好安排备份和紧急措施。

将所有东西扔到窗外，然后创建所需的轮子

无论我们是否选择开源项目，成本与收益之间的主要权衡仍然存在。 有时使用开源项目可能不是最好的方法。

软件和硬件领域之间最显着的差异是，在软件方面绝对没有最终的行业标准-每个人都喜欢按照自己喜欢的方式来创建软件。 在硬件中，无论技术或产品质量如何，制造无法应用于车辆的具有独特尺寸的车轮都是浪费资源。 这不是软件的限制，在软件中创建的任何东西仍然可以使用，并且组合没有严格定义。 此外，对于大规模应用，开源项目通常会适应通用处理解决方案。

但是，由于业务类型的差异，通用解决方案可能不适合全面应用。 例如，Memcached通过一致性哈希提供群集，但是对于我们的某些业务，缓存崩溃会减慢整个业务的速度。 这需要Memcached中不可用的缓存备份功能。 同时，当Redis没有集群时，我们分配了一个大约两到四个人的团队，在两个月的时间内工作，以产生一组支持存储，备份和集群的缓存框架。 在此框架的基础上，我们添加了跨数据中心同步，从而大大提高了平台的可用性。

使用开源解决方案并依靠它们来实现特定的需求可能既耗时又完全徒劳。 因此，如果现金流量，人才库和时间允许，投资于创建完全适合您的平台或服务的自己的解决方案并不是一个糟糕的选择。 毕竟，所有值得其支持的高科技公司都这样做—如果没有它们，我们将永远不会拥有如此多的优秀开源项目。

（李运华李运华的原创文章）

阿里巴巴科技

关于阿里巴巴最新技术的第一手和深入的信息→在Facebook上搜索“ Alibaba Tech”

From: https://hackernoon.com/using-open-source-projects-a-recipe-for-success-or-unmitigated-disaster-784eff6713b1