架构之技术选型

前言

技术选型是一个公司的重中之重，是技术的根基，是部门的方向，是对技术负责人，架构师，cto，基础架构组的考验。一个错误的选型，可能形成巨大的财务，人力损失。

技术选型原则

开源,是否在持续维护中

开源以后，不惧怕闭源

不用惧怕之后项目会闭源而出现各类问题，若是有一个优秀的项目开源之后，很大的用户群体，大型互联网公司使用过，那么不用担忧闭源问题带来的后果，闭源以后大型互联网会在原有的基础上维护或者创新一个相似的。

开源项目会有更多人与团队参与，社区十分会比较活跃，生态圈会慢慢完善

鸟菜啊我的认为这点很是重要，开始使用某个技术的时候，可能不须要源码。时间长了会暴露大量的问题出来，这个时候请人不如求己。

1. 当须要在某个技术上进行扩展的时候，若是不了解原理与实现，可能形成严重的问题。
2. 深刻源码，能够了解实现，正确的使用这个技术。
3. 出现bug的时候，能够了解bug出现的缘由

持续维护中

若是做者与团队，中止对开源项目进行维护。不该该选择该技术。在技术栈里面已经存在。那么你须要准备寻找替代品，并在必定时间内完成更新。可是有些项目已经作到终点了，好比dubbo2.0,基本知足了soa全部需求

是否收费，公司对技术费用的承受能力有多少

如今架构组成有大量的技术，每一个技术都收费的话，大部分初创公司基本直接死了，有钱的公司也扛不住这样量的收费。

是否有一样功能或在性能方面稍弱，基本功能其群，而且免费的技术。收费的项目可能有更好的性能，生态，技术支持，可是你须要吗？

oracle的强大路人皆知，收费挺不便宜的。做为通常的公司须要那么多功能的吗？ 结果是不须要。因此选择MySQL 是一个优质解决方案

若是收费，投入的资金是否回报高如投入

某金融公司想使用MySQL NDB解决分布式的问题，随着数据量的不断增长，服务实例愈来愈多，收费愈来愈贵，该公司团队以为出入不敷。

好比直接购买云服务，公司须要消息中间件，并且量不大。鸟菜啊就直接建议使用阿里云的商业版rocketmq。简单方面，不须要运维。.net团结接受了建议，使用了很长时间。效果很是好。量不大的应用都使用的阿里云商业版rocketmq,成本没有提升，解决了2我的的运维，管理，维护成本。

技术程度的定义，是否符合需求（基础功能），是否须要，须要程度，团队是否有对应的人员

是核心技术，仍是重要技术，仍是工具。注重是性能，仍是效率。技术做用方面。不一样要求的可能偏重就不同。若是你技术定位错了。

符合

一次错误的跟风， ——node.js 很火。被不少吹捧成在web领域拯救世界的语言。不少大公司的大牛面也在宣扬node.js在公司里面实践获得不少好处。 ——结果了，公司的架构组（我已经逃离了），就采用node.js。采用node.js干什么，实现api网关（也就是接口），把全部的java实现的接口，所有换成了node.js的实现。架构师把一个dome给演示给开发团队，说多简单，这多好，那多好，是时代的趋势等等（我并不知道）。开发团队热火朝天的在学习，修改接口。慢慢的出现了不少问题,有些问题搞了很久也没搞定（鸟菜啊，看了下，不难）。同时发现开发效率并不高，管理，运维十分艰难。一个月后，架构师隆重的宣布，放弃node.js的方案，一个开发团队十号人的一个月的努力没有了.........

须要，程度

某公司想作商品进行检索，百度了一下想使用lucene solr方案。团队里面没有人会这个套东西，先安排了一我的学习，部署，学习如何使用。在一遍招人熟练使用lucene solr的....... —— 问了下负责人，请问下商品有多少数据，活跃数据多少。 负责人：100万数据，活跃数据10万 鸟菜啊： 直接用MySQL 全文搜索。与 lucene的功能差很少。都是用的倒序索引，性能方面都差很少。数据量又不大，不须要分布式。何须了。团队里面又有MySQL dba，不用招人 负责人采用了建议,棉猴的回馈效果不错。

生态圈是否完善

一个拥有完善或者较完善生态园的技术，会让你技术落地，问题解决，运维变得很是简单。选择一个较完善的技术，是十分重要的。通常来讲 社区是否活跃，是否强大，使用群体是否有必定规模，大型公司，大规模，高并发等复杂环境的实践的技术，生态圈都比较完善。完善的生态圈，可让你的入门，学习，研究，扩展，运维，管理的成本大大的下降

不完善的技术

