学生会管理系统后端架构

一、引言

1.0 项目最后源代码整合:

• 学生会管理系统app:

• 学生会管理系统后端:https://github.com/zhang-wangz/ruangong-backen

• 学生会管理系统web端:https://github.com/LinXS597/SUManager

• 学生会管理系统小程序端:https://github.com/fireworks-EX/StudentUnion

• 前期接口文档以及需求文档:https://www.showdoc.cc/531866446040267?page_id=3144694473293441

• 后端后期spring整合swagger文档:http://api.wangz.online/api/swagger-ui.html

  分布式部分

• k8s管理界面:https://139.9.90.185:31175/

• dubbo管理界面:http://139.159.248.231:8080/dubbo-admin-2.6.0/

1.1 编写目的

• 描述整个软工项目下来自己亲身感受，和对课程的意见和建议，以及这一学期在课程中学到的东西，和遇到的问题以及对各种问题进行的解决描述。

1.2 编写背景

• 在此之前学习了java的springboot项目编写语法，并且有过3个有关的编写经验,所以主动承担了整个小组的后端编写任务，在此过程中因为兴趣学习了kotlin语法，所以一部分功能使用kotlin进行编写完成以加快编写速度和代码篇幅，过程中也加入了swagger进行调整接口文档(因为最后编写任务的繁重)，并且同时系统作为分布式系统，配置了k8s和dubbo进行完善分布式架构，同时对数据库进行配置为分布式mysql，以防mysql宕机使得整个系统挂掉。因为获取速度的关系，配置了redis作为整个后台的缓存机制。最后，配置成多模块，分布在不同的云服务器中缓解单服务器的压力，同时使用zookeeper作为注册中心进行多个模块间的通讯交互。

---

二、后端编写总结

2.0 后端中的java部分

• 因为最熟练并且尝试最多的是java语言，所以最开始就使用了java语言，依据之前的经验和编写的工具类，前期的进度一直很迅速,但同时也因为进度不同步使得那个阶段整个小组的编写十分的痛苦，所以在写的过程中，逐渐开始放缓了编写的步伐，并且开始去注重整个后端源代码的细节和注释部分，顾及大家的平均速度，使得整个项目进入飞速进展期。

2.1 后端中的kotlin部分

• 这是写到程序中期的时候，因为进入核心功能逻辑编写区，并且java代码处理逻辑的逐渐复杂，同时又因为kotlin的便捷和简便性，在中期的时候使用kotlin进行改写(真的悔恨当初)，但我其实也不清楚应该说这个改写是好是坏，好的一方面是使用kotlin之后代码的逻辑编写的确十分的简洁，无论是kotlin的高级扩展方法apply,use,let,alse,还是空值处理的 ‘?’ 形式，都极大的促进了项目的速度，坏的一面也很明显，因为是中期进行的改写，所以在兼容性上的处理花费了我大量的精力，并且其作为一门新晋语言，在后期分布式的兼容性上也很让人头疼，中间遇到了很多问题,比如，lateinit初始化，在分布式dubbo中，会报一个反序列错误问题，这个反序列报错最后只能通过java反射机制进行重新映射才解决， 还有map没有继承Serizable，使得传输一直报错，直到最后重写了原生类继承这个接口,才终于没报错。

2.2 后端中的swagger部分

• 由于初期使用showoc进行需求填写，为了统一也使用其进行了api接口编写，但是后期细节化的时候，一下子二三十个接口的加入便使得维护起来十分的麻烦，不仅需要添加新的，还要对之前的进行修改，所以为了便捷，后端加入了生产期间使用的动态接口swagger文档。而且在开发完成后也可以随时进行关闭，推荐使用,开发利器。
  

2.3 后端中的dubbo部分

• 因为考虑到工业使用问题，进行了分布式整合(又是后端的活!-.-),先是对springboot进行dubbo进行整合,所以得对原先的所有工程进行模块化，而且最重要的是dubbo是alibaba的aop架构，结果最显然的就是我的后台项目需要进行彻底的重构(说实话，当时人傻了)，还好最开始的springboot结构划分写的与之要求不大，新增了dto，exception(自定义运行错误类),vo层之后，并且对之前的service进行完整的重构，终于满足了需求，现在的缺点就是导致repo(dao层内容)与数据库的交互显得有些繁琐(就是请求的时候可能速度会慢一点)。但也完成了初步的分布式架构，分成了common，provider，consumer三个模块。同时使用docker配置zookeepr组件进行三个模块间的通讯，最后的成果就是可以使用dubbo进行负载均衡，访问请求等容错配置，而且不用担心服务会宕机。
  
  

2.4 后端中的Kubernetes(k8s)部分

• 这个模块也是实现起来最麻烦的一个部分，因为k8s的镜像源是在国外，所以国内下载服务器需要配置科学上网进行下载处理(但说实话，服务器配置代理实在太麻烦了)，所以我最后选择的是切换成国内的镜像源进行下载，但是其中也找了好长时间，(包括docker打包，上传，下拉，个人仓库等一系列,真的很头秃,googlemirror这是我找到的最终的镜像仓库，万分感谢维护这个仓库的社区大佬),并且配置了dashborad进行可视化管理。其中mysql和redis也处于这个架构组件中，最后是两个service暴露给外部进行访问。redis-cluster(配置使用k8s的cm(configMap)为集群的config)的配置难点主要在于密码的设置部分，如果不设置密码就进行配置的话，会使得外部无法访问这些k8s中的pods,设置密码的话会抛出no auth的error，最后的解决方案是进行无密码配置，然后通过k8s dash-board可视化配置所有实例的集群密码(’人工‘智能-.-),mysql则是为了方便没有使用k8s里的cm组件，而是docker build了一个自己的image进行配置，最后终于完成了，顺便也学习了springboot的type为redis的cache机制。

2.5 总结最后部分

• 写到这边其实就想说，整个项目下来，学到了很多，也犯了很多不该犯的错误，吃了很多苦，但最后这个苦是甜的，所以don‘t give up,maybe now you aren’t the brightest star, but work it,we finally will succeed.加油！

---

二、对课程的建议和意见

• 不得不说，朱勇老师的软工课是一段让人很享受的时光，不仅学到了很多(我想这就是一种试错),但也因为享受，在我看来,课程还是存在有一些小问题。

• 例如，在进行需求开会的问题上，理论上，从软件需求的角度看，应该不止有老师，本组成员参与，可能在进行小组抽选后，让被选中的小组进行课堂展示，从而进行加减分，这会是一个更好的选择，这样不仅各个小组都会为此准备，并且各个小组的选择和做法也会被所有学生进行学习交流。现在的机制虽然满足了所有小组讨论需求都有老师参与，但同时换一个角度看，这样做不仅使得老师十分的疲惫，而且需求有时候也并不是十分的完善。

• 此外，在课程中，最让我感到点睛的一段经历就是团体项目之前的那一个较完善的个人项目体验，但同时这也花去了大量的时间，如果可以缩短这个过程(比如说开课的时候便说明个人小项目的立意,让学生进行思考),我觉得可能会是个更好的选择。

​