做好技术选型：用合适的技术做合适的事（干货满满）

大家好，欢迎来到IT知识分享网。

一、技术选型的道与术

1、什么是技术选型

根据实际业务管理的需要，对硬件、软件以及所要用到的技术进行规格的选择。

在决定采纳某个技术之前，一定要做好调研，并尝试小规模引入，积累经验，经过验证后再大规模采用。

2、技术选型的误区

（1）不尊重需求

任何技术决策都是为业务去服务的，满足需求是一切的前提，如果需求都不能很好的满足，而是采用了更好用的技术。做了再厉害的技术方案，也是白搭的。

这个道理非常的简单，但实际上呢，有很多的架构师在做技术选型的时候，却过于站在技术人员的立场，导致业务需求都不能很好的满足。

（2）盲目追求流行技术

再流行、再主流的技术，也无法满足所有团队的需求，适合自己的才是最好的。

比如说小项目强行使用微服务。

（3）面向简历选型

（4）过度考虑

不可否认，我们都希望自己的系统都是高可用可扩展，可以完成任意的后续功能的组合，但是呢，这种考虑也要有个度。

（5）把看到的当事实

现在网上有很多技术文章，里面携带着各种观点，往往只会呈现出技术的其中一面，而不是全面的分析一个技术。还是要全面了解，才不会走进一个大坑。

比如说响应式编程有多好、性能多高，只口不提它本身的学习曲线是多么的陡峭。

3、技术选型的步骤

（1）总览

（2）明确问题与目标

首先搞清楚，当前遇到的问题是什么？（性能不佳？原来的技术无法满足需求？）

（3）调研

首先识别：是否需要采用额外的技术？（为了解决问题而引入额外的技术，引入额外的技术也是一种技术选型）

有时候，技术选型是一个伪需求，引入任何技术都是有成本的，比如说学习成本、运维成本、团队适应成本、项目复杂度等等。
一般来说，如果能在现有技术的基础上想办法实现目标，就不要贸然去引入新的技术。

奥卡姆剃刀原理：如无必要，勿增实体。

（4）找到候选技术

可以通过团队内部交流。一般来说，每个团队总有几个对技术有追求，并且有主见的小伙伴，不妨参考一下他们的意见。

网上搜索。

日常积累。见附一。

（5）验证

选择1-3中能够满足需求的技术小规模验证。一个技术合不合适，只有用了之后才会知道。

（6）决策

召集所有相关人员，组织一个评审会议，大家提出意见和建议，做出最终决策。

技术决策是有不确定性的，即使最终决策也是有翻车的可能。

（7）落地

在落地时，初期可以小规模试水，积累一定经验后，再逐步推广，降低落地失败的风险。

（8）总结与复盘

总结一下技术选型的简单过程；解决了那些问题；是否达到了预期；哪些地方是值得改进的。

如果落地失败，总结失败的原因是什么；总结如何防止再犯；完善技术选型的机制。

4、技术的比对

（1）因素加权法

（2）SWOT分析法

5、项目、团队、技术选型的映射关系

（1）项目生命周期 – 短生命周期

（2）项目生命周期 – 长生命周期

首先考虑可维护性，优先考虑成熟稳定的技术。

（3）项目地位 – 边缘性项目

（4）项目地位 – 核心项目

（5）项目新旧 – 新项目

相对更加灵活。技术选型也很自由。

（6）项目新旧 – 老项目

优先选择能和现有技术体系无缝融合的技术。（降低学习成本、降低项目风险、便于后期沉淀到技术体系中）

（7）项目类型 – 探索型项目

探索型项目初期，希望迅速出成果，快速试错，试错不成功的话，就会成为一个短周期项目。如果试错非常成果，就有可能进化为长周期项目，甚至核心项目。

（8）项目类型 – 守成型项目

稳定优先，不要轻易引入新的技术。

如果要引入新技术，则引入能够无缝地融入当前技术体系，且有人精通的技术。

守成型的项目，格局已经顶下来了，投入需求也不会有一个特别大的变化，投入产出比不高，不值得我们做特别大的改造。

（9）项目维度 – 总结

（10）团队技术实力 – 较强

（11）团队技术实力 – 薄弱

还是需要走出技术薄弱的困境，定期组织团队内技术分享、组织技术比赛、1带n树立技术榜样。

