技术方案选型标准 第1篇
根据实际业务管理的需要，对硬件、软件以及所要用到的技术进行规格的选择。
狭义上的技术选型：团队决定选用哪种技术去解决业务问题。（某种语言、某种框架去开发项目） 广义上的技术选型：泛指项目实施过程中的各种技术决策。（制定技术AB方案选其中一套，每个技术决策都是技术选型）
在决定采纳某个技术之前，一定要做好调研，并尝试小规模引入，积累经验，经过验证后再大规模采用。
任何技术决策都是为业务去服务的，满足需求是一切的前提，如果需求都不能很好的满足，而是采用了更好用的技术。做了再厉害的技术方案，也是白搭的。
这个道理非常的简单，但实际上呢，有很多的架构师在做技术选型的时候，却过于站在技术人员的立场，导致业务需求都不能很好的满足。
再流行、再主流的技术，也无法满足所有团队的需求，适合自己的才是最好的。
比如说小项目强行使用微服务。
有些架构师做决策的时候，不去结合当前团队和业务的情况，而是什么技术牛叉用什么。 主要是将该公司当成了跳板，为了丰富自己的简历经验。 这种现象并不少见，可谓是损人利己。
不可否认，我们都希望自己的系统都是高可用可扩展，可以完成任意的后续功能的组合，但是呢，这种考虑也要有个度。
过度考虑通用性、灵活性、扩展性，往往会导致工作量以及复杂度的猛增。 架构是逐步演进的，不是一蹴而就的。
现在网上有很多技术文章，里面携带着各种观点，往往只会呈现出技术的其中一面，而不是全面的分析一个技术。还是要全面了解，才不会走进一个大坑。
比如说响应式编程有多好、性能多高，只口不提它本身的学习曲线是多么的陡峭。
首先搞清楚，当前遇到的问题是什么？（性能不佳？原来的技术无法满足需求？）
技术选型的目标是什么？（提升开发效率？提升性能？降低成本？解决业务问题？） 多个目标排列优先级。
首先识别：是否需要采用额外的技术？（为了解决问题而引入额外的技术，引入额外的技术也是一种技术选型）
有时候，技术选型是一个伪需求，引入任何技术都是有成本的，比如说学习成本、运维成本、团队适应成本、项目复杂度等等。 一般来说，如果能在现有技术的基础上想办法实现目标，就不要贸然去引入新的技术。
奥卡姆剃刀原理：如无必要，勿增实体。
多个技术选择，比对技术有哪些风险，是不是可控的。 实施的成本高不高。（时间成本、开发成本、硬件成本、采购成本） 比对技术各自的优缺点。
可以通过团队内部交流。一般来说，每个团队总有几个对技术有追求，并且有主见的小伙伴，不妨参考一下他们的意见。
网上搜索。
日常积累。见附一。
选择1-3中能够满足需求的技术小规模验证。一个技术合不合适，只有用了之后才会知道。
召集所有相关人员，组织一个评审会议，大家提出意见和建议，做出最终决策。
技术决策是有不确定性的，即使最终决策也是有翻车的可能。
在落地时，初期可以小规模试水，积累一定经验后，再逐步推广，降低落地失败的风险。
总结一下技术选型的简单过程；解决了那些问题；是否达到了预期；哪些地方是值得改进的。
如果落地失败，总结失败的原因是什么；总结如何防止再犯；完善技术选型的机制。
结合项目里面关注的因素，为每个因素设置一个权重，并进行加权处理。 因素加权法一般只能用在选择具体的技术上，对于宏观层面的技术选型，比方说选择使用哪个技术方案或者更加高层的决策因素，因素加权法一般是无能为力的。
技术相关的因素： 1、官方活跃度 - 决定了如果在使用的过程中遇到bug能否得到官方支持。（软件发布周期、提交记录、README、Issue解决速度） 2、社区活跃度 - 决定了今后在使用中遇到问题，是否能够很快地得到帮助。（搜索引擎词条数、百度指数、谷歌趋势、GitHub Star数、第三方社区活跃度） 3、可维护性 - 如果维护性不好，千万不要使用！（比如低代码开发平台，需求复杂、变更频繁时慎用） 4、学习曲线 - 结合当前团队的技术特点以及熟练程度来考虑。（开发难度、学习难度） 5、性能 - 响应时间、TPS、存储容量、带宽等。（用性能测试工具评估） 6、安全性 - 检查它有多少的安全补丁以及严重程度，尤其是短期的安全补丁。可以借助一些漏洞扫描工具进行扫描。 7、优先选用熟悉的技术 - 而非高端的技术，接地气，了解熟悉。
技术以外的因素： 1、大规模采纳并成功的案例。侧面论证技术的成熟性、实践证明了能用在生产。 2、是否能够快速招募到人才。 3、考虑并平衡各方面利益。如果做技术选型的过程中，某个利益相关的发言人没有参加过，就可能会导致不考虑他们的决策。 4、法律问题。商用解决方案（花钱） or 开源解决方案（License问题，详见附二） 5、识别炒作。不要尽信别人的结果、文章，勤动手，以亲测结果为准。
SWOT分析法比较适合做一些宏观层面的技术选型。 适合做一些更上层、更加抽象的技术选型，比如说确定公司未来五年的技术方向是用云原生技术体系还是传统的技术体系？ SWOT是一个比较通用的分析框架，不仅仅可以用来做技术上的一些决策，还可以做企业的战略规划、分析竞争对手、个人的职业发展等等。
从优势（Strength）、劣势（Weakness）、机会（Opportunity）、威胁（Threat）这四个维度分析问题。 优势、劣势是内部的能力，而机会和威胁则是外部因素。
建议选择门槛低、简单易上手、开发速度快的技术。（糙快猛） 开发过程也可以相对自由。 这是因为项目一旦结束，代码就会直接被抛弃，精雕细琢的意义并不大。
首先考虑可维护性，优先考虑成熟稳定的技术。
影响面相对较小，有一定的故障容忍度。 可以作为项目的技术试验田，尝试比较新颖的技术或者方案，从中积累经验和教训。
稳定优先，做相对保守的技术选型。 同时也要考虑可维护性。 优先选用比较成熟，团队内部已积累足够经验，同时有比较好的技术支持的技术。
相对更加灵活。技术选型也很自由。
优先选择能和现有技术体系无缝融合的技术。（降低学习成本、降低项目风险、便于后期沉淀到技术体系中）
探索型项目初期，希望迅速出成果，快速试错，试错不成功的话，就会成为一个短周期项目。如果试错非常成果，就有可能进化为长周期项目，甚至核心项目。
探索型项目不确定性高。 所以既要快速，也要考虑可维护性。 优先保障简单性，不做太多预留。（需求不稳定，预留的扩展点，后续可能都用不上，甚至可能会成为负担）
但是，目前很多公司，初期只考虑快，等到项目爆发增长了之后，再把中心往可维护性偏移。（不建议这样做，出来混总是要还的，技术债总是要还的） 所以，探索型项目，非常考验架构师CTO的业务敏感度、技术嗅觉、直觉，做技术上的预判。
稳定优先，不要轻易引入新的技术。
如果要引入新技术，则引入能够无缝地融入当前技术体系，且有人精通的技术。
守成型的项目，格局已经顶下来了，投入需求也不会有一个特别大的变化，投入产出比不高，不值得我们做特别大的改造。
低价值的项目，优先考虑门槛低，速度快的技术； 高价值的项目，尽早进行投资性的技术积累，考虑天花板高、比较成熟的技术，并融入企业现有技术体系，
可结合项目的情况，一定程度上选择相对新颖的技术。 并且新技术往往代表技术趋势，代表更高的生产力。
建议继续在现有的技术体系之下发展，不要做过多的折腾。 技术选型尽量平滑，控制在现有技术体系的范围之内，减少适应成本，降低风险。 还可以增强团队交付记录，定好技术上的约束。（编程规约）
还是需要走出技术薄弱的困境，定期组织团队内技术分享、组织技术比赛、1带n树立技术榜样。
优先考虑技术的简单性、实施成本和效率。
大团队的问题： 团队人员的能力参差不齐，很难照顾到所有人的情况。 不同人的想法不同，对技术的偏好、技术方向也可能不一样，很难听取每个人的建议和意见。 很难做出符合所有人利益的决定。 大规模团队沟通噪声很大。
解决方案一： 通过领域驱动设计等思想，细分问题域，一个大问题拆分成若干个小问题。 把细分出来的问题，分给多个小规模的团队去承接。 将问题交给各个团队自治，由各个团队主导去做技术选型。 大团队拆成小团队。
解决方案二： 如果大团队无法拆成小团队， 需要制定战略方向、战术方向、技术方向。 定好 规约，把技术选型局限到一定的范围内。（比如只允许使用java、只允许使用spring生态） 制定好团队的技术规范，让大家知道什么是不允许的。（比如，禁止使用多个微服务共享1个数据库的方案、远程通信必须使用轻量级且能跨平台的协议） 但是也要设置特权机制，特殊原因特殊对待。（技术评审通过才可以）
康威定律：组织沟通方式会通过系统设计表达出来。 项目架构其实是团队沟通协作方式而产生的一个结果。 （比如，公司前后端都是一个人搞，很可能不会做前后端分离。想要做前后端分离，就要前后端分工） 所以，需要结合当前团队组织架构的特点，考虑选用的技术在最终技术架构中的位置、与当前团队沟通结构的匹配程度。
需要客观认识自己的团队，了解团队内部特点。
四要素：质量、工作范围、时间、成本。 理想情况：好、多、快、省。（实际上这四个项目是互相制约的）
考虑到多数情况，质量是不能妥协的，所以就有下面的模型：
做技术选型，是一个需要综合考虑的事情，具体问题需要具体分析，这需要架构师拥有大量的经验，从日常工作中逐步积累经验，才能做好技术选型。
软件版本是很多技术人员会忽视的东西，但是确实应该重视起来。
选择不同的版本，可能会有使用上的差异（比如和）、功能上的差异（JDK各个版本新特性）、版本升级的差异（升级到改动非常大）
Semantic Versioning官网：
比如： 1：主版本（Major），表示做了不兼容的修改。 2：次版本（Minor），表示向下兼容的功能性新增。 3：增量版本（Patch），一般表示向下兼容的bug修复。 RELEASE：里程碑（Milestone），表示版本状态（SNAPSHOT-开发版、RC-正式版的候选版、CR-正式版的候选版、RELEASE-正式版、Final-正式版）
比如：SpringCloud、SpringData、Android、Ubuntu、macOS……
比如说SpringCloud的版本，但是现在基本放弃这种版本了，改用日历化版本的命名方式。
Calendar Versioning官网：
比如： 2024表示主版本（Major），表示发布年。 0：次版本（Minor），表示功能新增。 1：微版本（Micro），表示最终编号，有时表示“补丁”。 RELEASE：修饰符（Modifier），表示版本状态。
1 - 新旧版本不兼容，优先用新版： 老版本早晚会废弃，跟随官方的步伐与软件发展的规律，否则得自己维护了。
2 - 最新的次版本可以观望： 最新的次版本不建议直接用在生产，还不是很稳定。建议观望3个月以上，看看有没有什么明显的bug。
3 - 总是使用BOM： BOM：Bill of Materials，定义一整套jar包版本的集合。从而让应用引入jar包依赖的时候，只要引入这个bom就可以放心的使用依赖包了，不需要自己去指定版本号，这些jar包的升级都会由bom的维护方去负责，并且bom的维护方会保证定义的jar包版本之间的一个兼容性。 Maven中BOM
4 - 尽量使用正式版 正式版都比较稳定，但是也有例外，有时候正式版有一些奇怪的bug，在非正式版做了修复。
5 - 尽量选用LTS版本 LTS（Long Term Support，长期支持版本）。 比如jdk8、11、17是LTS版本。比如说Ubuntu偶数年的4月份发行的版本是LTS版本，比如、
6 - 关注软件间的兼容性关系 比如说Springboot与SpringCloud之间的兼容性关系。
官网。 wiki。 软件安装指南、quick start。
在旧的系统外围，将新功能用新的方式构建，随着时间的推移，新的部分逐步绞杀旧的系统。
适合重构技术栈完全不同的应用，适合重构大型复杂的旧应用。
不适合无法拦截前往旧系统的请求，不适合局部修改就能达到目标。
像修房或修路一样，将系统中待修缮的部分隔离起来，用新的方式对其进行单独修缮。
适合能够局部改造的场景，不适合需要全盘改造的场景。
技术方案选型标准 第2篇
借贷、保险、证券。
互联网金融比传统金融，满足更广泛群体的金融需求，增强金融普惠性，提高金融服务效率。
互联网金融领域近十年蓬勃发展，比如花呗、借呗、微粒贷、余额宝。
技术 体系：SpringCloud、Dubbo、SOFA、以Kubernetes为中心交付。
蚂蚁金服：支付宝和蚂蚁花呗的技术架构及实践： 陆金所金融平台的架构大升级： 从宜人贷系统架构看互联网高并发对金融系统架构的挑战： 支付宝的技术架构及实践——阅读心得：
架构都是大差不差。
达达CTO：达达物流技术架构之路与技术分享 菜鸟物流大数据技术架构 顺丰快递物流设计方案 美团即时物流的分布式系统架构设计
熟人社交：QQ、微信。 短视频社交：抖音、快手。 直播社交：虎牙、斗鱼。 陌生人社交：陌陌、soul。 职场社交：钉钉、飞书、脉脉。 问答社交：知乎、百度知道。 婚恋社交：珍爱网、世纪佳缘。 社交媒体：Facebook、微博、Twitter。 儿童社交：小天才手表。
推流：是指将采集阶段封包好的内容传输到服务器的过程。 拉流：从直播服务器拉取直播内容的过程。（观众观看直播的过程）
直播平台架构： 直播平台的技术架构揭秘： 直播平台整体架构： 斗鱼已公开的运维技术和架构分析：
国际化环境下系统架构演化： 阿里巴巴全球化技术架构： 来膜拜下 Google 的全球化网站架构： _464000 全球级的分布式数据库 Google Spanner原理：
i18n的处理： Springboot使用不同的配置获取不同的语言。 使用数据库配置。 前端页面配置。
技术方案选型标准 第3篇
alpha = beta = gamma = Score = alpha * Pperformance + beta * Ccost + gamma * E_extendability print(_技术总分：_, Score) ```
在上面的代码中，我们首先计算了技术的性能、成本、可扩展性评分，然后根据以上的数学模型公式计算出技术的总分。
随着数据技术的不断发展，技术选型的复杂性也会不断增加。未来的挑战包括：
为了应对这些挑战，我们需要进一步研究和发展更加高效、智能的技术选型方法和工具。
A1：技术选型不仅适用于大数据场景，还适用于其他场景，如人工智能、企业级应用等。技术选型是一种通用的决策方法，可以帮助我们在面临不同需求时选择合适的技术。
A2：技术选型报告可以由专业人士编写，也可以由非专业人士编写。不过，专业人士编写的报告通常更加准确、全面。在实际应用中，我们可以根据团队的能力和资源来决定是否需要请求专业人士的帮助。
A3：技术选型报告中应该包括技术的优缺点，这有助于决策者更好地了解技术的特点，从而做出更明智的决策。在实际应用中，我们可以根据报告的目的和受众来调整报告的内容和格式。