Java入門系列-後端前世今生(-2019)

靜態時代(原始時代)

這個時代需要求很簡單,希望輸入一個網址(URL),服務端可返回指定頁面:

靜態頁面(指同一頁面,每個網民在某段時間內看到的內容是相同)時代,web服務端編程複雜度低,業務處理模塊相對較簡單:想辦法根據請求地址(url)找到對於的Html即可

動態時代

隨着web用戶量暴增,用戶希望和服務端有更多交互(動態頁面),如註冊,登錄,留言,發個交友信息等等。業務處理模塊就複雜很多,不止存取html數據,還需存取數據庫數據;返回瀏覽器的數據需根據每次請求不同,組裝成不同的網頁內容。爲提高開發效率,業界做了2件事情:

1. 設計動態web端語言(注:html是靜態web語言),更容易編寫動態頁面數據,如:asp,php等

2. 提供通用的網絡處理模塊,並提供可以解析動態web語言的環境。此時,業界有人將這提供這兩個功能的模塊合起叫web容器。如IIS,Apache等。爲簡單起見,如下示意圖未把asp/php解析器部分畫出了。

asp和php語言設計初衷是快速開發動態web服務端,因此採用的思路是將語言是嵌入html頁面的(如下<?php和?>之間是是動態部分),此類設計的優點是簡單快速,缺點是展示內容和業務邏輯揉在一起,而展示和業務邏輯處理一般是多個工種(頁面設計者及後端碼農)的同事一起完成,當展示和業務邏輯非常複雜時,維護起來就很困難。

Servlet時代(Java web)

Servlet是服務端(Server)小程序(Applet)的意思,可以理解爲實現某些接口的類。Servlet可以簡單對應到上面的業務處理模塊。Servlet規範定義了一些標準接口,Java程序猿只需要實現這些接口即可。

而網絡處理、Servlet調用和維護等事情,Java也定義了一套規範,按照這套規範實現的軟件,叫Servlet容器,大家也叫web容器,其中優秀成員有:tomcat,jetty,jboss等。規範中要求容器有一個配置文件,叫web.xml,裏面可配置哪個url請求對交給哪個Servlet處理

看到上面代碼,你就知道java程序猿只開心了一秒鐘,雖然php是業務邏輯嵌入展示內容,但上面代碼也半斤八兩,展示內容嵌入業務邏輯代碼。

Servlet時代(JSP)

Java官方當然不會這麼傻,用了一招解決此問題,就是設計一個專門用於展示動態頁面的Servlet(解決思路如此簡單,小白你肯定也能想到),這個Servlet有個別名,叫JSP。JSP被設計成PHP/ASP,在HTML頁面內嵌入少量Java代碼以支持動態網頁內容,而業務邏輯處理部分,最好也設計成和網絡無關的,於是Java學霸用JavaBean(也叫Plain Old Java Object (POJO) )處理業務邏輯部分,於是架構變成這樣:

這就是有名的JSP Model 1架構(即頁面驅動方式)。在該架構中JSP負責3重要件事:

 

1)動態頁面展示

 

2)路由請求到具體的JavaBean並對其發起調用

 

3)解析JavaBean返回的數據,並跳轉到相應的頁面。

Model1開發模式

Model1的開發模式是:JSP+JavaBean的模式,它的核心是Jsp頁面,在這個頁面中,Jsp頁面負責整合頁面和JavaBean(業務邏輯),而且渲染頁面,它的基本流程如下:

Model2開發模式

Model2的開發模式是:Jsp+Servlet+JavaBean的模式,它和Model1不同的是,增加了Servlet,將調用頁面數據,調用業務邏輯等工作放到了Servlet中處理,從而減輕了Jsp的工作負擔!它的基本流程如下:

Model2 問題

1.控制器的邏輯可能比較複雜:每個模塊基本需要一個控制器,如登錄模塊對接LoginServlet,新增用戶模塊對AddUserServlet等;

2.請求參數到模型的封裝比較麻煩:http協議傳輸都是文本形式,到Servlet後需要手工將它們轉到一個有不同類型的javabean(如上篇練習題的AccountBean),繁瑣且無技術含量;

3.視圖的選擇嚴重依賴於Servlet API:如resp.sendRedirect("success.jsp"), 很難更換視圖,比如我要支持Excel、PDF視圖等等;

