技术选型讨论
背景
2022.01月会上,技术委员会提出公司存在多个技术栈,部分服务技术选型太随意。需要在公司层面提供一套可行的标准和方案供落地。
现状
技术栈
- java技术栈
- springboot
- Springmvc(号码、u3、jump)
- springcloud(wifi/近场)
- springboot+dubbo+thrift+部分springcloud组件(电商)
- Vertx(vert.x是Eclipse软件基金会顶级java开源项目之一,它基于netty的、运行在jvm之上的、支持多种编程语言的高性能异步、非阻塞、响应式全栈java web框架。如:发送号码数据至oppo服务 )
- go技术栈
- dot埋点平台
- 日志归档
- python技术栈
- 运维工具
- 测试
- PHP技术栈
- push admin管理平台
- 官网
- esp部分老服务
- 前端技术栈
- Vue
- Nodejs(官网)
- 算法
- 大数据
中间件
- redis
- mysql
- Postgresql(kong网关)
- mongo
- kafka
- elasiticsearch
- memcached
- nacos注册中心(esp、电商)
- zookeeper(电商)
- apollo配置中心
其他
- 网关
- kong
- Apisix + etcd(esp部分服务)
- 监控
- prometheus
- skywalking
- kubernetes
- 云基础服务(cls…)
问题
- 技术人的自嗨
- “面向简历”的决策
调研
观点:技术选型的4个参考原则
原则 1:能否简化开发任务?
这条原则显而易见,如果选择的技术无法帮助我们高效地达成目标,似乎没有理由去选择它。注意这里的关键词:简化。完成开发任务的手段并不是唯一的,在众多手段中间我们只关心哪个能够让我们生活得更容易。
同时,这里还要避免一个不那么显而易见的陷阱:虽然简化了手头的任务,但带来了其他方面的复杂性。比如,引入 Kafka 确实带来了一系列的好处:流量削峰、简化了任务分配和服务异步化等等,但由此也带来了一系列其他的复杂性,比如:运维的复杂性和事务的复杂性。那么,作为决策者就要评估是否需要这样一个复杂的方案,是否采用简单地方案就能完成目标,如:日志表 + 定时任务。
原则 2:是否符合组织内的主流技术路线?
大多数组织都会有一个主流的技术路线,技术团队如果采用的技术五花八门,会大大增加技术管理的成本。技术路线,是在进行技术选型时必须要面对的问题,尽可能地选择符合公司技术路线的技术或工具,这样有助于工作的快速推进。
原则 3:是否普及程度高或者学习曲线平缓?
普及程度高,有利于很快找到合适的人直接上手开干;学习曲线平缓则有利于在缺人时快速将现有人员切换到现有赛道。
原则 4:能否得到有效地支持?
这里的支持可以来自于两方面:外部和内部。能够方便地获得外部支持一方面说明了项目的普及程度,另一方面也反映了项目的活跃程度。前者的好处在上面已有说明,至于后者,则说明项目在与时俱进,对于新出现的使用场景大概率有较好的支持
观点:技术选型需要考虑技术维护成本
常见的技术维护成本有如下四个方面,依次是:
技术选型成本。
这是指你在做技术选型的时候,选择不成熟的技术所带来的成本。越成熟的技术,其技术实现成本和人力成本都是相对要低的,但是并不是说,选择新技术就一定不划算,只要考虑到成本和风险,才能做出合理决策。
技术升级成本。
这是指在评估技术方案的时候,其兼容性和扩展性水平带来的后期升级的难度和成本。
问题排查成本。
在做技术实现的时候,要特别关注后续的问题排查。好的技术实现,分分钟可以排查出问题原因;而不好的技术实现和方案,查一个问题可能需要花上几天时间,成本差异不可同日而语。
代码维护成本。
在编写代码的时候,要记得代码是要有可读性的。这体现在别人升级代码要花多长时间才能看明白,修改起来是否简单、安全。
观点:技术选型的关键要素
- 任何脱离业务的选型,都是耍流氓
- 早期不建议自研
- 擅长什么用什么
- 技术栈建议收敛
- 不自研,浅浅封装
- 规模扩大,适当造些轮子
讨论
-
技术栈收敛
- 官网改造(废弃PHP技术栈)
-
关键项目back-up
-
技术立项流程
-
技术立项评审