基于 Servlet 容器的 Web MVC
身為 Java 開發者，對于 Spring 架構并不陌生。它起源于 2002 年、Rod Johnson 著作《Expert One-on-One J2EE Design and Development》中的 Interface 21 架構，到了 2004 年，推出 Spring 1.0，從 XML 到 3.0 之後，支援 JavaConfig 設定；進一步，在 2014 年時，除了 Spring 4.0 之外，首次發表了Spring Boot，最大的亮點是采用自動組态，令基于 Spring 的快速開發成為可能。
對 Web 開發者來說，Spring 中的 Web MVC 架構，也一直随着 Spring 而成長，然而由于基于 Servlet 容器，早期被批評不易測試（例如：控制器中包含了 Servlet API）。
不過，從實操 Controller 介面搭配 XML 設定，到後來的标注搭配 JavaConfig，Web MVC 使用越來越便利。如果願意，也可采用漸進的方式，将基于 Servlet API 的 Web 應用程式，逐漸重構為幾乎沒有 Servlet API 的存在，在程式代碼層面達到屏蔽 Servlet API 的效果。
由于不少 Java 開發者的 Web 開發經驗，都是從 Servlet 容器中累積起來的，在這個時候，Web MVC 架構基于 Servlet API，就會是一項優點。因為，雖然運用 Web MVC 編寫程式時，可做到不直接面對 Servlet API，然而，也意味着更強烈地受到 Spring 的限制，有時則是無法在設定或 API 中找到對應方案，有時也因為心智模型還是挂在 Servlet 容器，經驗上難以脫離，在搞不出 HttpSession、ServletContext 對應功能時，直接從 HttpSession、ServletContext 下手，畢竟也是個方法。
編寫程式時，就算沒用到 Servlet API，Web MVC 基于 Servlet 容器仍是事實，因為，底層還是得借助 Servlet 容器的功能，例如 Spring Security，本質上還是基于 Servlet 容器的 Filter 方案。
然而在今日，Servlet 被許多開發者視為陳舊、過時技術的象征，或許是因為這樣，在 Java EE 8 宣布推出的這段期間，當在某些場合談及 Servlet 4.0 之時，總會聽到有人提出“Web Flux 可以脫離 Servlet 了”之類的建議。
實作 Reactive Streams 的 Reactor
Web Flux 不依賴 Servlet 容器是事實，然而，在談及 Web Flux 之前，我們必須先知道 Reactor 項目，它是由 Pivotal 公司，也就是目前 Spring 的擁有者推出，實作了 Reactive Streams 規範，用來支援 Reactive Programming 的實作品。
既然是實作了 Reactive Streams 規範，開發者必然會想到的是 RxJava/RxJava 2，或者是 Java 9 的 Flow API。這也意謂着，在能使用 Web Flux 之前，開發者必須對于 Reactive Programming 典範，有所認識。
開發者這時有疑問了，Spring 為何不直接基于 RxJava 2，而是打造專屬的 Reactive Streams 項目呢？
就技術而言，Reactor 是在 Java 8 的基礎上開發，并全面擁抱 Java 8 之後的新 API，像是 Lambda 相關介面、新日期與時間 API 等，這意謂着，項目如果還是基于 Java 7 或更早版本，就無法使用 Reactor。
在 API 層面，RxJava 2 有着因為曆史發展脈絡的原因，不得不保留一些令人容易困惑或混淆的型态或操作，而 Reactor 在這方面，都有着明确的對應 API 來取代，然而，卻也提供與 RxJava 2（甚至是 Flow API）間的轉換。
另一方面，Reactor 較直覺易用，例如最常介紹的 Mono 與 Flux，實作了 Reactive Streams 的 Publisher界面，并簡化了資訊釋出，讓開發者在許多場合，不用處理 Subscriber 和 Subscription 的細節（當然，這些在 Reactor 也予以實作）。而在 Spring Web Flux 中，Mono 與 Flux 也是主要的操作對象。想知道如何使用Mono與Flux，可以參考〈使用 Reactor 進行反應式程式設計〉
又一個 Web 架構？
到了 Spring 5，在 Reactor 的基礎上，新增了 Web Flux 作為 Reactive Web 的方案，我們在許多介紹檔案的簡單示例，例如〈使用 Spring 5 的 WebFlux 開發反應式 Web 應用〉，就看到當中使用了 Flux、Mono 來示範，而且，程式的代碼看起來就像是 Spring MVC。
這是因為 Web Flux 提供了基于 Java 注解的方式，有許多 Web MVC 中使用的标注，也拿來用在 Web Flux 之中，讓熟悉 Web MVC 的開發者也容易了解與上手 Web Flux，然而，這不過就是新的 Web 架構嗎？
實際上，當然不是如此。Web Flux 并不依賴 Web MVC，而且它是基于 Reactor，本質屬于非同步、非阻斷、Reactive Programming 的心智模型，也是以，如果打算将 Web Flux 運作在 Servlet 容器之上，必須是支援 Servlet 3.1 以上，因為才有非阻斷輸入輸出的支援，雖然 Web Flux 的 API 在某些地方，确實提供了阻斷的選項，若單純隻是試着将基于 Web MVC 的應用程式，改寫為套用 Web Flux，并不會有任何益處，反而會窮于應付如何在 Web Flux 實作對應的方案。
例如，此時，Spring Security 顯然就不能用了，畢竟是 Spring 基于 Servlet 的安全方案，開發者必須想辦法套用 Spring Security Reactive；而且，在儲存方案上，也不是直接采用 Spring Data，而是 Spring Data Reactive 等。
就算能套用相關的設定與 API，要能獲得 Web Flux 的益處，應用程式中相關的元件，也必須全面檢視，重新設計為非阻斷、基于 Reactive Programming 方式，這或許才是最困難、麻煩的部份。
除了基于 Java 注解的方式，讓熟悉 Web MVC 的開發者容易了解之外，Web Flux 還提供了基于函數式的設計與組态方式。
實際上，在運用 RxJava 2/Reacto r等 Reactive Streams 的實操時，我們也都必須熟悉函數式的思考方式，才能充分掌握，這點在 Web Flux 并不例外。
可以脫離 Servlet 容器了？
Servlet 容器是個舊時代的象征，如果能夠屏蔽 Servlet 容器或相關 API，許多開發者應該都會很開心，可以少一層抽象，不必使用肥肥的 Servlet 容器，當然會是使用 Web Flux 時附帶的優點，然而，如果隻是為了屏蔽 Servlet，其實，早就有其他技術選擇存在。
基于 Servlet 一路發展過來的 Web MVC，雖然目前在某些地方可以安插一些函數式的設計，然而，本質上不變的部分在于，在技術堆疊中所隐含的，仍是一個基于同步、阻斷式、指令式的心智模型。如果在這樣的堆疊中，開發者老是因為想要實作非同步、非阻斷、Reactive、函數式而感到不快，Web Flux 也許才會是可考慮的方案，而不單隻是用來作為脫離 Servlet 容器，Web MVC 的替代品。
整體而言，Web Flux 還算是新技術，也還有待時間驗證可行性，如果隻是為了想用 Web Flux 來取代 Web MVC，或者更小一點的野心，隻是想要能脫離 Servlet 容器，最好在采取行動之前，全面檢視一下，确認自身或團隊成員是否準備好接受 Web Flux 的心智模型，或者真的存在着對應的應用場景吧。
總結：繪上一張Kakfa架構思維大綱腦圖（xmind）
其實關于Kafka，能問的問題實在是太多了，扒了幾天，最終篩選出44問：基礎篇17問、進階篇15問、進階篇12問，個個直戳痛點，不知道如果你不着急看答案，又能答出幾個呢？
若是對Kafka的知識還回憶不起來，不妨先看我手繪的知識總結腦圖（xmind不能上傳，文章裡用的是圖檔版）進行整體架構的梳理
資料領取方式：點選這裡免費下載下傳
梳理了知識，刷完了面試，如若你還想進一步的深入學習解讀kafka以及源碼，那麼接下來的這份《手寫“kafka”》将會是個不錯的選擇。
- Kafka入門
- 為什麼選擇Kafka
- Kafka的安裝、管理和配置
- Kafka的叢集
- 第一個Kafka程式
- Kafka的生産者
- Kafka的消費者
- 深入了解Kafka
- 可靠的資料傳遞
- Spring和Kafka的整合
- SpringBoot和Kafka的整合
- Kafka實戰之削峰填谷
- 資料管道和流式處理(了解即可)
fka的整合
- Kafka實戰之削峰填谷
- 資料管道和流式處理(了解即可)
[外鍊圖檔轉存中…(img-hqnD4gfD-1625924646902)]