技术方案（开源方案）选型的考量和方法论
我的观点：每个公司的情况不一样，开发人员的能力和语言也不一样，因此方案选型需要根据自身情况而定，没有最好，只有最合适！但是，可以有相关的方法论去帮助我们更好的选择合适的方案！
首要一定要了解清楚背景
首要一定要了解清楚背景，只有背景了解清楚了，大家才能在同一个起点上做相关的决策和讨论，技术方案一定是某个背景下产生的，如果脱离实际业务背景，那么技术方案也无法选择最优的。
这个背景包括的点会比较多，比如当前业务状况、未来发展情况、当然人力情况、现有技术方案等等所有相关的。
(资料图)
技术方案的选择需要团队内部的人员相匹配
技术方案的实现是需要团队内部的开发人员来具体实施的，因此一定要考虑团队内的人员具体情况，并且所选择的技术方案需要和团队内部的人员相匹配。比如编程语言、团队规模、公司业务、公司体量。比如当前这个方案技术人员是否接触过、编程语言是否熟悉、技术人员是否能够完全掌握这个方案等。
但是注意，这里不是说选择完全熟悉的领域或者方案，但是一定是考虑的因素，因为，如果你团队技术人员完全不懂这个技术、语言也不熟悉，选择这个方案后，压根就扛不住啊。 但是如果你团队的人员足够多，技术功底足够扎实，那么选择一个不熟悉的方案能够抗住也是 ok 的。
参照业界标杆选择技术方案（开源方案）
业界标杆选择的技术方案，一定是经过他们专业人士对比、选型之后决策得到的，并且经过了他们的大量的线上实际验证的。因此参考业界标杆，至少不会出错，但是这个仅仅只是一个参照，是否合适自己团队，还要结合本文的其他一个点来考虑。
这里的业界标杆，尽量的是选择国内外都流行的而不仅仅是国内流行的，技术这个东西一定是一个全球化的东西，不是一个局域化的事。所以，一定要选国际化的会更好。
在这个基础之下，我们选择的时候，不是直接使用，而是要看方案是否具备如下能力：
功能点是否满足业务需求，先看是否满足业务诉求，而不是先看开源方案是否更加优秀，一定是在满足业务诉求的基础上再去做抉择。一线互联网公司的落地产品如果是一线互联网公司落地并且开源的，且在社区内形成良好口碑的产品，那么这些产品已经经过了大流量的冲击，坑已经基本被填平，且被社区接受形成一个良好的社区生态。那么这样的产品算是一个比较好的选择，才能让你放心的运用在自己的生产环境中。* 怎么确定呢？这个就靠 Google 来做一些搜索了，看看有没有一些案例；或者有一些项目会明确说明业界有哪些公司已经采用* 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。尽量不要重复造轮子
尽可能的使用红利大的主流技术，而不要自己重复造轮子，更不要魔改。如果市面上已经有比较合适的方案后，我们尽可能的采用主流的开源方案；如果某些场景和功能，当前市面上的方案不满足，我们应该是给他们提 PR ，或者自己扩展支持，但是还是采用市面上已有的，这样等他们升级后，我们依然还是可以跟着升级。
开源方案一般情况下可以满足我们大部分的需求，部分需求不满足的时候，需要慎重考虑这个需求点是否真的有必要？是否属于不可替代需求？
不要过度设计
大家都希望自己的系统低耦合，通用性强，可以完成任意的后续功能的组合，但这也要有个度。
如果你自己认为自己的技术架构能力很强，知道代码在编写中低耦合高扩展，你可以在设计的时候，在满足现有需求的基础上，以不额外增加开发成本为前提，来做一些扩展预留的考虑。但是，如果你技术架构能力不强，满足现有需求即可，尽量做到低耦合，代码要尽可能间接，并写好代码注释。
另外一点就是不要只谈架构方案设计，其实代码层面的设计也是非常重要的，包括分层/模块/接口 等一定要考虑好，其实很多时候，与其做一套通用架构，不如让自己的代码更容易被修改，特别是对于技术架构能力不是特别高的开发者。
合适才是最重要的
最后，要说明下，合适的才是最重要的，技术方案和架构演进不是一蹴而就的，最重要的适合当前的业务场景需要
举个例子，当前业务对并发的要求并不高，你就没有必要非得现在选择一个能够抗住百万、千万的方案，因为这个方案不适合当前架构，初期构造太复杂，反而会让你失去焦点，并且让整体架构（技术方案）逐渐腐烂。
推荐阅读
推荐阅读我的其他文章：
《高并发架构和系统设计经验》
《TCP 长连接层的设计和 在 IM 项目中实战应用》
《万字解读云原生时代，如何从 0 到 1 构建 K8s 容器平台的 LB（Nginx）负载均衡体系》
《高可用架构和系统设计经验》
