pos機未知返回碼是什么意思,為什么你學了 N 遍 Spring Boot

新聞資訊2 | 2023-06-13 10:02 | 投稿人：pos機之家

網(wǎng)上有很多關于pos機未知返回碼是什么意思,為什么你學了 N 遍 Spring Boot的知識，也有很多人為大家解答關于pos機未知返回碼是什么意思的問題，今天pos機之家(m.afbey.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機未知返回碼是什么意思

pos機未知返回碼是什么意思

作者 | bugpool

出品 | CSDN博客

為什么你學了n遍《1天精通Spring Boot》，至今還是不精通Spring Boot，甚至還是停留在學生項目？真正要做項目就應該一步到位，半吊子半桶水是不行的。一個實戰(zhàn)項目需要充分考慮狀態(tài)碼、異常處理、日志處理、性能監(jiān)控、數(shù)據(jù)安全、部署等等因素，而不是急于求成，為了達到1天精通的目標而糊弄過去。

筆者在大學時也經(jīng)歷過學了很多Spring Boot的教材，但是比起外包(哪怕是個小程序)，總覺得比真實項目缺了點什么，項目跑起來也是分分鐘解體。本篇適合有一定后端開發(fā)基礎(不涉及中間件，會在Spring Cloud講)，但是又停留于學生項目的讀者(不同語言均有借鑒意義)。

問題分析：

項目監(jiān)控

項目能跑就行！管他什么項目監(jiān)控，項目問題通通等用戶反饋，掛了就重啟！SQL慢用戶就等著，我怎么知道哪里執(zhí)行慢？項目訪問不了就是用戶網(wǎng)絡問題！用戶遇到問題就是一清緩存、二換瀏覽器、三重啟大法好！你怕是沒經(jīng)過社會的毒打，KPI分分鐘墊底，再過2個月就可以實現(xiàn)家里蹲的愿望了。

這里拿alibaba的druid做個例子，druid可以監(jiān)控以下幾個部分：

數(shù)據(jù)源：顯示當前項目下所有數(shù)據(jù)源，多數(shù)據(jù)源的項目才會用到。當然了，肯定不會顯示密碼。

SQL監(jiān)控：監(jiān)控所有執(zhí)行的SQL語句，包括耗時，參數(shù)等等。

SQL防火墻：druid提供了黑白名單的訪問，可以清楚的看到SQL防護情況。

Web應用：可以看到目前運行的Web程序的并發(fā)數(shù)，事務書等等詳細信息。

URI監(jiān)控：可以監(jiān)控到所有的請求路徑的請求次數(shù)、請求時間等參數(shù)。

Session監(jiān)控：監(jiān)控session狀況，創(chuàng)建時間、最后活躍時間、請求次數(shù)、請求時間等參數(shù)。

集成完druid，項目馬上提高一個檔次，可以在boss面前打開頁面吹噓一把。最最關鍵的是，集成druid是分分鐘的事情，幾乎沒有代碼的侵入性，要改造也只需添加個bean，改下配置文件。詳細可參考springboot集成druid，絕對是排查慢SQL、優(yōu)化性能、監(jiān)控項目居家必備良藥！

日志

日志記錄操作軌跡、監(jiān)控系統(tǒng)運行狀態(tài)、回溯系統(tǒng)故障，保留系統(tǒng)故障現(xiàn)場，方便程序員快定位問題。生產(chǎn)環(huán)境不同于學生項目，隨時有問題就重啟debug，在公司里，開發(fā)人員你碰服務器的資格都沒有，所以保留日志成了排查Bug唯一的方法。這里就談談容易被忽視的幾點：

等級：DEBUG<INFO<WARN<ERROR<FATAL，程序員應該預先判斷好日志等級。不是所有日志一打就是log.error，比方說業(yè)務異常往往只需要通過引導用戶正確操作就可以解決，那么應該將他歸為log.warn級別。如果一股腦全部日志都打成log.error，error日志幾萬行(里面99%都只是校驗輸入出錯)，看到就頭疼，誰去排查error日志上的問題？

定期巡檢：初級項目往往是用戶反饋了故障才進行問題排查。而標準的項目應該定期巡檢error日志，因為②中已經(jīng)做好的分類，error一定是需要人為介入的，將這些error日志逐條排查便可以提前發(fā)現(xiàn)項目潛在風險。

日志完整性：初學者往往會打出log.error(e.getMessage)或log.error("錯誤信息：" + e)的日志，這種寫法將吃掉所有的堆棧信息！這是非常非常嚴重的事情，正確的寫法應該是logger.error("第x部分出錯 " + e)。

日志配置：初學者往往并不關心日志文件存放在哪里，日志文件保留多久，日志文件按等級生成等配置細節(jié)，而作為一名架構師，你需要充分評估項目的需求，對這些進行自定義的配置。筆者也曾因為不關心這些配置，導致日志爆滿撐死服務器！

日志框架分為日志門面、日志實現(xiàn)庫、日志適配器三類。JCL、SLF4j、Jboss-logging這些框架都是日志門面；而真實干活的人則是日志實現(xiàn)庫，常見的Log4j、Log4j2、Logback、JUL；當門面與實現(xiàn)庫不匹配時則需要日志適配器。當然現(xiàn)在百分之90的項目使用的都是slf4j + logback，可以不太關心日志框架的選型。但是如果你立志成為一名架構師，那框架的選型就是一門必修課，還是得去了解。

狀態(tài)碼

對比一下上圖有什么區(qū)別？很簡單，就是多了個狀態(tài)碼。有沒有這個狀態(tài)碼似乎對前端請求的數(shù)據(jù)也沒什么影響，不加狀態(tài)碼前端還是可以正常顯示。確實，在核心數(shù)據(jù)上是不會有任何影響的，但是一旦出現(xiàn)一些業(yè)務異常，返回的數(shù)據(jù)就會如下圖所示：

{"timestamp": "2020-04-25T03:55:26.179+0000","status": 500,"error": "Internal Server Error","message": "\### Error querying database. Cause: Java.sql.SQLException: sql injection violation, syntax error: syntax error, error in :\\u0027 asd from product_info where produc\\u0027, expect IDENTIFIER, actual IDENTIFIER pos 12, line 1, column 13, token IDENTIFIER : select * asd from ...}

如果前端沒有能通過狀態(tài)碼進行不同返回請求的處理，返回異常數(shù)據(jù)時，前端代碼仍舊直接獲取data數(shù)據(jù)，那誰知道前端會出現(xiàn)什么樣子的異常呢？

如果能與前端妹子好好商量一下狀態(tài)碼的規(guī)則，那么前端就可以通過不同的狀態(tài)碼，判斷不同的請求響應等級，例如：

當接受到200時，說明正常，直接取data數(shù)據(jù)，進行正常的展示；

如果遇到1000~2000的，說明只是普通的警告，調用??的彈窗，顯示一下msg就可以了；

如果遇到2000+的說明時是重大問題，需要獲取msg作為彈窗title，并從data中獲取異常信息……

不然你就隨心所欲拋異常，想怎么返回就怎么返回，前端妹子提刀就來找你了。想想自己為什么還是單身？或許就是因為沒跟前端妹子在大明湖畔約定好狀態(tài)碼吧。

異常處理

學生項目往往就是不到IDE報無法編譯，不到萬不得已堅決不進行異常處理！而異常處理又至關重要！那就大致來了解一下吧。

所有異常都是Throwable的子類，分為Error致命異常和Exception非致命異常。

Error異常往往是StackOverflowError、OutOfMemoryError這類根本無能為力的異常，既然無能為力了，我們也不需要太關心了，只需要記錄日志，也只能到時候排查了。

Exception這類異常又分為checked和RuntimeException、checked是需要顯示處理的異常，比如io異常等，你不處理就編譯不了，也就是上面說的不到萬不得已堅決不進行異常處理的異常，這類因為每次Idea都會提醒。

而我們關心的是RuntimeException，這類，這類異常往往是業(yè)務異常，正常的做法是封裝一個AppException繼承自RuntimeException，在發(fā)現(xiàn)業(yè)務異常時，配合狀態(tài)碼拋出對應異常：

@Getterpublic class APIException extends RuntimeException {private int code;private String msg;// 手動設置異常public APIException(StatusCode statusCode, String message) {// message用于用戶設置拋出錯誤詳情，例如：當前價格-5，小于0super(message);// 狀態(tài)碼this.code = statusCode.getCode;// 狀態(tài)碼配套的msgthis.msg = statusCode.getMsg;}// 默認異常使用APP_ERROR狀態(tài)碼public APIException(String message) {super(message);this.code = AppCode.APP_ERROR.getCode;this.msg = AppCode.APP_ERROR.getMsg;}}

那么誰來拋出異常，誰又來處理異常呢？

通常來說，一般拋出業(yè)務異常的是在service層或者相關的邏輯業(yè)務層進行，并且配合狀態(tài)碼進行拋出：

throw new APIException(AppCode.PRODUCT_NOT_EXIST, "上架商品中無法查詢到：" + orderDetail.getProductId);

然后在調用者層進行處理，這里的調用者一般指最上層的controller層也就是控制層，進行處理，當然springboot有統(tǒng)一處理的功能，本質是通過AOP對controller層進行攔截異常。有想深入了解的可以參考：《正規(guī)軍springboot如何處理：參數(shù)校驗、統(tǒng)一異常、統(tǒng)一響應》。

@RestControllerAdvice@Slf4jpublic class ControllerExceptionAdvice {@ExceptionHandler({BindException.class})public ResultVo MethodArgumentNotValidExceptionHandler(BindException e) {// 從異常對象中拿到ObjectError對象ObjectError objectError = e.getBindingResult.getAllErrors.get(0);return new ResultVo(ResultCode.VALIDATE_ERROR, objectError.getDefaultMessage);}@ExceptionHandler(APIException.class)public ResultVo APIExceptionHandler(APIException e) {log.error(e.getMessage, e);return new ResultVo(e.getCode, e.getMsg, e.getMessage);}}

單元測試

單元測試的意義并不僅僅在于發(fā)現(xiàn)現(xiàn)有代碼Bug。一個好的單元測試可以作為測試用例固化在項目中，方便程序員進行重構和修改。如上圖，自己都可能出現(xiàn)不敢刪掉冗余代碼的情況，更何況是重構代碼？修改代碼？甚至是接手別人的代碼？在公司中，正常一套代碼會有AB角之分，保證其中一方跑路跳槽，項目也不會出現(xiàn)人員斷層，確保項目能正常進行：

A角經(jīng)歷開發(fā)的完整周期，對功能潛在bug往往比B角清楚的多。當A角能寫好單元測試，B角只需重構修改好代碼，再重新運行一遍單元測試便可以安心上線

而當A角完全不寫單元測試，B角接手后大概就是?！芭P靠，這段tm能不能改??？”，“這不會有特殊情況吧？”，“這其他地方不會用到吧？”，“這tm該不會是業(yè)務需求討論，為后續(xù)模塊預留的吧？”……

如果說，公司某個A角邀請你簽他的AB角生死狀，請先看一下他的單元測試覆蓋率等指標，如果一個單元測試都不寫的，打死都不簽！不然改完代碼一上線很可能又是解體操作！

服務器

這點筆者深有體會，在大學期間，總是聽人說服務器就是一臺電腦。但是你說任你說，我還是覺得服務器是一個高端大氣又特別神秘的東西！自己的代碼永遠都運行在IDEA上，哪怕我知道部署項目的所有步驟，卻一直止步不前，總覺得少了點什么。直到第一次接觸到服務器，才發(fā)現(xiàn)原本以為這貨真的是個電腦！這貨真的就是個Linux！而且通過公網(wǎng)IP、域名真的可以訪問到自己的項目！

如果你也有這方面的困惑，請花一筆幾十塊錢的巨資去買阿里云或者騰訊云買個服務器，然后親手實操一遍，服務器、公網(wǎng)IP、域名(幾塊錢)這些都是本機虛擬機無法模擬的東西！最好學習一下docker部署springboot項目，詳見docker部署MySQL、SpringBoot。紙上讀來終覺淺！去實際操作一把，相信對你會有實質上的提升！這里筆者提供給大家學習的《一步到位SpringBoot系列》數(shù)據(jù)庫也是部署在服務器上的。

《一天精通SpringBoot》是不現(xiàn)實的，如果真是這樣，那Java后端程序員也就太沒有含金量了。麻雀誰小五脹俱全，一個哪怕再小的小程序項目，只要要上線，就都得經(jīng)歷一個項目的完整過程，少的可能只是中間件的優(yōu)化。

如果說要學習SpringBoot，目標已經(jīng)明確就是Java后端，那為什么不一步到位呢？又想學習SpringBoot后端的同學可以參考《一步到位SpringBoot》，保證搭建出一套健壯的，不會解體操作的后端框架。

《一步到位SpringBoot》鏈接：

https://blog.csdn.net/chaitoudaren/article/details/105624082

原文鏈接：

https://blog.csdn.net/chaitoudaren/article/details/105745335

?再見 Python，Hello Julia！

?順豐正式殺入外賣領域；中國移動推出 5G 消息 App；GCC 10.1 發(fā)布 | 極客頭條

?你現(xiàn)在從事的程序員還有多久會消失？牛津大學研究員幫你算了算

?一次對語音技術的徹底批判

?后端程序員必備：書寫高質量SQL的30條建議

?到底是哪些人在玩鏈游？| 《區(qū)塊鏈游戲玩家研究報告》