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

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

首要一定要了解清楚背景

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

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

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

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

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

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

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

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

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

• • 一线互联网公司的落地产品
  

• • 如果是一线互联网公司落地并且开源的，且在社区内形成良好口碑的产品，那么这些产品已经经过了大流量的冲击，坑已经基本被填平，且被社区接受形成一个良好的社区生态。那么这样的产品算是一个比较好的选择，才能让你放心的运用在自己的生产环境中。
  
• • 怎么确定呢？这个就靠 Google 来做一些搜索了，看看有没有一些案例；或者有一些项目会明确说明业界有哪些公司已经采用
  

• • 开源社区活跃度
  

• • GitHub 上的 stars、 commit、issue、pull request、release 的数量和频率是一个重要指标，同时需要参考其代码和文档更新频率（尤其是近年），这些指标直接反应开源产品的社区活跃度或者说生命力。
  
• • 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。
  

• • 方案是否具备了生产级的能力
  

• • 我们选择的技术方案是要解决实际业务问题和上生产抗流量的，选择不慎可能造成生产级事故，所以生产级，可运维，可治理，成熟稳定的技术才是我们的首选；
  
• • 怎么判定是否生成级可用？看 release 版本是否有发布正式环境，是否有 1.0 版本。
  
• • 怎么判定成熟稳重？看是否有一些实际业务在使用。
  

• • 代码整体质量是非常重要的，包括代码的功能特性、可扩展性、性能、可靠性和可用性
  

• • 规范的代码风格
  
• • 合理的代码组织结构
  
• • 覆盖度高的单元测试用例
  
• • 有一定的性能测试数据
  
• • 代码可以较好的进行扩展
  
• • 代码的 bug 要少
  

尽量不要重复造轮子

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

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

不要过度设计

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

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

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

合适才是最重要的

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

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

~~~~~~~~ 本文完 ~~~~~~~~

推荐阅读

推荐阅读我的其他文章：

• 《我终于统一了团队的技术方案设计模板》
  
• 《工作十年，谈谈我的高可用架构和系统设计经验》
  
• 《一文了解高性能架构和系统设计》
  
• 《高并发架构和系统设计经验》
  
• 《微服务系列 1：服务化框架落地的挑战和核心需求》
  
• 《微服务系列 2：微服务化框架的模型和治理能力设计》
  
• 《TCP 长连接层的设计和 在 IM 项目中实战应用》
  
• 《万字解读云原生时代，如何从 0 到 1 构建 K8s 容器平台的 LB（Nginx）负载均衡体系》