Spring家族幾大插件

 

      Spring家族很龐大，從最先先出現的服務於企業級程序開發的Core、安全方面的Security、到後來的做爲各類數據源橋樑的Data、最近幾年很火的Boot，以及最新推出的正在蓬勃發展的Cloud（在本文以後都簡單稱爲Boot、Cloud省略Spring節省一點個人打字時間😊）。

      上面這個腦圖給出了Spring家族主要的一些成員，右側非Cloud部分列的是功能，左側Cloud部分雖然組件繁雜，可是結構清晰（確實新版本清晰多了，命名也統一，你能夠放大圖片看一下這些是否熟悉），因此更進一步列出了組件要的一些模塊依賴和開啓功能的主註解。

0.Spring的發展

Spring框架幾乎涉及到了Java企業級服務開發的全部方面，也幾乎針對全部開發經常使用的模式、中間件、數據庫進行了整合適配。

以前在聊互聯網架構模式的時候我談到過，不少時候咱們寫一個業務把邏輯寫死寫出來是比較容易的，可是把這個邏輯提取成模式進而打包成一個框架來給你們使用，這是比較難的。由於咱們只有經歷過足夠多的場景後才能提取出普適的功能框架，大部分人才能用上，並且咱們須要針對核心功能開放出可配置的部分，知足小部分人進一步定製和擴展功能的須要。

Spring框架經歷了幾個階段：

1.第一個階段推出的Core、Security、Data是把單體應用開發服務好。不只僅提供了便捷的數據庫訪問、Web MVC等必要功能，並且經過AOP、IOC兩大利器讓咱們的程序內在可以作到低耦合可擴展。

2.第二個階段推出的Boot的意義不只僅是加速了開發效率並且能讓咱們的程序從可用變爲好用，應用程序核心業務邏輯可能只有70%的工做量，要讓程序在線上跑的愉快還有30%的監控日誌打點等工做量須要去作。

3.第三個階段推出的Cloud的意義在於推進了微服務架構的落地。讓不具有開發微服務基礎套件的小型互聯網公司也能享受到免費的開箱即用的微服務解決方案。其實不少人不是看了微服務的架構思想去尋找解決方案，而是瞭解到了Spring Cloud纔去瞭解微服務思想從而落地的。

4.目前屬於第四個階段，大力發展Cloud Dataflow+容器。Dataflow的思想是無論是作實時消息處理的服務仍是臨時運行的任務，均可以認爲是服務的組件，若是能夠有一套DSL來定義這些組件之間的交互方式，而後在容器中進行自由組合、部署、伸縮，那麼架構會很是靈活。下圖是Dataflow管理界面的一個示意圖。

      Spring的發展能夠看到互聯網架構的發展，Spring給咱們帶來至關多的技術啓發，從軟件設計模式的啓發慢慢到了架構的啓發，甚至我以爲Spring是爲Java開發打造了架構風格的模板，接下去Spring繼續發展2到3年有望成爲架構標準，我在想這個時候應用架構師何去何從？

1.Spring Core

        Spring Core提供的IOC、AOP功能已經變爲半個Java命根子了。其實不少開發平臺並非那麼強調IOC和AOP，甚至有的平臺徹底沒有相關支持。雖然我一直以爲IOC和AOP是很是好的思想，可讓咱們的軟件內部作到組件之間的低耦合，容易替換，容易擴展，可是個人觀點是，做爲一個類庫不該該把本身組件的初始化以及組裝工做交給外部來作。咱們知道經過IOC容器來管理咱們組件的實例化和依賴，其實咱們能夠在程序內部實現每個組件，把裝配工做交給XML配置進行，可是對於一些複雜的組件，若是這個工做的配置交給XML進行，那麼也就至關於交給了使用者進行，至關於須要使用者必定要理解組件內部的裝配結構，這是不合理的。更合理的方式是，組件或框架的做者提供一些擴展點，讓使用者能夠明確經過API來注入本身的擴展組件或實現組件，而對於只須要簡單使用組件的使用者能夠無需配置開箱即用。

        固然，這不是說Spring的IOC和AOP有什麼很差，正由於框架實現的如此靈活，Java使用Spring做爲容器也基本是標準了，因此Java界不少框架也所以能夠相互進行很好的集成，確實是一個很好的平臺。

        Spring 5推出了Reactive非阻塞技術棧，基於Netty或Servlet 3.1+容器，提供了Stream API、WebFlux以及各類響應式的存儲（各類NOSQL）訪問類庫。從前到後實現非阻塞的服務，能夠避免IO阻塞佔據線程，減小線程切換和資源使用，以最小的資源作到最大化的併發。惋惜的是JDBC目前並無非阻塞的版本，這樣咱們主流的基於MySQL的應用並不能進行全鏈路（從Controller到外部的Rest服務到數據庫）的非阻塞IO（一竿子到底這樣纔是最爽的）。並且對於Reactive套件，我通過簡單的使用我的感受API比較晦澀，鏈式調用可讀性並不高，並且反而遇到了併發的一些坑，加上代碼的示例和最佳實踐如今也不多，我感到如今使用並非特別成熟。

