Hana Project 介紹 第二集 - Hana 引擎後端架構

-

Hana 引擎架構

整體架構如下圖。

主要分成三大區塊對應內容如下:

  • Hana Back: 後端(包含DB)
  • Hana Front: 前端
  • Resource: 圖片音樂文字等資源

接下來會依序講解:

Hana Back

Hana 引擎的後端，本身是 spring boot服務，透過rest API 與Hana Front 溝通。
目前 Hana Back 主要處理兩份工作，分別是 Hana 語言解析跟存讀檔。

Hana 語言解析

由於Hana腳本語言會有一定數量的指令，當發現該行是指令後會繼續讀取下一行，直到非指令為止。
讀取完之後會將內容轉換成Json傳遞給 Hana Front。
原先想要一個 Json 就代表一個畫面，但最終考量到 restful 應該是無狀態的，不應該因為之前呼叫過哪些行數而改變傳遞內容；如果是每次都從開頭讀取 Hana 腳本語言而組成 Json 的話，在面對大量交換場景的部分可能會導致物件內容的大量重新 new 與拋棄，因此最終決定就忠實傳遞 Hana 腳本的內容就好了。

Hana Save System

目前尚未實作完成。
本體是使用內嵌的 H2DB搭配 MyBatis，雖然有部分資料不建議使用H2DB在生產環境中。但實際考量 galgame 本身並不會大量的 CRUD，因此就放心地使用了。
會在 Hana 引擎啟動的時候透過 spring boot 自動去尋找是否有建立 DB 跟 table。如果沒有的話將會自動建立；但目前尚未實作存讀檔，因此會建立DB跟table但不會有資料在裡面。

將來 Hana 引擎完成後會考慮搭配可視化工具讓開發者可以簡單去觀看資料。 

留言

張貼留言

這個網誌中的熱門文章

基本 Spring security 快速入門

-
圖片
基本 Spring security 快速入門 最近學了 spring security 遇到一些 6 版和舊版的一些差異，所以想說寫一下快速入門，但有些前情提要: 這個入門不包含 spring security 的使用概念，關於這部分相當推薦閱讀 spring security 實戰這本書 本快速入門不包含 OAuth2 和權限控管，只會使用 Basic 驗證，但建議先學會入門之後再加深． 由於個人專案有使用到 swagge ，因此也會有相對的教學 主要使用到的 spring security 元件： org.springframework.security.authentication.AuthenticationProvider org.springframework.security.crypto.password.PasswordEncoder org.springframework.security.core.userdetails.UserDetailsService org.springframework.security.core.userdetails.UserDetails 撰寫 UserDetailsService 首先先在 service 新增 class 並且 implements UserDetailsService 實作的時候會發現需要實作: UserDetails loadUserByUsername ( String username ) throws UsernameNotFoundException ; 依照 function name 可以知道要實現的功能是去 DB 或 redis 之類的地方取得使用者資訊，並且將資料放進 UserDetails 後 return 出去，因此在開始寫 loadUserByUsername 方法之前需要先實作 UserDetails 實作 UserDetails 實作的時候會發現我們需要實作 getAuthorities getPassword getUsername isAccountNonExpired isAccountNonLocked isCredentialsNonExpired isEnabled 基本上依照 functio...
閱讀完整內容

記帳專案說明

