大家好呀，我是苍何。
在牛客上看到一条帖子，说“计算机就业，别卷绩点，这是最大的信息差”。觉得挺有感触的。
强如牛友次次上课第一排，年年奖学金，绩点高达 3.94，成绩甚至冲到了年级前三，在找工作时，一样面临学历、项目经历、实习经历的拷打，但唯独不问绩点，不问分数。
我觉得如果是单纯就业的话，大可不必去卷绩点，冲排名，因为大部分企业根本不会问你成绩，主要还是看项目经历，实习经历或者在校期间得过什么奖之类的。（当然如果是考研、留学这些绩点就有很大作用了）。
所以在学校有明确的规划就很重要了，是先就业还是考研，留学，这些最好在大一大二就做好规划，如果选择的是就业，在校期间我建议把重点放在项目经历上来，简历上也要多从项目上下手，别卷分数。
这次我们就以开源实战校招项目 PmHub 的技术架构选型开始说起，聊一聊在实际业务项目中如何做好架构的选型。
PmHub 开源项目一共经历了 2 次技术架构选型，因为一开始它是个单体 SpringBoot 版本应用，其采用 SOA 模块化架构设计，即按照不同的业务范围分不同的 Moudle，这也是单体应用中现在常见的设计思路。
后面我把他升级到了微服务版本，架构复杂性自然也飙升了一截。需要考虑服务网关、服务调用、服务认证、服务注册、熔断降级、监控及分布式事务等一系列问题。
经过慎重的思考和架构选型，最终确定如下系统架构：
服务中使用到的一些后端技术列表如下：
| 技术 | 名称 | 版本 | 官网 | |
|---|---|---|---|---|
| 1 | Spring Boot | 基础框架 | 2.7.18 | https://spring.io/projects/spring-boot |
| 2 | SpringCloud | 微服务框架 | 2021.0.8 | https://spring.io/projects/spring-cloud |
| 3 | SpringCloud Alibaba | 阿里微服务框架 | 2021.0.5.0 | https://github.com/alibaba/spring-cloud-alibaba |
| 4 | SpringCloud Gateway | 服务网关 | 3.1.8 | https://spring.io/projects/spring-cloud-gateway |
| 5 | MyBatis-Plus | 持久层框架 | 3.5.1 | https://baomidou.com |
| 6 | Redis | 分布式缓存数据库 | Latest | https://redis.io |
| 7 | RocketMQ | 消息队列 | 2.2.3 | https://rocketmq.apache.org |
| 8 | HuTool | 小而全的工具集项目 | 5.8.11 | https://hutool.cn |
| 9 | Maven | 项目构建管理 | 3.9.1 | http://maven.apache.org |
| 10 | Sentinel | 流控防护框架 | 1.8.6 | https://github.com/alibaba/Sentinel |
明确了项目最终使用的技术架构选型，你是否好奇我是如何做技术架构选型的呢？下面浅谈一些自己的经验。
业务项目一定是用来满足业务需求的，而技术架构是为了更好更高效的完成业务项目，所以业务需求是技术架构选型中最为关键的一步，直接决定了技术选型的方向和重点。
一般公司业务，需要了解公司所在行业的现状、趋势和竞争态势。例如，电商、金融、医疗等不同领域的需求和侧重点会有所不同。
还要理解业务模式，明确公司的业务模式， 是B2B、B2C 还是 C2C 等，这会影响系统的设计和功能需求。
拿 PmHub 为例，因为我们是开源项目，业务比较简单，主要是项目管理和流程管理相结合。那需要深入理解业务，还要从业务目标和功能需求入手。
业务目标大体为为长期目标和短期目标，长期目标是公司在未来3-5年内的战略规划是什么？如扩展国际市场、推出新产品等。
而短期目标是公司在短期内希望通过技术实现哪些目标？如提高销售、用户增长、提升用户体验等。
拿 PmHub 来说，短期目标是能尽快实现微服务改造落地，并能闭环现有所有业务功能，长期目标，是能更好的帮助学生将此项目写入简历，帮助他们拿到一个好的 offer。
功能可以分为基本功能和非功能需求。
- 核心功能：定义系统必须实现的核心功能，如用户注册登录、产品展示、购物车、订单处理等。
- 辅助功能：定义增强用户体验的辅助功能，如推荐系统、优惠券、用户评价等。
- 性能要求：定义系统在响应时间、吞吐量、并发用户数等方面的性能指标。例如，页面加载时间不超过2秒，支持每秒1000次交易等。
- 安全要求：定义系统的安全需求，如数据加密、身份验证、权限管理、漏洞防护等。
- 可用性要求：定义系统的可用性指标，如99.9%的系统可用率、故障恢复时间等。
- 扩展性要求：定义系统的扩展性需求，以便未来能轻松添加新功能或处理更多用户。
PmHub 这个项目的基本功能是一套完整的 CRM 系统，而核心业务功能是项目管理和流程管控，其他的如日志管理、系统管理等均属于辅助功能。
下图是典型的技术架构选型图：
所以大部分情况下，在做技术分析的时候大体也需要围绕经典技术架构来做分析和选型。
对于不同的场景，需要至少罗列 2 种以上技术栈，并需要分析其之间的优缺点和适用场景，如果是在公司团队，还需要评估现有团队的技术能力和学习曲线。
如果是个人，需要看哪个技术是自己擅长的， 或者学习成本低的，我们在做技术选型的时候，并不是完全会选择那些很时髦的但没经过验证的技术，也大概率不会选择自己不熟悉的技术。
真要选择这种自己不熟悉的技术，一定是要先去学习这个技术才行的。
拿 PmHub 中的用户鉴权来举例，现成的技术框架有 Spring Security 和 Shiro 完全可以实现我的需求，且我对这两个技术也比较熟悉，所以在 monitor 监控中心的鉴权，我就直接用了 Spring Security。
而微服务的整体鉴权，我却选择了自定义注解配合网关鉴权，其实是有目的的，因为该项目的长期目标是帮助学生体现在简历上，所以需要增加亮点，
另外通过自己实现鉴权，也能更加理解鉴权框架的内部原理了，其实都差不多的。
选择技术选型的时候，需要选择能够支持业务增长的架构，而且确保所选技术能够满足性能需求，例如高并发、低延迟等。
选择技术框架是必须满足安全性和可靠性，一些有严重漏洞的框架，我们是坚决不会选的。
- 确保技术架构符合行业安全标准和法规要求。
- 评估技术的可靠性，避免单点故障。
- 采用模块化设计，确保系统的可维护性和可扩展性。
- 使用分层架构，例如MVC模式，明确各层的职责。
- 保持各组件之间的松耦合，减少相互依赖。
- 确保每个模块内部具有高内聚性，实现特定功能。
设计架构的时候，需要考虑实际的资源成本，考虑开发和部署的初始成本，包括硬件、软件和人力成本。评估长期运营和维护成本，例如服务器费用、第三方服务费用等。
比如在 PmHub 中，文件存储，我就没使用阿里云存储 OSS，而是自己实现了一套分布式文件存储系统，主要还是为了节省成本。
做架构设计是一件复杂的事情，有人觉得这是架构师该做的事情，但其实我觉得，架构设计是每一个开发都必须掌握的技能，通过架构设计，我们才明白我们做的系统究竟如何体现价值。
以上是关于技术架构选型的一些个人经验，感谢您的阅读。