技术架构师考核指标架构师技术选型

转载

mob64ca140f9cec 2023-10-09 08:55:04

文章标签 技术架构师考核指标运维 javascript python ViewUI 文章分类 架构后端开发

前言

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

技术选型原则

开源,是否在持续维护中

开源之后，不害怕闭源

不用害怕以后项目会闭源而出现各种问题，如果有一个优秀的项目开源以后，很大的用户群体，大型互联网公司使用过，那么不用担心闭源问题带来的后果，闭源之后大型互联网会在原有的基础上维护或者创新一个类似的。
开源项目会有更多人与团队参与，社区十分会比较活跃，生态圈会慢慢完善
鸟菜啊个人认为这点非常重要，开始使用某个技术的时候，可能不需要源码。时间长了会暴露大量的问题出来，这个时候请人不如求己。

当需要在某个技术上进行扩展的时候，如果不了解原理与实现，可能造成严重的问题。
深入源码，可以了解实现，正确的使用这个技术。
出现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，不用招人负责人采用了建议,棉猴的回馈效果不错。

生态圈是否完善

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

不完善的技术

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

简要生态圈对比

python的生态圈取向是小型项目与运维方面，java的生态圈取向软件工程与分布式方面
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，运维，使用方面都大量的经验，也会给。

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

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

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

有多个选择的时候，可以把本选择要点作为重要的选择因袭

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

没有足够的技术深度与技术广度，很难从上面的选择要点分析那个是对的，那是适合等等。鸟菜啊在快五年的架构生涯中基本没有选型失败的事情。很大部分是鸟菜啊有一定的技术深度与技术广度。
也许你技术选型对了但是只是简单的了解原理，没有足够技术能力，编码能力，分析能力，问题处理能力，也无法融入整个架构体系，无法深入优化，扩展，维护等。也是一种非常严重的时候。发现瞎猫碰见了死耗子或者跟大公司或者大神走，选型了但是无法正确的使用技术，致使架构十分臃肿，庞大，难以维护，开发缓慢，问题定位困难等。

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