HC小区物业管理系统——学习01_项目架构
如有侵权，请联系删除，本文章仅用于技术分享和学习，如理解有误，欢迎讨论
HC小区物业管理系统是gitee上开源的GVIP项目，对于在校生来说，发现是非常值得学习的
接下来会持续更新关于hc小区物业管理系统的学习笔记
整体项目架构
对于普通的，从b站视频上某ma视频学习路线来学习的Java生来说，该项目架构就显得有一点点看不懂，如下图
大家学习过微服务的应该还能看懂一部分，service-开头的包是微服务以业务区分的包，那java110-开头的包呢？
这边作者在b站上的二开视频中介绍了，java110-开头的会被提前编译成jar包供以下的服务使用，但是对于跟着b站上单单学习的同学来说，这好像也不好理解，我问了一下ai，ai是这样介绍的：
本架构遵循「平台 + 插件」或「框架 + 业务」模式。
java110-*系列模块构成 MicroCommunity 核心框架，提供标准化的运行环境；而service-*模块则是具体的 业务实现层
可以理解出，其实java110-开头的包是吴老师（本项目主要开发者）和java110团队为本项目单独设计的框架/平台，就像pom文件中引入的依赖一样，是适配HC而单独开发的框架层。这样的架构有诸多好处
- 解耦与聚焦 ，业务开发无需关心底层配置，可以更加关注业务代码开发，也间接规范了开发的一些规则，让业务开发更加统一迅速
- 版本隔离 ，框架可以单独升级，业务按需更新版本即可，不用动全身
- 编译性能 ，框架为预编译的模块，服务修改开发后可以单独重新运行，减少了编译时间，提升构建速度
微服务模块
微服务是本项目业务方面的架构，吴老师在二开视频中介绍这样主要是为了业务的方便拓展，因为本项目本来客户应该也是物业公司，微服务对于部署和服务器成本也稍大，后期项目也是更新了springboot方式启动，关于微服务是如何提供boot方式启动的，也是一个值得学习的点，这边使用ai简单分析了一下，就是加了一个springboot的聚合模块，通过将其他的服务居合道pom文件中，然后将启动类的@SpringBootApplication的scanBasePackage的包路径属性加上服务包,这样所有的Bean都加载到spring上下文了，然后完成boot方式启动....
注册中心
本项目的微服务的主要目的也是为了业务拓展，所以采用了轻量的嵌入式的注册中心，即eureka的方式， 相比于nacos，eureka的方式更加轻量，没有nacos那样的动态配置中心，动态DNS那样的更多功能，仅仅用于服务注册发现。
消息队列
HC不知道由于什么原因，将Kafka组件去掉了，换成了轻量的activeMQ，应该是本身项目就讲究轻量部署，Kafka会增加部署成本吧。
网关
网关的话得感叹吴老师及他的团队强大，HC是自己开发了一套网关，本人经过研究与ai辅助，发现其实现了很多东西，包括但不限于统一请求上下文，自研的类似zipkin微服务间的链路追踪，安全校验和加密，基于RestTemplate微服务分发调用等等,值得研究的地方还有很多
其他组件
有关于服务保护限流如sentinel，Hystrix本项目均没有做
好像本系统在微服务模块堆砌的组件并不多，但也是实际业务考虑，毕竟微服务主要也是为了拓展业务，并不是做多大的并发。
最后，其实前几周就开始一直在搜索关于本项目资料，也逐渐尝试部署，目前部署完毕，已经开始研究有一段时间了，希望可以从中学习到很多开发知识！
如对本系统有所误解，或者表述不正确的地方，请私聊或在评论区留言，文章目的出于学习和分享