（12）团队规模 – 小规模

优先考虑技术的简单性、实施成本和效率。

（13）团队规模 – 大规模

大团队的问题：
团队人员的能力参差不齐，很难照顾到所有人的情况。
不同人的想法不同，对技术的偏好、技术方向也可能不一样，很难听取每个人的建议和意见。
很难做出符合所有人利益的决定。
大规模团队沟通噪声很大。

解决方案一：
通过领域驱动设计等思想，细分问题域，一个大问题拆分成若干个小问题。
把细分出来的问题，分给多个小规模的团队去承接。
将问题交给各个团队自治，由各个团队主导去做技术选型。
大团队拆成小团队。

解决方案二：
如果大团队无法拆成小团队，
需要制定战略方向、战术方向、技术方向。
定好 规约，把技术选型局限到一定的范围内。（比如只允许使用java、只允许使用spring生态）
制定好团队的技术规范，让大家知道什么是不允许的。（比如，禁止使用多个微服务共享1个数据库的方案、远程通信必须使用轻量级且能跨平台的协议）
但是也要设置特权机制，特殊原因特殊对待。（技术评审通过才可以）

（14）团队 – 组织架构

（15）团队 – 总结

需要客观认识自己的团队，了解团队内部特点。

（16）项目管理四要素

（17）总结

做技术选型，是一个需要综合考虑的事情，具体问题需要具体分析，这需要架构师拥有大量的经验，从日常工作中逐步积累经验，才能做好技术选型。

6、如何选择技术栈的版本

（1）概述

软件版本是很多技术人员会忽视的东西，但是确实应该重视起来。

选择不同的版本，可能会有使用上的差异（比如Angular1.x和Angular2.x）、功能上的差异（JDK各个版本新特性）、版本升级的差异（Springboot1.x升级到2.x改动非常大）

（2）常用版本命名方式1 – 语义化的版本命名

Semantic Versioning官网：https://semver.org/lang/zh-CN/

（3）常用版本命名方式2 – 版本代号

比如：SpringCloud、SpringData、Android、Ubuntu、macOS……

比如说SpringCloud的Hoxton.SR9版本，但是现在基本放弃这种版本了，改用日历化版本的命名方式。

（4）常用版本命名方式3 – 日历化

Calendar Versioning官网：https://calver.org/overview_zhcn.html

（5）版本选择原则

（6）如何找版本？

7、技术选型失败如何补救？

（1）绞杀者模式

在旧的系统外围，将新功能用新的方式构建，随着时间的推移，新的部分逐步绞杀旧的系统。

适合重构技术栈完全不同的应用，适合重构大型复杂的旧应用。

（2）修缮者模式

像修房或修路一样，将系统中待修缮的部分隔离起来，用新的方式对其进行单独修缮。

二、基于业务量级的技术选型

1、单机应用

（1）概述

多为个人项目，企业项目用的不多。

（2）单体应用技术选型

2、应用服务、数据服务分离

（1）概述

企业级应用的起步阶段，通常是这种技术模式。

（2）要考虑的问题

（3）本阶段技术选型的特点

3、引入缓存系统

（1）背景

（2）要考虑的问题

在哪个位置使用缓存。采用什么类型的缓存。采用哪种缓存模式。具体用什么缓存组件。

（3）缓存框架

EhCache、Guava Cache、Redission、Caffine、JetCache、Redis、Hazelcast、Memcached、Infinispan等。

4、负载均衡

（1）概述

（2）基于DNS的负载均衡

可以使用dig查看dns的记录。

（3）基于反向代理的负载均衡

请求经过反向代理，由反向代理组件提供负载均衡算法，计算出一个服务器地址返回。

代表实现：Nginx、HAProxy、Apache。

（4）基于特定协议的负载均衡

比如：基于NAT的负载均衡。（在请求的时候把外部IP转化为内部IP，再在内部IP对应的机器上进行处理，处理完成之后再转换回去并返回，比如LVS）

（5）如何选择负载均衡组件

确定好用什么类型的负载均衡器之后，搜索该类型下的负载均衡器实现，并通过因素加权法获得结果。

5、有状态vs无状态

状态：是指服务器是否要存储用户的登录状态。（服务器端是否要维护用户的会话）

（1）粘性会话

当客户端在一台Web Server上登录之后，以后的请求都会绑定到该WebServer实例。

