網(wǎng)上有很多關(guān)于pos機(jī)未知返回碼是什么意思,為什么你學(xué)了 N 遍 Spring Boot的知識(shí)，也有很多人為大家解答關(guān)于pos機(jī)未知返回碼是什么意思的問題，今天pos機(jī)之家(www.shineka.com)為大家整理了關(guān)于這方面的知識(shí)，讓我們一起來看下吧!
本文目錄一覽：
pos機(jī)未知返回碼是什么意思
作者 | bugpool
出品 | CSDN博客
為什么你學(xué)了n遍《1天精通Spring Boot》，至今還是不精通Spring Boot，甚至還是停留在學(xué)生項(xiàng)目？真正要做項(xiàng)目就應(yīng)該一步到位，半吊子半桶水是不行的。一個(gè)實(shí)戰(zhàn)項(xiàng)目需要充分考慮狀態(tài)碼、異常處理、日志處理、性能監(jiān)控、數(shù)據(jù)安全、部署等等因素，而不是急于求成，為了達(dá)到1天精通的目標(biāo)而糊弄過去。
筆者在大學(xué)時(shí)也經(jīng)歷過學(xué)了很多Spring Boot的教材，但是比起外包(哪怕是個(gè)小程序)，總覺得比真實(shí)項(xiàng)目缺了點(diǎn)什么，項(xiàng)目跑起來也是分分鐘解體。本篇適合有一定后端開發(fā)基礎(chǔ)(不涉及中間件，會(huì)在Spring Cloud講)，但是又停留于學(xué)生項(xiàng)目的讀者(不同語言均有借鑒意義)。
問題分析：
項(xiàng)目監(jiān)控
項(xiàng)目能跑就行！管他什么項(xiàng)目監(jiān)控，項(xiàng)目問題通通等用戶反饋，掛了就重啟！SQL慢用戶就等著，我怎么知道哪里執(zhí)行慢？項(xiàng)目訪問不了就是用戶網(wǎng)絡(luò)問題！用戶遇到問題就是一清緩存、二換瀏覽器、三重啟大法好！你怕是沒經(jīng)過社會(huì)的毒打，KPI分分鐘墊底，再過2個(gè)月就可以實(shí)現(xiàn)家里蹲的愿望了。
這里拿alibaba的druid做個(gè)例子，druid可以監(jiān)控以下幾個(gè)部分：
數(shù)據(jù)源：顯示當(dāng)前項(xiàng)目下所有數(shù)據(jù)源，多數(shù)據(jù)源的項(xiàng)目才會(huì)用到。當(dāng)然了，肯定不會(huì)顯示密碼。
SQL監(jiān)控：監(jiān)控所有執(zhí)行的SQL語句，包括耗時(shí)，參數(shù)等等。
SQL防火墻：druid提供了黑白名單的訪問，可以清楚的看到SQL防護(hù)情況。
Web應(yīng)用：可以看到目前運(yùn)行的Web程序的并發(fā)數(shù)，事務(wù)書等等詳細(xì)信息。
URI監(jiān)控：可以監(jiān)控到所有的請(qǐng)求路徑的請(qǐng)求次數(shù)、請(qǐng)求時(shí)間等參數(shù)。
Session監(jiān)控：監(jiān)控session狀況，創(chuàng)建時(shí)間、最后活躍時(shí)間、請(qǐng)求次數(shù)、請(qǐng)求時(shí)間等參數(shù)。
集成完druid，項(xiàng)目馬上提高一個(gè)檔次，可以在boss面前打開頁面吹噓一把。最最關(guān)鍵的是，集成druid是分分鐘的事情，幾乎沒有代碼的侵入性，要改造也只需添加個(gè)bean，改下配置文件。詳細(xì)可參考springboot集成druid，絕對(duì)是排查慢SQL、優(yōu)化性能、監(jiān)控項(xiàng)目居家必備良藥！
日志
日志記錄操作軌跡、監(jiān)控系統(tǒng)運(yùn)行狀態(tài)、回溯系統(tǒng)故障，保留系統(tǒng)故障現(xiàn)場(chǎng)，方便程序員快定位問題。生產(chǎn)環(huán)境不同于學(xué)生項(xiàng)目，隨時(shí)有問題就重啟debug，在公司里，開發(fā)人員你碰服務(wù)器的資格都沒有，所以保留日志成了排查Bug唯一的方法。這里就談?wù)勅菀妆缓鲆暤膸c(diǎn)：
等級(jí)：DEBUG<INFO<WARN<ERROR<FATAL，程序員應(yīng)該預(yù)先判斷好日志等級(jí)。不是所有日志一打就是log.error，比方說業(yè)務(wù)異常往往只需要通過引導(dǎo)用戶正確操作就可以解決，那么應(yīng)該將他歸為log.warn級(jí)別。如果一股腦全部日志都打成log.error，error日志幾萬行(里面99%都只是校驗(yàn)輸入出錯(cuò))，看到就頭疼，誰去排查error日志上的問題？
定期巡檢：初級(jí)項(xiàng)目往往是用戶反饋了故障才進(jìn)行問題排查。而標(biāo)準(zhǔn)的項(xiàng)目應(yīng)該定期巡檢error日志，因?yàn)棰谥幸呀?jīng)做好的分類，error一定是需要人為介入的，將這些error日志逐條排查便可以提前發(fā)現(xiàn)項(xiàng)目潛在風(fēng)險(xiǎn)。
日志完整性：初學(xué)者往往會(huì)打出log.error(e.getMessage)或log.error("錯(cuò)誤信息：" + e)的日志，這種寫法將吃掉所有的堆棧信息！這是非常非常嚴(yán)重的事情，正確的寫法應(yīng)該是logger.error("第x部分出錯(cuò) " + e)。
日志配置：初學(xué)者往往并不關(guān)心日志文件存放在哪里，日志文件保留多久，日志文件按等級(jí)生成等配置細(xì)節(jié)，而作為一名架構(gòu)師，你需要充分評(píng)估項(xiàng)目的需求，對(duì)這些進(jìn)行自定義的配置。筆者也曾因?yàn)椴魂P(guān)心這些配置，導(dǎo)致日志爆滿撐死服務(wù)器！
日志框架分為日志門面、日志實(shí)現(xiàn)庫、日志適配器三類。JCL、SLF4j、Jboss-logging這些框架都是日志門面；而真實(shí)干活的人則是日志實(shí)現(xiàn)庫，常見的Log4j、Log4j2、Logback、JUL；當(dāng)門面與實(shí)現(xiàn)庫不匹配時(shí)則需要日志適配器。當(dāng)然現(xiàn)在百分之90的項(xiàng)目使用的都是slf4j + logback，可以不太關(guān)心日志框架的選型。但是如果你立志成為一名架構(gòu)師，那框架的選型就是一門必修課，還是得去了解。
狀態(tài)碼
對(duì)比一下上圖有什么區(qū)別？很簡(jiǎn)單，就是多了個(gè)狀態(tài)碼。有沒有這個(gè)狀態(tài)碼似乎對(duì)前端請(qǐng)求的數(shù)據(jù)也沒什么影響，不加狀態(tài)碼前端還是可以正常顯示。確實(shí)，在核心數(shù)據(jù)上是不會(huì)有任何影響的，但是一旦出現(xiàn)一些業(yè)務(wù)異常，返回的數(shù)據(jù)就會(huì)如下圖所示：
{"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)碼進(jìn)行不同返回請(qǐng)求的處理，返回異常數(shù)據(jù)時(shí)，前端代碼仍舊直接獲取data數(shù)據(jù)，那誰知道前端會(huì)出現(xiàn)什么樣子的異常呢？
如果能與前端妹子好好商量一下狀態(tài)碼的規(guī)則，那么前端就可以通過不同的狀態(tài)碼，判斷不同的請(qǐng)求響應(yīng)等級(jí)，例如：
當(dāng)接受到200時(shí)，說明正常，直接取data數(shù)據(jù)，進(jìn)行正常的展示；
如果遇到1000~2000的，說明只是普通的警告，調(diào)用??的彈窗，顯示一下msg就可以了；
如果遇到2000+的說明時(shí)是重大問題，需要獲取msg作為彈窗title，并從data中獲取異常信息……
不然你就隨心所欲拋異常，想怎么返回就怎么返回，前端妹子提刀就來找你了。想想自己為什么還是單身？或許就是因?yàn)闆]跟前端妹子在大明湖畔約定好狀態(tài)碼吧。
異常處理
學(xué)生項(xiàng)目往往就是不到IDE報(bào)無法編譯，不到萬不得已堅(jiān)決不進(jìn)行異常處理！而異常處理又至關(guān)重要！那就大致來了解一下吧。
所有異常都是Throwable的子類，分為Error致命異常和Exception非致命異常。
Error異常往往是StackOverflowError、OutOfMemoryError這類根本無能為力的異常，既然無能為力了，我們也不需要太關(guān)心了，只需要記錄日志，也只能到時(shí)候排查了。
Exception這類異常又分為checked和RuntimeException、checked是需要顯示處理的異常，比如io異常等，你不處理就編譯不了，也就是上面說的不到萬不得已堅(jiān)決不進(jìn)行異常處理的異常，這類因?yàn)槊看蜪dea都會(huì)提醒。
而我們關(guān)心的是RuntimeException，這類，這類異常往往是業(yè)務(wù)異常，正常的做法是封裝一個(gè)AppException繼承自RuntimeException，在發(fā)現(xiàn)業(yè)務(wù)異常時(shí)，配合狀態(tài)碼拋出對(duì)應(yīng)異常：
@Getterpublic class APIException extends RuntimeException {private int code;private String msg;// 手動(dòng)設(shè)置異常public APIException(StatusCode statusCode, String message) {// message用于用戶設(shè)置拋出錯(cuò)誤詳情，例如：當(dāng)前價(jià)格-5，小于0super(message);// 狀態(tài)碼this.code = statusCode.getCode;// 狀態(tài)碼配套的msgthis.msg = statusCode.getMsg;}// 默認(rèn)異常使用APP_ERROR狀態(tài)碼public APIException(String message) {super(message);this.code = AppCode.APP_ERROR.getCode;this.msg = AppCode.APP_ERROR.getMsg;}}
那么誰來拋出異常，誰又來處理異常呢？
通常來說，一般拋出業(yè)務(wù)異常的是在service層或者相關(guān)的邏輯業(yè)務(wù)層進(jìn)行，并且配合狀態(tài)碼進(jìn)行拋出：
throw new APIException(AppCode.PRODUCT_NOT_EXIST, "上架商品中無法查詢到：" + orderDetail.getProductId);
然后在調(diào)用者層進(jìn)行處理，這里的調(diào)用者一般指最上層的controller層也就是控制層，進(jìn)行處理，當(dāng)然springboot有統(tǒng)一處理的功能，本質(zhì)是通過AOP對(duì)controller層進(jìn)行攔截異常。有想深入了解的可以參考：《正規(guī)軍springboot如何處理：參數(shù)校驗(yàn)、統(tǒng)一異常、統(tǒng)一響應(yīng)》。
@RestControllerAdvice@Slf4jpublic class ControllerExceptionAdvice {@ExceptionHandler({BindException.class})public ResultVo MethodArgumentNotValidExceptionHandler(BindException e) {// 從異常對(duì)象中拿到ObjectError對(duì)象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);}}
單元測(cè)試
單元測(cè)試的意義并不僅僅在于發(fā)現(xiàn)現(xiàn)有代碼Bug。一個(gè)好的單元測(cè)試可以作為測(cè)試用例固化在項(xiàng)目中，方便程序員進(jìn)行重構(gòu)和修改。如上圖，自己都可能出現(xiàn)不敢刪掉冗余代碼的情況，更何況是重構(gòu)代碼？修改代碼？甚至是接手別人的代碼？在公司中，正常一套代碼會(huì)有AB角之分，保證其中一方跑路跳槽，項(xiàng)目也不會(huì)出現(xiàn)人員斷層，確保項(xiàng)目能正常進(jìn)行：
A角經(jīng)歷開發(fā)的完整周期，對(duì)功能潛在bug往往比B角清楚的多。當(dāng)A角能寫好單元測(cè)試，B角只需重構(gòu)修改好代碼，再重新運(yùn)行一遍單元測(cè)試便可以安心上線
而當(dāng)A角完全不寫單元測(cè)試，B角接手后大概就是。“臥靠，這段tm能不能改??？”，“這不會(huì)有特殊情況吧？”，“這其他地方不會(huì)用到吧？”，“這tm該不會(huì)是業(yè)務(wù)需求討論，為后續(xù)模塊預(yù)留的吧？”……
如果說，公司某個(gè)A角邀請(qǐng)你簽他的AB角生死狀，請(qǐng)先看一下他的單元測(cè)試覆蓋率等指標(biāo)，如果一個(gè)單元測(cè)試都不寫的，打死都不簽！不然改完代碼一上線很可能又是解體操作！
服務(wù)器
這點(diǎn)筆者深有體會(huì)，在大學(xué)期間，總是聽人說服務(wù)器就是一臺(tái)電腦。但是你說任你說，我還是覺得服務(wù)器是一個(gè)高端大氣又特別神秘的東西！自己的代碼永遠(yuǎn)都運(yùn)行在IDEA上，哪怕我知道部署項(xiàng)目的所有步驟，卻一直止步不前，總覺得少了點(diǎn)什么。直到第一次接觸到服務(wù)器，才發(fā)現(xiàn)原本以為這貨真的是個(gè)電腦！這貨真的就是個(gè)Linux！而且通過公網(wǎng)IP、域名真的可以訪問到自己的項(xiàng)目！
如果你也有這方面的困惑，請(qǐng)花一筆幾十塊錢的巨資去買阿里云或者騰訊云買個(gè)服務(wù)器，然后親手實(shí)操一遍，服務(wù)器、公網(wǎng)IP、域名(幾塊錢)這些都是本機(jī)虛擬機(jī)無法模擬的東西！最好學(xué)習(xí)一下docker部署springboot項(xiàng)目，詳見docker部署MySQL、SpringBoot。紙上讀來終覺淺！去實(shí)際操作一把，相信對(duì)你會(huì)有實(shí)質(zhì)上的提升！這里筆者提供給大家學(xué)習(xí)的《一步到位SpringBoot系列》數(shù)據(jù)庫也是部署在服務(wù)器上的。
《一天精通SpringBoot》是不現(xiàn)實(shí)的，如果真是這樣，那Java后端程序員也就太沒有含金量了。麻雀誰小五脹俱全，一個(gè)哪怕再小的小程序項(xiàng)目，只要要上線，就都得經(jīng)歷一個(gè)項(xiàng)目的完整過程，少的可能只是中間件的優(yōu)化。
如果說要學(xué)習(xí)SpringBoot，目標(biāo)已經(jīng)明確就是Java后端，那為什么不一步到位呢？又想學(xué)習(xí)SpringBoot后端的同學(xué)可以參考《一步到位SpringBoot》，保證搭建出一套健壯的，不會(huì)解體操作的后端框架。
《一步到位SpringBoot》鏈接：
https://blog.csdn.net/chaitoudaren/article/details/105624082
版權(quán)聲明：本文為CSDN博主「bugpool」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：
https://blog.csdn.net/chaitoudaren/article/details/105745335
?再見 Python，Hello Julia！
?順豐正式殺入外賣領(lǐng)域；中國移動(dòng)推出 5G 消息 App；GCC 10.1 發(fā)布 | 極客頭條
?你現(xiàn)在從事的程序員還有多久會(huì)消失？牛津大學(xué)研究員幫你算了算
?一次對(duì)語音技術(shù)的徹底批判
?后端程序員必備：書寫高質(zhì)量SQL的30條建議
?到底是哪些人在玩鏈游？| 《區(qū)塊鏈游戲玩家研究報(bào)告》
以上就是關(guān)于pos機(jī)未知返回碼是什么意思,為什么你學(xué)了 N 遍 Spring Boot的知識(shí)，后面我們會(huì)繼續(xù)為大家整理關(guān)于pos機(jī)未知返回碼是什么意思的知識(shí)，希望能夠幫助到大家！
