GitHub：https://github.com/yaolingkun/springbootplus
功能：
多數據源
手工配置數據源
注意：
MySQL： 的日期類型建議使用DataTime類型
Oracle: date精確到秒,timestamp精確到毫秒
日誌記錄
使用logback-spring.xml自定義日誌輸出
區分渠道:
http--.do,H5--hl,client--cl,微信--wx
限制請求綁定方法（execute）、參數(Context)、返回值類型(Map)
優點：一個控制層對應一個請求，便於維護
統一返回格式
過濾器
使用FilterRegistrationBean註冊過濾器；
注意：WebFilter註解配合Order註解，排序無效；@Order註解只能用於定義Bean的加載順序，卻真正無法控制Filter排序。
swagger配置
ActionTemplate接口補充swagger使用示例
json格式數據
使用@RestController或者@ResponseBody註解返回的是json格式對象，而不是一個json字符串。
根據實際情況使用jackson
獲取外部自定義配置文件
非application開頭的Properties配置文件
跨域配置
請求頭無數據的原因：請求頭有不安全字段，瀏覽器自發options類型請求預校驗
定時器監控任務
---------------------------------------------待優化-----------------------------------------
增加jwt
全局異常處理
全鏈路跟蹤
---------------------------------------------規則-------------------------------------------
配置文件使用規則：
禁止私自增加配置文件
/config/application.yml 公用變量配置
/config/application-dev.yml 開發環境變量配置
/config/application-test.yml 測試環境變量配置
/config/application-pro.yml 準生產環境變量配置
/config/mappers/mappers0 具體數據源下的mapper路徑，多個路徑用英文逗號隔開
---------------------------------------------補充-----------------------------------------
小知識：
1、springboot 有讀取外部配置文件的方法，如下優先級：
第一種是在jar包的同一目錄下建一個config文件夾，然後把配置文件放到這個文件夾下。（最後被加載）
第二種是直接把配置文件放到jar包的同級目錄。
第三種在classpath下建一個config文件夾，然後把配置文件放進去。
第四種是在classpath下直接放配置文件。（首先被加載）
注意：這裏只針對application的配置文件
在不指定要被加載文件時，默認的加載順序：由裏向外加載，所以最外層的最後被加載，會覆蓋裏層的屬性
2、注：如果在docker裏面運行在jar同目錄下放config目錄也是讀取不到的，Dockerfile裏需要加上一句：ADD config/ /config/
然後讀出來的路徑是：//config/application.properties
3、Mysql 日期
1.DATE、DATETIME和TIMESTAMP 表達的時間範圍
Type Range Remark
DATE '1000-01-01' to '9999-12-31' 只有日期部分，沒有時間部分
DATETIME '1000-01-01 00:00:00' to '9999-12-31 23:59:59' 時間格式爲 YYYY-MM-DD hh:mm:ss，默認精確到秒
TIMESTAMP '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07'UTC 默認精確到秒
2.DATETIME和TIMESTAMP 最大時間精確度
5.7 之後的版本（其實應該說5.6.5），在默認的秒精確度上，可以帶小數，最多帶6位小數，即可以精確到 microseconds (6 digits) precision。
Type Range Remark
DATETIME '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999' 'YYYY-MM-DD hh:mm:ss[.fraction]'
TIMESTAMP '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999' 'YYYY-MM-DD hh:mm:ss[.fraction]'
3.DATETIME和TIMESTAMP 區別
（1） 時間範圍不一樣，TIMESTAMP 要小很多 ，且最大範圍爲2038-01-19 03:14:07.999999，到期也不遠了。
（2）對於TIMESTAMP，它把客戶端插入的時間從當前時區轉化爲UTC（世界標準時間）進行存儲。查詢時，將其又轉化爲客戶端當前時區進行返回。而對於DATETIME，不做任何改變，基本上是原樣輸入和輸出。
4、非簡單請求即是複雜請求
常見的複雜請求有：
請求方法爲 PUT 或 DELETE
Content-Type 字段類型爲 application/json
添加額外的http header 比如access_token
在跨域的情況下，非簡單請求會先發起一次空body的OPTIONS請求，稱爲"預檢"請求，用於向服務器請求權限信息，等預檢請求被成功響應後，才發起真正的http請求。
5、OncePerRequestFilter
大家常識上都認爲，一次請求本來就只過一次，爲什麼還要由此特別限定呢，呵呵實際上我們常識和實際的實現並不真的一樣，經過一番查閱後，此方式是爲了兼容不同的web container，特意而爲之（jsr168），也就是說並不是所有的container都像我們期望的只過濾一次，servlet版本不同，表現也不同。
6、HTTP協議狀態(sc-status)碼的含義
100 Continue 初始的請求已經接受，客戶應當繼續發送請求的其餘部分
101 Switching Protocols 服務器將遵從客戶的請求轉換到另外一種協議
200 OK 一切正常，對GET和POST請求的應答文檔跟在後面。
201 Created 服務器已經創建了文檔，Location頭給出了它的URL。
202 Accepted 已經接受請求，但處理尚未完成。
203 Non-Authoritative Information 文檔已經正常地返回，但一些應答頭可能不正確，因爲使用的是文檔的拷貝
204 No Content 沒有新文檔，瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的
205 Reset Content 沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容
206 Partial Content 客戶發送了一個帶有Range頭的GET請求，服務器完成了它
300 Multiple Choices 客戶請求的文檔可以在多個位置找到，這些位置已經在返回的文檔內列出。如果服務器要提出優先選擇，則應該在Location應答頭指明。
301 Moved Permanently 客戶請求的文檔在其他地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。
302 Found 類似於301，但新的URL應該被視爲臨時性的替代，而不是永久性的。
303 See Other 類似於301/302，不同之處在於，如果原來的請求是POST，Location頭指定的重定向目標文檔應該通過GET提取
304 Not Modified 客戶端有緩衝的文檔併發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還可
以繼續使用。
305 Use Proxy 客戶請求的文檔應該通過Location頭所指明的代理服務器提取
307 Temporary Redirect 和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即使原來的請求是POST，即使它實際上只能在POST請求的應答是303時才能重定向。由於這個原因，HTTP 1.1新增了307，以便更加清除地區分幾個狀態代碼：當出現303應答時，瀏覽器可以跟隨重定向的GET和POST請求；如果是307應答，則瀏覽器只能跟隨對GET請求的重定向。
400 Bad Request 請求出現語法錯誤。
401 Unauthorized 客戶試圖未經授權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示用戶名字/密碼對話框，然後在填寫合適的Authorization頭後再次發出請求。
403 Forbidden 資源不可用。
404 Not Found 無法找到指定位置的資源
405 Method Not Allowed 請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。
406 Not Acceptable 指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容
407 Proxy Authentication Required 類似於401，表示客戶必須先經過代理服務器的授權。
408 Request Timeout 在服務器許可的等待時間內，客戶一直沒有發出任何請求。客戶可以在以後重複同一請求。
409 Conflict 通常和PUT請求有關。由於請求和資源的當前狀態相沖突，因此請求不能成功。
410 Gone 所請求的文檔已經不再可用，而且服務器不知道應該重定向到哪一個地址。它和404的不同在於，返回407 表示文檔永久地離開了指定的位置，而404表示由於未知的原因文檔不可用。
411 Length Required 服務器不能處理請求，除非客戶發送一個Content-Length頭。
412 Precondition Failed 請求頭中指定的一些前提條件失敗
413 Request Entity Too Large 目標文檔的大小超過服務器當前願意處理的大小。如果服務器認爲自己能夠稍後再處理該請求，則應該提供一個Retry-After頭
414 Request URI Too Long URI太長
416 Requested Range Not Satisfiable 服務器不能滿足客戶在請求中指定的Range頭
500 Internal Server Error 服務器遇到了意料不到的情況，不能完成客戶的請求
501 Not Implemented 服務器不支持實現請求所需要的功能。例如，客戶發出了一個服務器不支持的PUT請求
502 Bad Gateway 服務器作爲網關或者代理時，爲了完成請求訪問下一個服務器，但該服務器返回了非法的應答
503 Service Unavailable 服務器由於維護或者負載過重未能應答。例如，Servlet可能在數據庫連接池已滿的情況下返回503。服務器返回503時可以提供一個Retry-After頭
504 Gateway Timeout 由作爲代理或網關的服務器使用，表示不能及時地從遠程服務器獲得應答
505 HTTP Version Not Supported 服務器不支持請求中所指明的HTTP版本
---------------------------------------------建議-----------------------------------------
自問自答：
1. 爲什麼需要手工爲每個數據源配置事務管理器？
沒有使用@Primary註解！
若是使用@Primary的話，各個數據源交叉使用的時候，就給人一種數據源“地位不等”的感覺
使用@Transactional註解時很容易讓人麻痹大意而出錯。
2. 爲什麼需要爲每個數據源配置SqlSessionFactory？
每一次訪問數據庫皆由SqlSession代勞，而SqlSessionFactory正是生產SqlSession的工廠。既然和訪問數據庫有關，那肯定是要區分DataSource的。
3. 需要專門配置SqlSessionTemplate嗎？
不必。因爲mapper接口的實現類MapperProxy在初始化的時候已經初始化了SqlSessionTemplate，參見如下所示MapperProxy的構造函數。