技术选型：从团队与部署约束出发

新项目技术栈的确定，除了技术本身的特性，更需要考虑开发团队的情况。最近的在为新项目做技术调研，这里记录一下相关的信息和思考。

---

写在前面

技术栈主要分为四大类：

1. 应用和数据
2. 工具
3. DevOps
4. 商业工具

本文主要着眼于第一和第三点，其他两点根据不同国家地区和不同团队习惯可以很方便地进行切换，这里就不赘述了。

一些思考

首先要强调的是，不同团队不同项目有不同的方案，这里只是我一天的思考，后面肯定有好多地方需要调整，总体来说，还是起到抛砖引玉的作用，希望各路大神老司机带带我。

先简单说下背景，这个项目之所以有比较大的自由度，主要是因为基本上可以算作是一个全新的业务，没有太多的历史包袱。虽然其他项目有可以参考的代码，不过量不大，即使要迁移，也可以在很短时间完成。另外一个值得注意的地方是具体的实地测试可能需要在全球进行，有很多开发外的因素不得不考虑进来（比如说法务相关的数据安全性等等）。考虑到远程部署远程测试的客观条件，在选择相关技术的时候我给自己定的原则就是：

轻量、高并发、易拓展、易部署、易排查

解释一下：

• 轻量：一直以来我不太喜欢特别重的框架，一是学习曲线陡峭，二是很多东西框架代劳，看起来简单，但真正需要根据需求变动修改的时候，可能会有意想不到的问题。因此，我更希望用一个灵活大于条条框框的框架（甚至不用框架也行）
• 高并发：在初步概念测试的前提下（没有统一标准，各个公司都在搞自己的一套），没有办法争取到很多资源，所以希望能在有限的条件下，提供更好的服务质量，天生支持高并发的语言是我更倾向的
• 易拓展：业务量上来之后如果需要增加机器，希望能够简单配置即可
• 易部署：能够轻松跟 Jenkins 等持续集成工具配合，或者直接简单粗暴可以通过配置工具部署，在这一步步骤越多就越容易出问题
• 易排查：出了问题能够快速定位，这又回到框架的问题，用框架后增加的复杂度，更不容易快速准确定位问题

这些标准是当时项目约束下的取舍，并非越轻量越好。最终还需要用原型验证实际负载、部署流程和故障排查成本，再决定技术栈。