主要針對新的專案
1 - 開始不要著急搞微服務,分布式,無疑會加大開發成本,拖慢開發速度,除非團隊有基礎,水平很高.
2 - 可以按照微服務的架子進行專案開發管理,比如拆分出使用者管理模組,裝置模組,某某應用模組等等,url統一字首,建立各自的service,utils,source等等,資料庫根據業務區分字首,便於後期拆分服務.
3 - 使用統一的時間庫,json庫
4 - 資料庫存時間戳或utc時間,前端根據時區處理,解決時區問題
5 - 後端返回前端格式統一,一律用狀態碼進行提示,這樣多語言就可以放在前端處理了,而不用兩端同時處理
6 - 不要在controller中寫業務邏輯,只進行引數驗證,邏輯寫在service裡,便於重用
7 - 引數驗證前後端要統一正規表示式,要單獨建立乙個utils,統一管理引數驗證
8 - 一邊開發,一邊重構,一旦某段**複製了3次就重構之前的**
9 - 乙個方法只做一件事,乙個類只做一種事,乙個服務只做一類事
10 - 使用lambok優化pojo類是個不錯的選擇
11 - 資料庫表名統一以下劃線方式,類,屬性,方法用駝峰方式,常量全大寫
12 - 統一處理異常,統一驗證許可權,不要放到各個介面中,使用aop
13 - 開發時,經常使用git分支,可以有效提高開發,運維和測試的工作效率
14 - 盡可能不要聯調測試,可以用doker部署下,讓測試人員連docker
15 - 寫了service,心虛的那種,可以先在test中自己測試下,這樣可以縮小問題的範圍
16 - 不用太多注釋,盡可能用合理的方法名說明要做什麼事,保持**簡潔
17 - **沒寫完,下班了,一定寫乙個todo,可以減少第二天回憶的時間
18 - 如果使用者多了,撐不住了,可以先考慮垂直擴充套件,畢竟使用者多了也就有錢了,增加裝置配置會省不少事
19 - 如果還撐不住,就搞個負載均衡,nacos?dubbo?nginx?如果流量削峰,rocketmq?
20 - 如果資料庫扛不住了,先考慮把大的字段拆到別的表,還不行,就分庫,分庫,加配置也撐不住了,那就分表吧,水平拆分shardingphere,leaf...
21 - 這個時候就可以考慮拆分服務了,所有的業務應該都差不多清晰了,康威定律,按照公司的架構模式拆分估計也差不多了
22 - 這個時候可以使用springcloudalibaba那一套方案
23 - 逐漸演變成k8s + istio服務網格,資料庫遷移到tidb
以上也是在開發過程中,查詢資料,學習了解到的.
實際專案沒有真的走到微服務那一步,也許以後會用到,記錄一下,目前專案也只是增加了裝置配置...
關於springboot的logback的配置
1 pom檔案引入jar包 dependency groupid org.springframework.boot groupid artifactid spring boot starter logging artifactid version 1.5.2.release version depe...
Springboot開發之我見
現在越來越多的人關注微服務，要求提公升開發效率，我從17年9月起開始使用springboot框架，在專案過程中聊聊我的心得體會 1 強大的註解模式 幾乎不需要配置檔案，yml的配置檔案看起來體驗比properties要清晰明了 2 main啟動 springboot內建了tomcat引擎，jar包直...
基於SpringBoot開發
使用idea配置springboot專案 專案結構 而 configuration 經常與 bean 組合使用，使用這兩個註解就可以建立乙個簡單的spring 配置類，可以用來替代相應的xml 配置檔案。enableautocon figuration 能夠自動配置spring 的上下文，猜測和配置...