技术方案（开源方案）选型的考量和方法论

我的观点：每个公司的情况不一样，开发人员的能力和语言也不一样，因此方案选型需要根据自身情况而定，没有最好，只有最合适！但是，可以有相关的方法论去帮助我们更好的选择合适的方案！

首要一定要了解清楚背景

首要一定要了解清楚背景，只有背景了解清楚了，大家才能在同一个起点上做相关的决策和讨论，技术方案一定是某个背景下产生的，如果脱离实际业务背景，那么技术方案也无法选择最优的。

(资料图片仅供参考)

这个背景包括的点会比较多，比如当前业务状况、未来发展情况、当然人力情况、现有技术方案等等所有相关的。

技术方案的选择需要团队内部的人员相匹配

技术方案的实现是需要团队内部的开发人员来具体实施的，因此一定要考虑团队内的人员具体情况，并且所选择的技术方案需要和团队内部的人员相匹配。比如编程语言、团队规模、公司业务、公司体量。比如当前这个方案技术人员是否接触过、编程语言是否熟悉、技术人员是否能够完全掌握这个方案等。

但是注意，这里不是说选择完全熟悉的领域或者方案，但是一定是考虑的因素，因为，如果你团队技术人员完全不懂这个技术、语言也不熟悉，选择这个方案后，压根就扛不住啊。 但是如果你团队的人员足够多，技术功底足够扎实，那么选择一个不熟悉的方案能够抗住也是 ok 的。

参照业界标杆选择技术方案（开源方案）

业界标杆选择的技术方案，一定是经过他们专业人士对比、选型之后决策得到的，并且经过了他们的大量的线上实际验证的。因此参考业界标杆，至少不会出错，但是这个仅仅只是一个参照，是否合适自己团队，还要结合本文的其他一个点来考虑。

这里的业界标杆，尽量的是选择国内外都流行的而不仅仅是国内流行的，技术这个东西一定是一个全球化的东西，不是一个局域化的事。所以，一定要选国际化的会更好。

在这个基础之下，我们选择的时候，不是直接使用，而是要看方案是否具备如下能力：

功能点是否满足业务需求，先看是否满足业务诉求，而不是先看开源方案是否更加优秀，一定是在满足业务诉求的基础上再去做抉择。一线互联网公司的落地产品如果是一线互联网公司落地并且开源的，且在社区内形成良好口碑的产品，那么这些产品已经经过了大流量的冲击，坑已经基本被填平，且被社区接受形成一个良好的社区生态。那么这样的产品算是一个比较好的选择，才能让你放心的运用在自己的生产环境中。

* 怎么确定呢？这个就靠 Google 来做一些搜索了，看看有没有一些案例；或者有一些项目会明确说明业界有哪些公司已经采用

复制开源社区活跃度GitHub 上的 stars、 commit、issue、pull request、release 的数量和频率是一个重要指标，同时需要参考其代码和文档更新频率（尤其是近年），这些指标直接反应开源产品的社区活跃度或者说生命力。

* 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。

复制方案是否具备了生产级的能力我们选择的技术方案是要解决实际业务问题和上生产抗流量的，选择不慎可能造成生产级事故，所以生产级，可运维，可治理，成熟稳定的技术才是我们的首选；怎么判定是否生成级可用？看 release 版本是否有发布正式环境，是否有 1.0 版本。怎么判定成熟稳重？ 看是否有一些实际业务在使用。运维能力也是必须要考虑的，否则一旦出问题，运维、研发、测试都只能干瞪眼.代码整体质量是非常重要的，包括代码的功能特性、可扩展性、性能、可靠性和可用性规范的代码风格合理的代码组织结构覆盖度高的单元测试用例有一定的性能测试数据代码可以较好的进行扩展代码的 bug 要少

尽量不要重复造轮子

尽可能的使用红利大的主流技术，而不要自己重复造轮子，更不要魔改。如果市面上已经有比较合适的方案后，我们尽可能的采用主流的开源方案；如果某些场景和功能，当前市面上的方案不满足，我们应该是给他们提 PR ，或者自己扩展支持，但是还是采用市面上已有的，这样等他们升级后，我们依然还是可以跟着升级。

开源方案一般情况下可以满足我们大部分的需求，部分需求不满足的时候，需要慎重考虑这个需求点是否真的有必要？是否属于不可替代需求？

不要过度设计

大家都希望自己的系统低耦合，通用性强，可以完成任意的后续功能的组合，但这也要有个度。

如果你自己认为自己的技术架构能力很强，知道代码在编写中低耦合高扩展，你可以在设计的时候，在满足现有需求的基础上，以不额外增加开发成本为前提，来做一些扩展预留的考虑。但是，如果你技术架构能力不强，满足现有需求即可，尽量做到低耦合，代码要尽可能间接，并写好代码注释。

另外一点就是不要只谈架构方案设计，其实代码层面的设计也是非常重要的，包括分层/模块/接口 等一定要考虑好，其实很多时候，与其做一套通用架构，不如让自己的代码更容易被修改，特别是对于技术架构能力不是特别高的开发者。

合适才是最重要的

最后，要说明下，合适的才是最重要的，技术方案和架构演进不是一蹴而就的，最重要的适合当前的业务场景需要

举个例子，当前业务对并发的要求并不高，你就没有必要非得现在选择一个能够抗住百万、千万的方案，因为这个方案不适合当前架构，初期构造太复杂，反而会让你失去焦点，并且让整体架构（技术方案）逐渐腐烂。

推荐阅读

推荐阅读我的其他文章：

《高并发架构和系统设计经验》

《TCP 长连接层的设计和 在 IM 项目中实战应用》

《万字解读云原生时代，如何从 0 到 1 构建 K8s 容器平台的 LB（Nginx）负载均衡体系》

《高可用架构和系统设计经验》