technology selection

content/posts/arch/technology-selection.md

@@ -0,0 +1,41 @@
++++
+draft = false
+date = 2024-11-21T20:20:56+08:00
+title = "构建自己的框架去做技术选型"
+description = "构建自己的框架去做技术选型"
+slug = ""
+authors = []
+tags = ["系统架构"]
+categories = ["系统架构"]
+externalLink = ""
+series = []
+disableComments = true
++++
+
+技术选型无处不在，你可能需要选择一种类库、选择一个框架、选择一种语言、选择一种组件、选择一个架构模式、选择一种系统方案……。
+那么如何构建一个决策或思维框架去做技术选型呢？
+
+## 技术选型
+
+![](https://raw.githubusercontent.com/RifeWang/images/master/arch/technology-selection.drawio.png)
+
+如上图所示，这是我自己总结出来的一套框架。
+
+我把问题进行了层次结构的划分，从以下方面考虑：
+- `需求满足度`：可选项对当前业务或技术需求的满足情况，以及对未来潜在需求的支持程度，即“功能性”。
+- `非功能质量属性`：
+    - `性能`：几乎所有框架或组件都宣称自己是高性能。
+    - `高可靠/高可用性`：是否支持集群或主从结构，是否存在单点故障的可能。
+    - `可修改性`：是否能对 BUG 快速修复，是否支持扩展。
+    - `安全性`：是否有认证授权、追踪审计、数据加密等等安全特性。
+- `团队亲合度`：实施需要具体的人员，因此就有了：
+    - `开发成本`：研发对所选技术的上手程度、掌握情况。
+    - `运维成本`：运维管理的支撑难易。
+
+注意，以上只是我提供的一种框架，每个维度针对不同场景都是可以改变的。例如，如果对比的是开源组件，那么你很可能需要增加“成熟度”这一个维度。重要的不是那些条条框框，而是思考的方式。
+
+## 构建自己的框架
+
+为什么要做技术选型？在我看来有两个重要原因：辅助决策、达成共识。通过罗列各种指标，进行综合性打分，可以减缓过多的主观情绪对决策的影响。另外，技术选型也是在团队成员间达成一致的手段，这也是一种协作、协商的机制。
+
+你不需要生搬硬套各种技术选型的框架，更合适的方式应该是你进行“结构化”思考之后得到自己的层次结构图，这需要一些积累与刻意练习，但并不难。一旦你掌握了结构化的思维方式之后，在处理其它问题上也会游刃有余。所以，请你只参考，但构建自己的框架。