學生會管理系統-后端個人總結
一、引言
1.0 項目最后源代碼整合:
-
學生會管理系統web端:傳送門
-
學生會管理系統小程序端:傳送門
-
學生會管理系統app:傳送門
-
學生會管理系統后端:傳送門
-
前期接口文檔以及需求文檔:傳送門
-
后端后期spring整合swagger文檔:傳送門
-
分布式部分
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的鏡像源是在國外，所以國內下載服務器需要配置ssr進行下載處理(但說實話，服務器配置代理實在太麻煩了)，所以我最后選擇的是切換成國內的鏡像源進行下載，但是其中也找了好長時間，(包括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.加油！
二、對課程的建議和意見
-
不得不說，朱勇老師的軟工課是一段讓人很享受的時光，不僅學到了很多(我想這就是一種試錯),但也因為享受，在我看來,課程還是存在有一些小問題。
-
例如，在進行需求開會的問題上，理論上，從軟件需求的角度看，應該不止有老師，本組成員參與，可能在進行小組抽選后，讓被選中的小組進行課堂展示，從而進行加減分，這會是一個更好的選擇，這樣不僅各個小組都會為此准備，並且各個小組的選擇和做法也會被所有學生進行學習交流。現在的機制雖然滿足了所有小組討論需求都有老師參與，但同時換一個角度看，這樣做不僅使得老師十分的疲憊，而且需求有時候也並不是十分的完善。
-
此外，在課程中，最讓我感到點睛的一段經歷就是團體項目之前的那一個較完善的個人項目體驗，但同時這也花去了大量的時間，如果可以縮短這個過程(比如說開課的時候便說明個人小項目的立意,讓學生進行思考),我覺得可能會是個更好的選擇。