实际项目中很少会采用这种方式，如果非要用的话，一般就是用nginx+ipHash的方式。

（2）会话共享

应用使用session保持会话，多个应用实例存储到一个中央存储中去。

可以考虑使用spring session。

（3）会话复制

web server实例之间互相复制会话。

一般由web容器自身提供，比如tomcat cluster就可以实现。

（4）无状态

服务器端不去记录用户的登录状态。（服务器端不去维护会话）

6、读写分离

7、数据垂直、水平拆分

（1）垂直分表

（2）垂直分库

按业务分类，把不同业务分布到不同数据库上。

（3）水平分库

（4）水平分表

（5）水平切分最佳实践

（6）分库分表中间件选型

MyCAT、Sharding-Sphere、Sharding-JDBC、Sharding-Proxy、Sharding-Sidecar。

8、分布式文件系统

（1）应用与文件资源不分离

（2）应用与文件资源分离

优点：应用服务器可专注于自身业务，文件服务器专门存储文件。

缺点：单台机器容灾能力差，单台文件服务器可能有性能瓶颈。

（3）分布式文件系统

分布式文件系统组成：
文件存储子系统 – 负责文件存储；
文件仲裁子系统 – 负责按照一定算法决定文件存储的位置，相当于分布式文件系统的大脑；
文件容灾子系统 – 容灾能力，可用性得到了显著增强。

（4）如何选择分布式文件系统

（5）各种文件存储方案适用场景

9、CDN

（1）概述

（2）CDN组成原理

CDN是一种组合技术，最简单的CDN网络由一个DNS服务器和几台缓存服务器组成。

（3）CDN技术选型

（4）自建CDN

总体来说就三个问题：用什么DNS系统？用什么缓存系统？用什么反向代理软件？

参考：智能解析 + Nginx反向代理，自建CDN加速节点

（5）淘宝CDN系统架构

（6）商用CDN

Fikker：https://www.fikker.com/

https://www.hostucan.cn/cdn

10、全文搜索

（1）概述

使用全文搜索，减轻了数据库查询压力，推升应用性能，提高用户体验。

（2）使用数据库内置的全文搜索能力

PostgreSQL：gin索引 + zhparser/pg_jieba。

优点：学习成本低，使用方便，不需要引入新组建，保持了架构上的简单性。

（3）使用和数据库深度集成的全文搜索

（4）使用开源全文搜索引擎

目前最主流的方式，选择丰富，扩展性强。

可以考虑使用该方案。

（5）使用商用全文搜索引擎

例如 阿里云的Open Search，微软的Microsoft Azure Search，但是使用该方案的并不多。

（6）自研全文搜索引擎

核心技术在自己手上，更灵活，遇到问题可以从底层调整与优化。

但是对团队的技术要求很高，成本高。

技术实力强、资金实例强的企业可以尝试。

（7）总结

搜索引擎排名：https://db-engines.com/en/ranking/search+engine

三、特定领域的技术选型

1、电商领域

略

2、互联网金融领域

借贷、保险、证券。

互联网金融比传统金融，满足更广泛群体的金融需求，增强金融普惠性，提高金融服务效率。

互联网金融领域近十年蓬勃发展，比如花呗、借呗、微粒贷、余额宝。

技术 体系：SpringCloud、Dubbo、SOFA、以Kubernetes为中心交付。

3、物流领域

架构都是大差不差。

4、社交领域

（1）社交领域

（2）直播社交

直播平台架构：
https://www.processon.com/special/template/5ce763fbe4b0240bd852ec96#map
直播平台的技术架构揭秘：
https://www.cnblogs.com/luojunwu/p/13099063.html
直播平台整体架构：
https://blog.csdn.net/kingmax54212008/article/details/84307500
斗鱼已公开的运维技术和架构分析：
https://www.cnblogs.com/pythonal/p/6561828.html

5、国际化领域

附一：拓展自己的技术视野

开源中国软件更新栏目：https://www.oschina.net/news/project
技术雷达：https://www.thoughtworks.com/zh-cn/radar/techniques
ITeye：https://www.iteye.com/
spring4all：https://spring4all.com/
DockOne：https://dockone.io/
Jdon（解道）：https://www.jdon.com/

附二：常见开源License

附三：开发语言与数据库排行榜