1. 刚刚出来的技术
2. 没有经历大规模时间的技术
3. 太偏的技术
4. 只针对一个方面，可能在其余方面十分欠缺。好比node.js

简要生态圈对比

1. python的生态圈取向是小型项目与运维方面，java的生态圈取向软件工程与分布式方面
2. MySQL有比较健全的生态圈，好比客服端，压测，备份，管理。在这些方面MongoDB很是弱，有些基本为零

选择重点特性，健全，完善的基础功能的技术，而不是盲目追求大而全，一站式解决方案

Tidb刚刚出来的时候，就一群人吹捧是比MySQL等等还要优秀的数据库，是一个解决一切问题的分布式数据库等等。 可是公司也面临数据库分布式的问题，而架构师与架构团队没法解决这个问题。Tidb的出现，立刻就去看文档，发现Tidb是分布式一站式解决方式，架构师简单搭建，能用以后，而后就让运维人员在测试环境搭建，结果由于Tidb实在太大，搭建了一个月（架构师的能力的确太差了），在测试的时候各类问题。最终直接放弃了。

须要与这门技术类型的定义是什么，一个类型与一个定义的技术只选择一个

好比在架构中已经存在了hibernate，可是你做为技术负责人感受hibemate在处理复杂的sql十分麻烦，经过研究发现spring-jdbc比较适合，也最简单。因而引入了spring-jdbc，可是不想大规模的修改代码，又不想放弃hibernate的开发效率，因而存在两种功能相同的技术框架。这样形成团队其余开发人，没法正确的定位那些业务，功能使用那个技术。出现使用混乱现象，代码可读性极差，问题定位慢等代价。

是否融入架构体系，是否对现有架构，设计，代码影响大，替换的代价是否能承受

很简单的一个例子，把MySQL替换从PostgreSQL，若是应用层所有是按照标准的sql语句，是没有问题的。可是分页操做是不同的。须要把全部的分页的sql修改测试

社区是否活跃，是否强大，使用群体是否有必定规模

社区活跃表明使用的人多，社区强大表明

某金融公司想使用MySQL NDB解决分布式的问题，NDB的问题挺多，用户群体没几个，国内的MySQL 大神没有一个深刻过，出现的问题没法解决。并且MySQL NDB的商业服务比较坑。最后把 MySQL NDB换回来了，innodb引擎了。

是否有大型公司，大规模，高并发等复杂环境的实践。

若是是bat，还有几家大公司，已经大规模，复杂环境进行的实践，那么基本表示这个技术在基本使用，性能方面。没有什么问题。有问题，大公司都遇到了，会提供大量的文档。基本把验证技术可行性，大量的bug，运维，使用方面都大量的经验，也会给。

开发者或者开发团队是否有商业支持或者属于商业公司

技术选型中，鸟菜啊认为，这点是十分重要的。优秀的开源技术，须要优秀的程序员，可能须要优秀的开发团队，这些优秀的程序员，都是人，须要生活，生活须要薪水，并且相对都比较高。稳定的生活，才能无虑的工做，保证开源产品的质量，保证人员稳定。也是这个缘由为何不少优秀的开源项目都是大型互联网或计算机公司产出的。

曾经是否在同样的环境使用，运用过某个技术，或相似的技术

有多个选择的时候，能够把本选择要点做为重要的选择因袭

选型者与团队，有足够的技术深度与技术广度，足够技术能力，编码能力，分析能力，问题处理能力。是否对选型的技术，深刻了解，对原理了解，扩展，阅读源码

没有足够的技术深度与技术广度，很难从上面的选择要点分析那个是对的，那是适合等等。鸟菜啊在快五年的架构生涯中基本没有选型失败的事情。很大部分是鸟菜啊有必定的技术深度与技术广度。

也许你技术选型对了可是只是简单的了解原理，没有足够技术能力，编码能力，分析能力，问题处理能力，也没法融入整个架构体系，没法深刻优化，扩展，维护等。也是一种很是严重的时候。发现瞎猫遇见了死耗子或者跟大公司或者大神走，选型了可是没法正确的使用技术，导致架构十分臃肿，庞大，难以维护，开发缓慢，问题定位困难等。

架构师与架构组把其余的选择都作了，可是没有达到这一条基本是空话。

架构师与架构组把其余的选择都作了，可是没有达到这一条基本是空话。

架构师与架构组把其余的选择都作了，可是没有达到这一条基本是空话。

那些方面能够下降入门，学习，研究，深刻，扩展，运维，管理的成本

1. 技术开源
2. 生态圈是否完善
3. 社区是否活跃，是否强大，使用群体是否有必定规模
4. 是否有大型公司，大规模，高并发等复杂环境的实践