4.給視圖傳入用於展示的模型數據也依賴於Servlet API.

Spring MVC解決問題

1.控制器過於複雜問題:那就將其分爲多個子控制器唄,各負責一部分控制邏輯

2.請求參數轉成模型麻煩:那就單獨設計一個模塊,專門將http文本型參數轉爲javabean內部屬性對應的類型,暫叫DataBinder

3.控制和視圖強耦合問題:那就讓這兩者用一個通用的數據結構進行交互,比如用字符串來表示一個視圖邏輯名,用jsp還是其他視圖模板,控制器不關心,而是由一個單獨的模塊處理,暫叫它ViewResolver。ViewResolver根據視圖邏輯名找到相應具體視圖模板並結合模型數據進行解析。如控制器給視圖模塊傳“success”字符串,ViewResolver根據配置及工程目錄下文件名,找到success.jsp,並用jsp視圖解析器解析success.jsp此模板。

Spring MVC架構圖

上圖只有橙色需自己實現,其他組件框架都實現好了

爲什麼要有Spring

可以看出,每一個方法中都需要進行實例化我們需要用到的接口的實現類,這就會存在大量的實例化對象,並且他們的生命週期可能就是從方法的調用開始到方法的調用結束爲止,加大了GC回收的壓力!

單利模式

可以看出,這種方式有兩個問題:

 

(1)業務代碼與單利模式的模板代碼放在一個類裏,耦合性較高; 

(2)大量重複的單利模式的模板代碼;

 

從上述可以看出,使用的單利模式雖然從性能上有所提高,但是卻加重了我們的開發成本。因此只會小規模的使用,例如我們操作JDBC的Utils對象等。

Spring 容器

IoC(控制反轉,英文含義:Inverse of Control)是Spring容器的內核,AOP、事務等功能都是建立在此基礎上的。從字面意思上可以把IoC拆分爲兩層含義:控制和反轉。控制可以理解爲是接口實現類的選擇權,反轉可以理解爲這個選擇權交給第三方進行管理;總的來說就是某一接口具體實現類的選擇控制權從調用類中移除,轉交給第三方進行決定,即由Spring容器通過Bean配置來進行控制,這樣的話應用程序本身就不用負責依賴對象的創建和維護,而由Spring容器進行管理。

依賴注入的概念和控制反轉的概念從本質上是一樣的,只是從不同的側面描述了這個功能。依賴注入的概念描述的是讓調用類對某一接口實現類的依賴關係有第三方容器或其他東西注入,以此來移除對某一接口實現類的依賴。

Spring 構造方法注入

Spring Set注入

Spring 基於註解的注入

四種註解可以註冊bean,每種註解可以任意使用,只是語義上有所差異:

@Component:可以用於註冊所有bean

@Repository:主要用於註冊dao層的bean

@Controller:主要用於註冊控制層的bean

@Service:主要用於註冊服務層的bean

@Resource:java的註解,默認以byName的方式去匹配與屬性名相同的bean的id,如果沒有找到就會以byType的方式查找,如果byType查找到多個的話,使用@Qualifier註解(spring註解)指定某個具體名稱的bean。

@Autowired:spring註解,默認是以byType的方式去匹配與屬性名相同的bean的id,如果沒有找到,就通過byName的方式去查找,如果byName查找到多個的話,使用@Qualifier註解(spring註解)指定某個具體名稱的bean。

Spring

容器核心組件:

Beans :表示的是spring對所有Bean對象的管理,主要是包含了對象間的關係配置以及一些對象的實例化操作。

Core:包含了最底層的開發支持,例如:依賴的注入關係、資源文件的訪問,數據類型的轉換;

Context:提供的是一個完整的容器上下文,在這個上下文可以處理對象生命週期或者是事務;

SPEL:表達式語言模塊,利用SPEL實現表達式語言的操作,以增強String的功能;

Spring 的問題

隨着使用 Spring 進行開發的個人和企業越來越多,Spring 也慢慢從一個單一簡潔的小框架變成一個大而全的開源軟件,Spring 的邊界不斷的進行擴充,到了後來 Spring 幾乎可以做任何事情了,市面上主流的開源軟件、中間件都有 Spring 對應組件支持,人們在享用 Spring 的這種便利之後,也遇到了一些問題。

