给新复活的精弘论坛物色了一段时间的技术和架构选型，总算是有了一些收获，可以产出一篇博客用以内部技术分享了。
技术栈 链接到标题
- 语言：Java
- 版本：JDK17
- 开发框架：Spring Boot
- RPC框架：Dubbo
- RPC通信协议：triple
- RPC API：Protobuf(IDL)
- 前后端交互协议：HTTP
- 服务注册中心：Nacos
- 配置中心：Nacos
这一套技术选型和当今互联网大厂的 Java 技术选型高度一致，这样的一个实战项目十分符合之前选择采用 Java 的原因。
一些文档 链接到标题
网络流量传输架构图 链接到标题
上图是直接从 Dubbo 文档里偷出来的，刚好我们的论坛架构和图里的完美适配，前后端是通过 HTTP 协议进行交互的，而后端的多个微服务之间是通过 triple 协议进行交互的，这样既可以享受到 HTTP 的灵活性，也能保护好我们的系统，避免一些不希望外部访问到的敏感接口被暴露到外网。
讲到这刚好还能聊聊我作为一个退休老登对精弘技术部各个业务发展的想法。我的短期期许是论坛可以按期上线，并且可以用上本文提出的所有架构，可以成为精弘服务端转向统一的微服务的最佳样本。
中期期许是可以改造一下已有的用户中心（对应的负责人已经开始了）、问卷系统和微精弘，可以把它们也纳入微服务的版图之内，做到系统间信息的互通（例如论坛首页可以通过微精弘的接口之间获取当日课表）。把所有鉴权功能都收口到用户中心是我们一直想做的事情，现在几乎每一个系统都独立接入了统一登录系统，三套逻辑维护起来实在是太费劲了，收口到一处后就可以不用担心该了这里没改那里了。
长期期许就没上面两者那么清晰了，只能模糊的希望精弘的若干系统可以一直有服务全校师生的价值，我们的技术可以与之俱进，我们可以获得各个大厂的人脉。
精弘整体项目架构图 链接到标题
整体架构允许服务端各个服务之间通过 RPC 相互调用，践行高内聚低耦合的开发理念。
各个系统至少需要由两台虚拟容器组成集群，避免我们后续发布过程中影响用户体验，也可以降低我们出现 fgc 甚至宕机时对我们服务的影响。
引入 Sentinel 和 Druid 两个监控系统，全面监控我们的每一个系统、每一个接口、每一个数据库、每一个数据表，让我们的成就能有数字来支撑，让我们的稳定性能用现实的工具来捍卫。
所有系统均接入消息队列，给系统内、系统间的子系统节藕提供另一种可能，也希望能够借助消息队列的削峰填谷效果来提升我们的稳定性。
最后就是系统接入 ELK 日志系统，给我们排查和监控提供足够的信息，避免问题排查摸不着头脑。
论坛服务的项目代码架构 链接到标题
API 模块作为要被其他系统引用的部分，需要严格控制大小，基本上只允许引用 protocol 相关依赖已经 Lombok 等工具，模块内只写接口的声明和出入参声明。
common 模块作为整个系统的基建，包含一些注解、常量、枚举（包括异常枚举）的定义，还有常用的工具类（包括外部 HTTP 接口调用工具）和全局异常捕获与过滤。
service 模块和下面的 A、B 功能模块在功能上是一致的，都是大部分接口的业务实现，可以认为这里是唯一和数据库交互的地方。而 service 和 A、B 的区别就是领域划分了，service 是本项目最为主体的业务，放到论坛这个场景下就是对帖子的操作，而 A、B 等就是一些主体外的其他子系统，例如徽章积分子系统、排行榜子系统等。
最后的 start 模块则是暴露给前端的 HTTP 接口的定义和实现，这一层可以是调用 API 模块里定义的那些方法，也可以根据实际逻辑直接调功能模块里的方法了。