當前位置:編程學習大全網 - 腳本源碼 - 為什麽選擇Spring Boot作為微服務的入門級微框架

為什麽選擇Spring Boot作為微服務的入門級微框架

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:/v1/function?param1=value1

devURI:/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自身並不解決的問題。

下面我們總結壹下:

  • 上一篇:使命召喚6全武器修改方法?
  • 下一篇:我和僵屍有個約會第三部中,有壹段特別好聽的插曲,誰能告訴我?
  • copyright 2024編程學習大全網