Spring 每集成一個開源軟件,就需要增加一些基礎配置,慢慢的隨着人們開發的項目越來越龐大,往往需要集成很多開源軟件,因此後期使用 Spirng 開發大型項目需要引入很多配置文件,太多的配置非常難以理解,並容易配置出錯,到了後來人們甚至稱 Spring 爲配置地獄。

Spring Boot 的誕生

Spring 似乎也意識到了這些問題,急需有這麼一套軟件可以解決這些問題。

Spring Boot 是由 Pivotal 團隊提供的全新框架,其設計目的是用來簡化新 Spring 應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置,從而使開發人員不再需要定義樣板化的配置。用我的話來理解,就是 Spring Boot 其實不是什麼新的框架,它默認配置了很多框架的使用方式,就像 maven 整合了所有的 jar 包,Spring Boot 整合了所有的框架(不知道這樣比喻是否合適)。

Spring Boot 簡化了基於 Spring 的應用開發,通過少量的代碼就能創建一個獨立的、產品級別的 Spring 應用。 Spring Boot 爲 Spring 平臺及第三方庫提供開箱即用的設置,這樣你就可以有條不紊地開始。Spring Boot 的核心思想就是約定大於配置,多數 Spring Boot 應用只需要很少的 Spring 配置。採用 Spring Boot 可以大大的簡化你的開發模式,所有你想集成的常用框架,它都有對應的組件支持。

Spring Boot 特性

  • 使用 Spring 項目引導頁面可以在幾秒構建一個項目

  • 方便對外輸出各種形式的服務,如 REST API、WebSocket、Web、Streaming、Tasks

  • 非常簡潔的安全策略集成

  • 支持關係數據庫和非關係數據庫

  • 支持運行期內嵌容器,如 Tomcat、Jetty

  • 強大的開發包,支持熱啓動

  • 自動管理依賴

  • 自帶應用監控

  • 支持各種 IED,如 IntelliJ IDEA 、NetBeans

Spring Boot 這些特性會給我們研發帶來非常大的優勢,下面我們可以分開來介紹:

使用 Spring Boot 的優勢

使用 Spring Boot 開發項目,會給我們帶來非常美妙的開發體驗,可以從以下幾個方面展開來說明

Spring Boot 讓開發變得更簡單

Spring Boot 對開發效率的提升是全方位的,我們可以簡單做一下對比:

在沒有使用 Spring Boot 之前我們開發一個 web 項目需要做哪些工作:

  • 1)配置 web.xml,加載 Spring 和 Spring mvc

  • 2)配置數據庫連接、配置 Spring 事務

  • 3)配置加載配置文件的讀取,開啓註解

  • 4)配置日誌文件

  • n) 配置完成之後部署 tomcat 調試

可能你還需要考慮各個版本的兼容性,jar 包衝突的各種可行性。

那麼使用 Spring Boot 之後我們需要開發一個 web 項目需要哪些操作呢?

  • 1)登錄網址 http://start.spring.io/ 選擇對應的組件直接下載

  • 2)導入項目,直接開發

上面的 N 步和下面的2步形成巨大的反差,這僅僅只是在開發環境搭建的這個方面。

微服務

1 什麼是微服務

  1. 使用一套小服務來開發單個應用的方式,每個服務運行在獨立的進程裏,一般採用輕量級的通訊機制互聯,並且他們可以通過自動化方式部署。
  2. 如何拆分最小服務單元(不是固定的量化,是一種設計思路)
  3. 微服務特徵:單一職責,輕量級通訊,隔離性,業務數據獨立,技術多樣性。
  4. 微服務誕生背景:互聯網的快速發展,敏捷開發,精益方法,容器技術的成熟

2.微服務架構圖

  1. 業務場景:登錄註冊,發送郵件或者短信,獲取課程列表
  2. 單體架構圖: 

     

  3.  微服務架構圖:

         

3.微服務架構優勢,劣勢

  1. 優勢:獨立性,敏捷性,技術棧靈活,高效團隊。
  2. 劣勢:額外的工作,數據一致性,溝通成本。

 

參考:

Java Web 開發發展簡介 https://www.jianshu.com/p/bec6736dcc3d

Spring Boot 的發展歷程和優點 https://blog.csdn.net/adingyb/article/details/80707471

微服務簡介 https://www.cnblogs.com/jingtyu/p/8745647.html

發佈了209 篇原創文章 · 獲贊 235 · 訪問量 193萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章