-
圖片
新專案說明 最近開新的專案，目前專案的系統架構和後端處理的差不多了，剩下前端的部分正在一邊學 react 一邊完成中，考慮到最近要開始找工作了，所以想說寫個部落格一邊介紹目前專案的架構與紀錄目前的狀態。 專案整體架構 在開始之前我們先發一張架構圖吧，接下來請把架構圖當成地圖開始冒險吧。 這次的專案主要是走雲原生的概念，下述我們分成基礎設施、前端、後端來聊吧 基礎建置 雲端服務廠商選擇: AWS 這個專案從剛開始設計就是預計上雲且使用的是 aws，主要有兩個點 我們家並沒有固定 IP ，如果要走地端的話勢必要使用到 DDNS ，那牽涉的範圍就會更廣了，因此決定直接上雲 根據網路上查到的資料，目前 aws 市佔 33% ，考慮到將來要找工作與方便尋找資料因此決定直接使用 aws 用到的 AWS 服務 接下來先概覽一下用到的服務與相關功能，下面會以使用者接觸到服務的順序來說明： 服務名稱 用途 router53 DNS, 用於將 domain 轉換成 IP, 我的 domain 也是在該服務購買的 彈性 IP 當我們租了 AWS 的伺服器時是沒有對外 IP 的，因此我們需要透過彈性 IP 申請並且綁定到我們的 EC2 安全群組 連到伺服器的防火牆，可以設定每個 port 是否要開啟，並且設定白名單等 EC2 這個就是我租伺服器的本體，所有的服務與反向代理等都是放在這裡 EC2 建置了哪些服務 這邊會講一下我安裝與使用到哪些非我開發的服務 資料庫： 資料庫的部分我使用的是 mariaDB, 會選擇 mariaDB 的原因除了他是 MySQL 的分支之外，他的社群很活躍、穩定性也很高 catch: catch 的部分我使用 redis ，主要適用於處理會需要經常取得資料或者不需要持久化的資料，目前我主要用於記錄使用者登入後的 token，由於採取的是前後端分離的架構，後端會需要頻繁的驗證 token 和透過 token 取得用者資訊，因此這部分得資料就放在 redis，更詳細的使用邏輯將會在後面提到後端的時候說明。 SSL: 這個專案的 SSL 主要用於 https 連線，這部分是使用 Let's Encrypt 家的憑證。 會用 Let's Encrypt 的原因最主要是免費和自動化申請，如果考慮到...
閱讀完整內容

JMSTemplate 的教學

-
前言（一堆廢話） 嘿，大家好久不見！我發現距離上次在 Blogger 發文，竟然已經過了快半年了。想想還真有點不好意思，不過這次我可是帶著新東西來跟大家分享的！ 這次要聊的是 Java JMSTemplate。為什麼突然要學這個呢？主要是因為我最近換了新公司，而他們那邊剛好需要用到 訊息佇列 (Message Queue) 的技術，所以我就趁這個機會好好學了一下。 (老實說，我其實都工作六年了，這東西早就該會了啦！) Message Queue 是什麼和目的 這部分我覺得我讀的書的寫的很棒，因此想說直接引用過來。 假設現在是星期五 16:55 ，在幾分鐘就可以開始期待已久的休假了。再過幾分鐘你的飛機就要起飛了，但是在這幾分鐘你需要先確定主管和同事了解你的工作進度，這樣他們才有機會於下週一接續你的工作。這時候該怎麼辦？ 這時候避免打擾到他們最好的做法就是留紙條或發送 E-mail ，如此一來他們就可以在下週一或有空的時候看到 E-mail 接續工作。 這段很完美的解釋了 Message Queue，的概念，將訊息傳到佇列，之後根據佇列的先進先出讓服務吸收消化，最後調整服務一次接收多少 Message 。 如此一來可以帶來以下幾個好處： 解耦合： 發送者可以完全不管接收者狀態與是否可以承受，只需要將訊息丟到 Queue 就好了 系統不同的區塊可以獨立開發（其實就跟現今流行的微服務類似概念） 非同步處理：發送者可以完全不需要等待另一方處理就可以繼續處理下一個 request。這樣講有點抽象，可以想像麥當勞點餐系統，櫃檯的人員不需要完全確認廚房是否收到單就可以接下一個客人了。 提高可靠性：很多提供 Message Queue 的元件會提供持久化的功能，他會將 message 存起來，這樣一來就算遇到某個 Message 處理有問題，也可以很快查到並且做後續 support。 水平擴展：我們可以很輕易地增加消費 Message 的處理人員，這樣就可以提高 Queue 的消化速度，已應付高流量又要快速處理的需求。 等等 上述只有放我自己認為很重要的優點，但其實還有很多的優點。 名詞 那優點介紹完之後我們來聊一下在 Message Queue 常會用到的名詞， 佇列(Queue)：就像是排隊一樣，先進先出。 生產者(Producer)：就是指生成 Message 的服務 消費者(...
閱讀完整內容