-
技术开放性（开源or闭源）
开源意味着，如果有一天你遇到了一个Bug，你至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统火烧眉毛的问题，而不是束手无策地等待开发者不一定什么时候发布的下一个版本来解决
-
开源社区是否活跃
大部分遇到的 Bug，其他人可能早就遇到并且修复了，你在使用过程中遇到的一些问题，也比较容易在社区或者通过搜索找到类似的问题和解决方案
-
学习和维护成本
即使开源，如果实现的编程语言是相对非常冷门的语言，或者跟自身团队的主要技术栈不match，那么学习和维护成本也会比较高
-
与周边生态的集成和兼容
因为系统是由不同的部分组成的，不同部分需要相互交互和协同，因此不同部分的技术选型需要考虑互相的兼容性，比如Kafka和Flink 就有比较好的兼容性，Flink内置了Kafka的Data Source，使用Kafka就很容易作为Flink的数据源开发流计算应用
-
对原有系统代码的侵入性：
如果需要对原有系统代码做较大的改动，则可能会引入风险，进而会对业务造成影响；
举个🌰：
- 如果技术选型的场景是要支撑成熟核心业务，需要重点关注稳定性，那如上5点需要重点关注
- 1.1 技术开源和社区活跃，帮助出现问题的时候能够快速定位和解决问题；
- 1.2 与周边生态的兼容，帮助降低技术集成出问题的概率；
- 1.3 尽量对原有代码低侵入或无侵入，降低对原有业务的影响；
- 1.4 学习成本即使高一点，如果上述三点比较适合，那这一点也不会是突出的问题；
- 如果当前是想做一个创新业务的探索，那需要的是快速试错，关注的是效率，稳定性则其次，因此需要考虑选型技术是否足够轻量级，学习成本是否足够低，开发效率是否足够快；
-
启动应用是否快以及所需要的资源多少（cpu、内存等）：java其实就是一个比较重的语言，应用启动需要jvm以及依赖基础类库；
-
侵入程度的轻重：是否需要实现框架的接口或继承抽象类，这意味着需要实例化大量的类并注册到应用中；
-
开发方便性：
- 3.1 依赖其他资源的多少，是否可独立使用 vs 依赖容器或者很多其他类库
- 3.2 是否能够快速的开发、调试、测试、部署和运行；