PmHub是如何做架构选型的？
PmHub 一共经历了 2 次技术架构选型，因为一开始它是个单体的 SpringBoot 版本应用，采用的是 SOA 模块化架构设计，即按照不同的业务范围分不同的 Moudle，这也是单体应用中常见的设计思路。
技术派项目就是单体版的，因为原计划 2 期做微服务版本，因为备案被小人恶意投诉，后来就搁浅了。
但微服务的学习需求一直都在，VIP 群的很多小伙伴都吵着要学，所以我后来就把 PmHub 升级到了微服务版本，架构复杂性自然也飙升了一截。需要考虑服务网关、服务调用、服务认证、服务注册、熔断降级、监控及分布式事务等一系列问题。
经过慎重的思考和架构选型，最终确定如下技术选型和架构：
服务中使用到的一些后端技术列表如下：
明确了项目最终使用的技术架构选型，你是否好奇我是如何做技术架构选型的呢？下面浅谈一些自己的经验。
明确业务需求
项目一定是用来满足业务需求的，而技术架构是为了更好更高效的完成编码工作，所以业务需求是技术架构选型中最为关键的一步，直接决定了技术选型的方向和重点。
一般的公司业务，需要了解公司所在行业的现状、趋势和竞争态势。例如，电商、金融、医疗等不同领域的需求和侧重点会有所不同。
还要理解业务模式，是 B2B、B2C 还是 C2C，这会影响系统的设计和功能需求。
拿 PmHub 为例，因为我们是开源项目，业务比较简单，主要是项目管理和流程管理相结合，就要从业务目标和功能需求入手。
分析业务目标
业务目标大体分为长期目标和短期目标，长期目标是公司在未来 3-5 年内的战略规划是什么？如扩展国际市场、推出新产品等。
而短期目标是公司在短期内希望通过技术实现哪些目标？如提高销售、用户增长、提升用户体验等。
拿 PmHub 来说，短期目标是尽快实现微服务改造落地，并能闭环现有的业务功能。长期目标，能更好的帮助学生党和工作党将此项目写入简历，帮助他们拿到一个好的 offer。
确定功能需求
功能可以分为基本功能和非功能需求。
基本功能
- 核心功能：定义系统必须实现的核心功能，如用户注册登录、产品展示、购物车、订单处理等。
- 辅助功能：定义增强用户体验的辅助功能，如推荐系统、优惠券、用户评价等。
非功能需求
- 性能要求：定义系统在响应时间、吞吐量、并发用户数等方面的性能指标。例如，页面加载时间不超过 2 秒，支持每秒 1000 次交易等。
- 安全要求：定义系统的安全需求，如数据加密、身份验证、权限管理、漏洞防护等。
- 可用性要求：定义系统的可用性指标，如 99.9%的系统可用率、故障恢复时间等。
- 扩展性要求：定义系统的扩展性需求，以便未来能轻松添加新功能或服务更多用户。
PmHub 这个项目的基本功能是一套完整的 CRM 系统，而核心业务功能是项目管理和流程管控，其他的如日志管理、系统管理等均属于辅助功能。
技术分析
下图是典型的技术架构选型图：
所以大部分情况下，在做技术分析的时候也需要围绕经典的技术架构来做分析和选型。
考察技术栈
对于不同的场景，需要至少罗列 2 种以上技术架构，并需要分析它们之间的优缺点和适用场景，如果是在公司团队，还需要评估现有团队的技术能力和学习曲线。
如果是个人，需要看哪个技术是自己擅长的， 或者学习成本是比较低的，我们在做技术选型的时候，并不需要选择那些很时髦的但没经过验证的技术，也不需要选择自己完全不熟悉的技术。
如果真要选择自己不熟悉的技术，一定是要先花时间调研和学习。
拿 PmHub 中的用户鉴权来举例，现成的技术框架有 Spring Security 和 Shiro，我对这两个技术也比较熟悉，所以 monitor 监控中心的鉴权，我就直接用了 Spring Security。
而微服务的整体鉴权，我却选择了自定义注解配合网关鉴权，因为 PmHub 的长期目标是帮助大家争取到更多的面试机会，所以需要增加亮点。
另外，通过自己实现鉴权，我也能更好地理解鉴权框架的内部原理。
可扩展性和性能
技术选型的时候，需要选择能够支持业务增长的架构，而且确保所选技术能够满足性能需求，例如高并发、低延迟等。
安全性和可靠性
技术框架是必须要满足安全性和可靠性的，一些有严重漏洞的框架，我们是坚决不能选的。
- 确保技术架构符合行业安全标准和法规要求。
- 评估技术的可靠性，避免单点故障。
架构设计原则
模块化和分层设计
- 采用模块化设计，确保系统的可维护性和可扩展性。
- 使用分层架构，例如 MVC 模式，明确各层的职责。
松耦合和高内聚
- 保持各组件之间的松耦合，减少相互依赖。
- 确保每个模块内部具有高内聚性，实现特定功能。
资源评估
设计架构的时候，需要考虑开发和部署的初始成本，包括硬件、软件和人力成本。评估长期运营和维护成本，例如服务器费用、第三方服务费用等。
比如在 PmHub 中，文件存储我就没使用阿里云的 OSS，而是自己实现了一套分布式文件存储系统，这样可以带着大家去学习分布式文件存储的原理。
做架构设计是一件复杂的事情，有人觉得这是架构师该做的事情，但其实我觉得，架构设计是每一个开发都必须掌握的技能，通过架构设计，我们才能明白我们做的系统究竟如何体现价值。
整体交互方案
接下来我们需要将上面的方法论以及业务拆分后的微服务串连起俩，看一下 PmHub 是如何运转起来的。
整体交互设计
对于 PmHub 的项目管理以及流程管控，其交互流程大概是这样的：
用户添加项目，设置任务并制定任务执行人，执行人拿到任务后进行任务状态变更，如交付物上传，其他同类型用户可以对此发表评论，完成任务后可以发起完成审批，任务发起人（通常是项目经理）审批通过后，任务的流程就完成了。
登录交互方案
登录基于传统的用户名和密码实现，下面是具体的交互流程图，大家可以对着代码看看，理解会更深刻！
消息通知方案
我们抽离了消息通知公共组件到 pmhub-base-notice，支持发送消息到企业微信等第三方平台，下面是一个具体的交互流程，当然这部分的细节实现可以参看：
✅PmHub 整合 Rocketmq 实现审批流消息推送（👍 必看）
前端技术架构
PmHub 中使用到的前端技术列表如下：
| 技术 | 名称 | 版本 | 官网 | |
|---|---|---|---|---|
| 1 | JS 框架 | Vuejs | 2.6.12 | https://cn.vuejs.org |
| 2 | UI 框架 | element-ui | 2.15.10 | https://element.eleme.cn/2.0/#/zh-CN |
| 3 | Ajax 请求 | Axios | 0.24.0 | https://axios-http.com/ |
| 4 | 前端路由 | Vue-router | 3.4.9 | https://router.vuejs.org/ |
| 5 | 前端脚手架 | Vue-cli | 5.0.8 | https://cli.vuejs.org/ |