2.Spring Data

       Spring Data但願以相對比較一致的Template API來讓咱們更方便得使用各類數據存儲。我我的不太喜歡習慣使用Data套件而是更喜歡使用各類NOSQL的Java原生客戶端。幾個緣由：

1.原生客戶端緊跟服務端的實現，能夠第一時間體驗到最新的功能

2.原生客戶端的API和服務端提供的API每每一一匹配，能夠一竿子到底，讓咱們功能使用更準確

3.原生客戶端每每只是基於API的簡單封裝，性能更好

       固然，若是咱們只是對NOSQL進行簡單使用的話，Spring Data可能使用起來更方便。

3.Spring Boot

       稍微老一點的Java開發基本都是從純XML配置到XML+註解配置走過來的，比較有意思的是不少開發雖然當初在使用XML配置，可是每每問他們每個配置的含義都不能準確回答出，基本就是拿着主管或前人搭建的一套XML配置直接複製粘貼過來使用。從側面說明了，其實咱們大部分那些Mybatis、Spring MVC的配置都是在幹組件初始化而不是定製化的事情。從0開始要讓一個組件用起來就須要這些基本的配置，既然是這樣的話，其實徹底能夠有默認配置，採用約定大於配置的方式來作。只有在咱們須要針對組件進行定製化的時候纔去作更多配置。

       Spring Boot不但在自動配置、配置簡化上作了不少工做，並且還提供了輕量的嵌入式的容器，只須要20行的Pom+10行代碼，就能夠當即實現一個能夠自啓的應用程序（部署簡單）激發了咱們使用微服務的熱情。此外也給咱們作了不少Production-ready的啓示（Actuator），告訴咱們一個完善的應用程序應當注重環境切換、監控、日誌、打點等等方面。總之，以前咱們可能須要半天時間搭建一個項目，如今經過start.spring.io甚至只須要10秒。在有Boot以前，我實在沒有興趣使用重量級的Java（可能就爲了訪問下數據庫作一些處理，仍是使用Python算了）來建立一個實驗性的控制檯應用程序。

