1. Spring Boot是什麼，解決哪些問題

     1) Spring Boot使編碼變簡單

     2) Spring Boot使配置變簡單

     3) Spring Boot使部署變簡單

     4) Spring Boot使監控變簡單

     5) Spring Boot的不足

2. Spring Boot在平臺中的定位，相關技術如何融合

     1) SpringBoot與SEDA +MicroService + RESTful

     2) SpringBoot與Mock

3. 採用了SpringBoot之後，技術管理應該如何進行

首先，我們來看一下spring boot是什麼，它幫助我們解決了哪些問題

SpringBoot是伴隨著Spring4.0誕生的；

從字面理解，Boot是引導的意思，因此SpringBoot幫助開發者快速搭建Spring框架；

SpringBoot幫助開發者快速啟動一個Web容器；

SpringBoot繼承了原有Spring框架的優秀基因；

SpringBoot簡化了使用Spring的過程。

Spring由於其繁瑣的配置，一度被人認為“配置地獄”，各種XML、Annotation配置，讓人眼花繚亂，而且如果出錯了也很難找出原因。

Spring Boot更多的是採用Java Config的方式，對Spring進行配置。

可以看到，採用了spring-boot-start-actuator之後，直接以REST的方式，獲取程序的執行期效能引數。

當然這些metrics有些是有敏感資料的，spring-boot-start-actuator為此提供了一些Basic Authentication認證的方案，這些方案在實際應用過程中也是不足的。

Spring Boot作為一個微框架，離微服務的實現還是有距離的。

沒有提供相應的服務發現和註冊的配套功能，自身的acturator所提供的監控功能，也需要與現有的監控對接。沒有配套的安全管控方案，對於REST的落地，還需要自行結合實際進行URI的規範化工作。

下面，我們研究一下Spring Boot在平臺中的定位，相關技術如何融合。

上圖比較複雜，整體是採用SEDA，也就是Stage-EDA。可以看到，整體是以處理順序進行展示的，響應過程類似。在處理過程中，主要會有前置過濾，核心功能處理，後置過濾幾大部分。

圖中的過濾器都是可插拔式的，並且可以根據實際場景進行擴充套件開發。每個過濾器都是Stage，比如ClientInstance合法性檢查、呼叫鑑權、解密、限流等等。

一個請求Stage與Stage的轉換，實現上是切換不同的執行緒池，並以EDA的方式驅動。

對於業務邏輯的開發者而言，只需要關心CORE部分的業務邏輯實現，其他的非功能都由框架進行統一實現。

Mock不應當再是測試的專有名詞了，當然對於測試這個角色而言，mockito這樣的工具，依然可以為他們提升不少效率。

SpringBoot為建立REST服務提供了簡便的途徑，相比之下，採用阿里的dubbo在做多團隊、多程序聯調時，mock的難度就陡增。

Mock是解耦並行開發的利器，在理性的情況下，軟體從開發期Mock聯調，到開發與開發的真實聯調，只需要切換一個依賴的域名即可，比如：

mockURI:http://mock.service.net/v1/function?param1=value1

devURI:http://dev.service.net/v1/function?param1=value1

而上述的域名切換，只需要在開發期定義好一個配置項，在做環境切換的時候自動注入即可，省時、省心、省力。

如上圖和docker的整合可以有AB兩種方案：

• A方案的核心是，把docker作為作業系統環境的交付基線，也就是不同的fat jar 使用相同的作業系統版本、相同的JVM環境。但對於docker image來說都是一樣的。

• B方案的核心是，不同的fat jar，獨立的編譯為docker image，在啟動時直接啟動帶有特定版本的image。

A相比與B方案的特點是對於docker registry（也就是docker的映象倉庫）的依賴性較低，對於前期編譯過程的要求也較低。

採用了Spring Boot之後，技術管理應該如何進行？

正因為Spring Boot是與Spring一脈相承的，所以對於廣大的Java開發者而言，對於Spring的學習成本幾乎為零。

在實踐Spring Boot時學習重點，或者說思維方式改變的重點在於：

1）對於REST的理解，這一點尤為重要，需要從設計、開發多個角色達成共識，很多時候都是對於HTTP 1.1協議以及REST的精髓不理解，導致REST被「盲用」而產生一些不好的效果。

2）對於YAML的理解和對於JavaConfig的理解，這兩點相對較為簡單，本質上是簡化了xml檔案，並提供等價的配置表述能力。

1. 豐富的工具鏈為SpringBoot的推廣帶來了利好。

2. SpringBoot的工具鏈主要來自於兩個方面：

    1) 原有Spring積累的工具鏈；

    2) SpringMVC或者其他REST框架使用HTTP協議，使得HTTP豐富的工具成為SpringBoot天然的資源。

SpringBoot自身對於前面提到的配置檔案：“application.yml”提供了多個「Profile」，可以便於開發者描述不同環境的配置，這些配置例如資料庫的連線地址、使用者名稱和密碼。

但是對於企業使用者而言，把不同環境的配置，寫到同一個配置檔案中，是極其不安全的，是一個非常危險的動作。

有一個經常被提及的例子是，隨著開源的進行，很多網際網路公司，都由於把相關的程式碼提交到github之類的開原始碼社群，並且沒有對程式碼進行嚴格的配置審查，導致一些”password”被公開。有些不良用心的人，就利用搜索工具，專門去挖掘這些關鍵字，進而導致資料庫被「拖庫」。

所以對於企業使用者，更多的應該是採用集中式的配置管理系統，將不同環境的配置嚴格區分地存放。

雖然SpringBoot的actuator自身提供了基於「使用者名稱+口令」的最簡單的認證方式，但它保護的是對框架自身執行期的效能指標敏感資料的最基本的保護。這種保護在實際應用過程中，「使用者名稱+口令」的管理是缺乏的，「使用者名稱+口令」的安全配置過程是缺失的。

SpringBoot也不提供對於我們自己開發的功能的任何防護功能。

一般來講，一個安全的通道（資訊傳輸的通道），需要通訊雙方在進行正式的資訊傳輸之前對對方進行身份認證，服務提供方還需要在此基礎之上，對請求方的請求進行許可權的校驗，以確保業務安全。這些內容也需要基於SpringBoot進行外圍的安全擴充套件，例如採用前面提到的S-EDA進行程序級別的安全管控。這些還需要配套的安全服務提供支援。

一般來說，只要企業與網際網路對接，那麼隨便一個面向消費者的「市場活動」，就有可能為企業帶來井噴的流量。

傳統企業內，更多的系統是管理資訊類的支撐系統，這類系統在設計時的主要使用者是企業內部員工以及有限的外部供應商。這類系統存在於企業內部的時間一直很長，功能耦合也很多，在功能解耦前，是非常不適合的，或者說絕對不可以直接為網際網路的使用者進行服務的。

SpringBoot自身並沒有提供這樣的流控措施，所以需要結合前面提到的S-EDA進行流量的控制，並結合下層的水平擴充套件能力（例如，Kubernets）進行流量負載合理的動態擴容。

另外，在長業務流程的設計上，也儘可能地採用非同步的方式，比如介面呼叫返回的是一個「受理號」，而不是業務的處理結果，避免井噴業務到來時，同步呼叫所帶來的阻塞導致系統迅速崩潰，這些也都是SpringBoot自身並不解決的問題。

以上是我分享的主要內容，下面我們總結一下：