一個失敗的微服務項目,這是我項目的總結.失敗的主要緣由是對微服務的濫用,本文將總結微服務在本項目中暴露出的缺點前端
項目簡介
這是一個休息遊戲項目,主線是餵養一隻可愛的小狗, 經過玩內置小遊戲,或者作任務積累狗糧.在整個過程當中會隨機掉落紅包, 紅包能夠之間兌換少許RMB,遊戲以用戶點擊廣告做爲主要收入, 用戶轉化是另外一部分收入vue
項目概況
項目分遊戲端和管理端 遊戲端:java
- 遊戲大廳(主界面,包含:玩家信息\邀請\站內信\成長記錄\簽到等)
- 排行榜
- 幸運大盤
- 成長任務
- 多款小遊戲 管理端:
- 基礎權限管理
- 用戶管理
- 提現
- 報表
- 版本管理
- 廣告與渠道
- 維護
人員配置
策劃 x2 美術 x3 音效 x1 遊戲前端(Cocos) x3 遊戲後端(java) x2 管理前端(vue) x2 管理後端(java) x4 測試 x2 運維 x2 運營 x1mysql
後端架構
- spring-cloud Hoxton.SR3做爲微服務框架
- nacos 作服務註冊發現以及配置中心
- swagger2 生成doc
- redis 作緩存
- mysql
- mybatis + mybatis-plus 作持久層
- kafka 作消息中間件
- jwt 生成token
- elasticsearch 作報表
每一個微服務由兩個模塊組成,一個模塊api接口,一個模塊對接口進行實現, api接口用@FeignClient進行註解,其它模塊引用本模塊便可方便調用程序員
@FeignClient(value = "gb-user", contextId = "userFeign")
public interface UserFeign {
@GetMapping("findUserInfoByUserId")
UserDetailResultDTO findUserInfoByUserId(Long userId);
}
用戶信息綁定在線程上,在整個調用鏈條上共享.web
public class LoginUserContext {
private static ThreadLocal<LoginUser> userThread = new ThreadLocal();
public LoginUserContext() {
}
public static LoginUser get() {
return userThread.get() == null ? LoginUser.builder().build() : (LoginUser)userThread.get();
}
public static void set(Long userId, Integer userType) {
userThread.set(LoginUser.builder().userId(userId).userType(userType).build());
}
public static void set(LoginUser loginUser) {
userThread.set(loginUser);
}
public static void clear() {
userThread.remove();
}
}
項目就介紹到這裏.接下來講明微服務架構的缺點以及遇到的問題:redis
優勢:
- 每一個微服務基本由一我的負責,能夠提供更大的自由度
- 經過在項目實現中引入api層,可讓遠程調用像本地調用同樣簡單
- 架構師對框架進行了深度的封裝,只須要關注業務實現也能寫出基本合格的代碼
問題:
- 總體來講項目不大,或者說這是一個很小的項目,遊戲端和管理端一共也就7人開發.何況遊戲端和管理端幾乎徹底獨立.也就是單個子項目3~4人開發.使用微服務技術就顯得很是笨重.
- 項目設計要100w併發(吹牛),但實際併發很是小,首先管理端就不可能有過高的併發,遊戲端因爲須要第延時,也不可能有過高的併發.我看過騰訊遊戲的相關資料,單臺服務器的併發最高2w,遊戲的低延時又不可能使用多臺服務器.因此設計的100w併發是吹牛,即便須要遊戲支持100w併發,也只能經過分區分服來實現.這些都和微服務沒有關係.
- 我在項目中實際負責一款小遊戲的後端開發,剛開始使用kafka + 網關進行先後端通信實現,實測下來小遊戲的操做延遲很是大,徹底不知足設計須要.後來之間讓遊戲服務提供websocket服務才解決問題.
- 微服務自身的缺點也在本項目中暴露無遺 -- 開發中的煩惱,開發過程當中不免遇到api設計不合理,即便設計合理,中途的需求變動也會形成api修改,api修改帶來各類的版本衝突伴隨開發的前中期 -- 項目管理的煩惱,多模塊開發常常出現maven依賴的莫名錯誤,即便不影響開發那條紅線也讓程序員抓狂 -- 調試困難,須要啓動一堆服務才能進行調試,springboot項目自己佔用內存大,有時候須要啓動8個服務進行調試,個人小本本表示壓力巨大. -- 其它困難1,因爲咱們這個項目涉及到提現模塊,分佈式事務的一致性又來了.容錯\冪等難度指數上升. -- 其它困難2,架構師過多過死的封裝用於項目中,沒有通過大量實戰項目檢驗,被你們親切的稱爲demo架構師
整體來講是技術選型出了問題,迷信微服務,堆砌新技術.spring
遊戲界面設計稿