4.Spring Cloud

 

      上圖來自官網首頁，很好地闡述了各個組件之間的關係。咱們來逐一過一下腦圖上的那些組件：

      1.配置管理Cloud Config：提供了客戶端和服務端,客戶端的使用方式和Spring完美結合，服務端提供了Git方式和文件方式的數據存儲，最新版本也提供了數據庫方式。這個配置管理的功能上和以前《朱曄的互聯網架構實踐心得S1E5：不斷耕耘的基礎中間件》一文中我探到的那些配置管理的功能差十萬八千里。

       2.服務發現Netflix Euerka：提供可客戶端和服務端（兼管理臺），這裏的客戶端是指服務發現的使用方，其實微服務中的服務在這裏是客戶端。

       3.斷路器Netflix Hustrix：提供了客戶端API、聚合服務端Tubine和Dashboard網站。

       4.服務網關：有Netflix Zuul和Cloud Gateway兩種網關能夠選擇，後者聽說性能更好。網關其實就是典型的Filter+Handler的實現機制，經過路由找到合適的Handler，而後調用Pre和Post的各類插件式Filter。

       5.調用鏈跟蹤Cloud Sleuth：能夠搭配Zipkin使用，功能只能說湊活用。Zipkin的那後臺功能上和國內主流互聯網實現的Trace後臺功能相比仍是太弱了。

       6.消息驅動Cloud Stream：抽象成爲了產出消息的Source，消費數據的Sink和抓換數據的Processor。而後把Broker的實現經過Binder進行解耦，支持主流的Kafka、KafkaStream和RabbitMQ三種類型。

       7.消息總線Cloud Bus：抽象了MQ的功能，支持主流的MQ產品。

       8.函數即服務Cloud Function：把函數封裝爲Web服務或Stream服務能夠獨立調用。對函數編程的Function、Consumer和Supplier分別映射成爲了Processor、Sink和Source。

        9.微服務契約Cloud Contract：實現契約優先的編程，能夠先定義契約對契約進行測試，同時進行服務實現。複雜的服務能夠用這套方式來作，消費者提供者對着契約本身編本身的，兩不耽誤。

       10.任務框架Cloud Task：非定時任務的概念，這裏的任務是指一次性運行的進程。框架提供了任務執行審計管理最基本的功能。這裏的任務最後能夠在Cloud Dataflow中運行也能夠獨立運行。

        11.管理臺：這裏列的Admin管理臺是第三方提供的，基於Actuator的端點進行信息的綜合展現和監控。

        總結一下，整體上我感受Cloud模塊化的思想很好，模塊和模塊之間能夠相互搭配使用，可是可能一開始沒有進行系統性的規劃，版本的升級帶來的Breaking Changes有點過多，並且由於內容太多了，文檔方面沒有特別全面，要所有用起來坑會比較多，須要享受新功能的話還須要不斷更新框架版本不斷踩坑。

        從目前功能的完善程度來講我感受核心功能完善度在60%（大概還須要發展1年能夠用的比較舒服）。後臺方面過於簡陋，官方提供的後臺零散醜陋並且完成度極低（相比國內一線互聯網在治理這塊開發的功能來講，完善度大概在30%，大概還須要發展2年能夠用的比較舒服，若是能夠好好規劃一套完整的後臺把服務治理全部相關功能都整合在一塊兒就行了）。無論怎麼樣，至少Cloud套件是一套完整的解決方案，目前來看尚未能夠媲美的其它開源選擇可使用（Dubbo咱們也知道雖然如今又開始高速迭代，可是因爲其原始定位是RPC框架，理念上仍是有不少不一樣的，組件方面並無Cloud那麼完善）。

        除了功能不完善，Cloud令我擔憂的還有一點是（我沒測試過，可是由於看到目前功能的迭代速度對這方面信心不足，誰大規模應用了可否能夠給點數據），這些中間件（服務發現、網關服務、鏈路跟蹤、配置管理）是否是通過壓測，是否能夠知足比較大的壓力，若是隻是實現功能的話，可能會在全面用起來後遇到性能瓶頸，在這個時候恐怕就麻煩了。

總結

        Spring家族已是功能強大的龐然大物了，咱們的項目pom中出現幾十個Spring依賴也是屢見不鮮。使用.NET家族的套件也是幾年前的事情了，可是至今我仍是以爲微軟.NET的開發套件無論是MVC仍是ORM仍是RPC方面比Spring的MVC、Data JPA（如今你們都使用Mybatis，Mybatis也仍是太弱了）、Cloud套件在功能和設計的優雅上更勝一籌，但願未來能夠看到Spring針對這些點繼續發力，而且持續打造Dataflow套件，結合K8S打形成一個微服務的OS（各類中間件能夠實現一鍵部署集羣）。另外對於Spring Cloud除了核心功能以外，但願在管理臺方面能夠繼續完善，打造一個一體化（不必定是一個網站，可是至少能夠有權限控制和審計，實現SSO）的管理臺，全面實現微服務部署伸縮、服務治理、數據流程管理、服務全鏈路監控、配置管理等等功能，也期待Spring Cloud和Dataflow雙劍合璧在未來的2到3年定義微服務和以數據爲核心的流處理的架構標準。