springcloud 研發規範

1) 程序結構規範

 

   

1: Facade-Stub:包含全部對外提供服務的藉口定義,並對外提供

2:  Façade:實現Façade-Stub裏面定義的所有藉口,能夠調用Service模塊和Common模塊

3:  Task:包含所有的任務實現,能夠調用Service模塊和Common模塊

4:  Service:包含業務處理邏輯,一般來講事務在此模塊中實現,能夠調用Client、Dao和Common

5:  Client:包含所有對其餘服務的調用,經過引入Façade-Stub實現藉口調用,能夠調用其餘服務的Façade-Stub和本服務Common

6:  Dao:包含全部對數據的操做,包含SQL、NoSql等,能夠調用Common

7:  Common:一些本服務中通用的方法

8:  模塊命名方法: 業務名稱-服務名稱-模塊名稱 akucun-user-client

9: 使用子模塊的方式引入到主POM中

<modules>
  <module>akucun-user-client</module>
  <module>akucun-user-common</module>
  <module>akucun-user-dao</module>
  <module>akucun-user-facade</module>
  <module>akucun-user-facade-stub</module>
  <module>akucun-user-service</module>
  <module>akucun-user-task</module>
</modules>

 

2) 技術棧規範

      

新業務應用所有使用:

java + mybatis + springcloud 的技術棧進行研發

老系統逐步替換成規定的技術棧

 

l  數據庫設計規範                    

        

mer_bank.sql

 

ID 統一叫: pid

created_time、updated_time、created_by、update_by是必需要加到表定義中的。

若是有刪除動做還須要加上is_delete、delete_time、delete_by等字段 , is_delete 爲NOT NULL字段 默認爲0 ,   1 表示刪除

全部字段儘可能所有都是NOT NULL,若是業務上確實須要使用爲NULL的字段,請說明。

請儘可能將數據庫的默認步長設置爲2方便之後擴展

頻繁須要連表查詢的數據,考慮是否能夠進行數據冗餘

 

3) 接口設計規範

 

對外接口設計時參照RESTful風格

使用HTTP Method 來標識操做:

POST:              表示新增

GET:                  表示查詢

DELETE:      表示刪除

PUT:                   表示更新

PATCH:           表示部分更新(依照之前的經驗老說,不太經常使用,或者轉義使用)

使用資源來標識操做的對象

http://www.a.com/api/v1/b2b/users/1

這個URL標識將   api->v1版本->b2b域下->ID爲1的用戶   做爲操做對象

注:對於特別複雜的接口,能夠不嚴格遵守規範設計,可是要在設計時提出

 

接口數據傳遞經過原則上經過JSON實現

全部接口的返回值必須有統一的結構,具體結構會在後面給出

接口返回的狀態碼須要統一分段分配

前端和後端須要共同維護狀態碼和報錯信息的對應表

每一個服務都要提供health-check接口,用於檢測其可用

 

 

4) 提測規範

 

開發人員根據接口文檔完成研發後須要將接口(編號)提測

提測的接口集合應該至少是一個完整的流程或功能(例如對會員信息的增刪改查,應該一塊兒提測)

有依賴關係的接口應該先提測底層接口再提測上層接口

每一個提測接口應需給出一個調用示例(能夠保存在postman上)

postman 帳號：aikucun

密碼：aikucun123456

完成接口測試以後才能進行前端系統的測試(多是某個模塊的接口)

 

 

5) 上線規範

 

測試人員在某個代碼版本上完成測試後(一般完成測試能夠認爲是沒有優先級高的BUG便可不須要修改徹底部BUG)方可上線

每一次上線都應該至少記錄BUG FIX List, 新應用或者新功能列表,已有功能的修改列表三個表格

上線步驟一般能夠分爲:1)數據上線 2)應用服務上線 3)前端系統上線

 

能夠對數據進行適當備份.

執行DDL

執行DML

執行緩存數據的上線

 

 

6) 數據上線規範

 

能夠對數據進行適當備份.

執行DDL

執行DML

執行緩存數據的上線

 

 

7) 應用服務上線規範

理清須要上線服務的調用關係

執行底層服務的上線

執行上層服務的上線

線上冒煙測試

迴歸測試(可選)

 

 

8) 前端系統上線規範

 

將靜態資源發佈到各個前端系統中(nginx、cdn等,沒有順序限制)

線上冒煙測試

迴歸測試(可選)

 

9) springcloud項目規範

 

1:  輸出規範

輸出類: com.akucun.common.Result

分頁類: com.akucun.common.Pagination

Result中的code message對應的枚舉: com.akucun.common.utils.enums.CodeMsg 

 

2: 項目發佈規範說明: 

git 的分支總體預覽圖以下。

從上圖能夠看到主要包含下面幾個分支：

• master: 主分支，主要用來版本發佈。
• develop：平常開發分支，該分支正常保存了開發的最新代碼。
• feature：具體的功能開發分支，只與 develop 分支交互。
• release：release 分支能夠認爲是 master 分支的未測試版。好比說某一期的功能所有開發完成，那麼就將 develop 分支合併到 release 分支，測試沒有問題而且到了發佈日期就合併到 master 分支，進行發佈。
• hotfix：線上 bug 修復分支。

 參考: http://blog.jobbole.com/109466/

 

3: springboot 項目運行說明: 

添加啓動參數:   -Ddeploy.app.name=merchant-platform-facade  和  -Dhost=192.168.1.1  -Dlog.level=info -Dguid.datacenter.id=2  -Dguid.machine.id=3

說明:

deploy.app.name	日誌文件夾名稱如:  /home/用戶/logs/merchant-platform-facade/日誌文件
host	服務器的ip地址 ELK用來區分那臺服務器打印的日誌
log.level	初始日誌級別
guid.datacenter.id	數據中心
guid.machine.id	數據中心中對應的服務器編號

 

 

4:  啓動類繼承 SpringBootServletInitializer 能夠打war包

 

5:  待續...

 

10) 屬性文件中敏感數據加密處理

     測試環境和線上環境對數據文件中的敏感數據加密處理, 可藉助springcloud config加密解密功能

11) 用戶登陸行爲埋點

待續...

 

12) 技術選型

當前階段愛庫存技術選擇以下

緩存	阿里雲 redis 集羣
數據庫	RDS 的讀寫分離
API通訊	restfulAPI 爲主
消息隊列	rocketMQ
文件存儲	OSS 與 fastDFS  (優化抽像可切換)
搜索引擎	ElasticSearch