注意

希望本系列的教程不管是該spring boot生態系列的原創文章還是Netty RPC的文章，感興趣的小夥伴能夠在PC端閱讀，一起探討學習優化，因為app端閱讀源代碼的體驗並不是很高，影響閱讀體驗，本章並沒有源代碼，不過從下一章就會有部分代碼的貼出，希望大家能夠收藏，常看~感謝

前言

Spring boot2.x作為spring家族中目前比較優秀的一員，已經成為各大企業java開發的首選了，本系列文章將整合工業級的開發工具，初步準備整合如下幾個

Alibaba的RPC框架Dubbo (目前已經成為apache頂級項目)

Alibaba的流量治理熔斷降級框架Sentinel

Alibaba的配置中心Nacos

Alibaba的消息中間件RocketMQ

整合我們經常使用的MYSQL,Redis,ElasticSearch

整合分表分庫框架Sharding-sphere

​ 我們做的也不是簡單地去整合，也會了解其中的原理和機制，瞭解這些中間件周邊的技術，做到融會貫通，這樣才能變成一個合格的程序員

​然後我們需要將我們整合的一套完整的工程(我們可能會寫一個簡單的項目)然後使用Docker去部署，容器化的過程我們也會一步步地進行，先使用docker和docker compose，然後再過渡到容器編排工具docker swarm和kubernetes，並且一起系統地學習這些容器的基本原理，存儲原理，網絡原理。

​本java企業開發系列教程，也會幫助很多2~3年的程序員去了解Netty，並且編寫一個相對完整的RPC框架，讓大家能夠更快地懂得RPC的基本原理，瞭解整個調用的過程，方便大家更好地去運用和總結

​本小節簡單地先介紹一下我們這個系列需要學習的中間件和框架，和其基本的大體功能介紹

一.Dubbo

​作為國內最早的RPC調用框架的典範，在13年開始風靡至今，Dubbo它有的不僅僅是遠程服務調用的功能，還能有部分服務治理的功能，並且它是由國內巨頭阿里巴巴開發，由阿里的工程師背書，它的java代碼治理也是業界的典範，性能也是無法詬病，核心三大能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現

​雖然期間，由於阿里巴巴內部組織架構的調整，Dubbo停止維護了很長時間，但是從去年Dubbo開始被新的團隊重新開始維護，並孵化成Apache的頂級項目，官網地址如下，所以用一個經典的框架去學習RPC是一個很好的選擇

http://dubbo.apache.org/zh-cn/

​再附上，那個RPC那個經典的RPC調用流程圖，一圖恆久遠，知識永流傳

二.Sentinel

​現在微服務化國內盛行，不管是在java還是golang的微服務調用生態過程中，為了防止突發流量和併發，或者為了防止部分請求調用鏈路過長或者因為某種原因，請求處理的時間比較長，或者佔用的資源比較多，或者在請求的時候，系統正在FGC,所以在微服務調用中，一個靈魂的設置就是超時，不要忽視這個超時限制，這樣可以後來的請求全部hold住，然後請求堆積，最後拖垮整個系統，所以流量的控制，請求超時的控制，在微服務的架構中，必不可少，阿里巴巴的Sentinel和Netflix的Hystrix更是流量整理的翹楚。

​Hystrix是老牌的限流熔斷地工具，由國外大佬公司Netflix開源，一直以來的地位也是很穩固，不過最近聽說不再維護，而且源代碼也是Rxjava寫的，看源代碼的門檻比較高，而我們國內的阿里巴巴在去年開源了Sentinel，一個輕量級的流量控制，熔斷降級的類庫，並且在今年開始支持集群限流，並且支持控制檯，可以顯性地看到當前的系統流量

​而且它無縫支持spring boot和Duubo,從生態體系上，更加具有親和性，血緣上就是親戚，更加本土化，官網地址如下

https://github.com/alibaba/Sentinel

核心特性如下圖，我們也會將其整合到spring boot2.x中去，並且整合我們的dubbo調用

三.配置中心Nacos

CICD的普及，代碼配置集中化管理，同樣的代碼，不同的環境卻有不同的配置，現在已經變成了一種趨勢，本地不再有大量的properties配置文件，或者yml配置文件，所有的配置都在遠端，都在配置中心，項目在啟動的時候，第一步就是根據系統配置的配置中心的地址和當前的環境變量，例如“dev”(開發環境)，“test”(測試環境)，“pre”(預發佈環境)，"prd"(生產環境) 來進行http或者tcp請求去動態獲取配置KV值，環境變量信息你在本地開發的時候，可以使用System.setProperty的方法進行配置，在運維人員的手上只需要加一個啟動參數就可以完成不同環境的配置KV信息的加載。

​Nacos的官網地址如下

https://nacos.io/zh-cn

阿里巴巴開源的Nacos,可以完成上述的開發的基本要求，並且它提供的功能比上述的更加強大

1.它可以和zookeeper，etcd等一樣提供服務發現的功能

2.它是一個提供管理頁面的並且能夠動態替換KV的配置中心

3.它無縫支持雲化，支持docker，kubernetes等容器雲平臺

​我們可以使用Nacos來整合我們的spring boot2.x系統，做到企業級應用的腳手架工程了，並且也會去學習其中的源碼，做到心中有數，先附上Nacos的基本架構圖和組件圖，大家可以去官網，先去簡單地瞭解一下其基本的架構和使用方式，以後我們細嗅薔薇~

四.消息中間件RocketMQ

​消息中間件在我們日常開發中，已經成了一個必不可少的工具了，掌握消息中間件是一個合格的業務開發工程師的必要技能，它能提供的最大的兩個特性就是，系統解耦和流量削峰，在我所認識到具體的業務中有如下使用的方式來優化業務系統的關係

1.定時異步計算系統，自己是消息的生產者，自己也是消息的消費者，把非常複雜的邏輯計算處理切割成多個階段，這樣就可以做成多階段計算，每個計算的階段業務邏輯相對獨立，相互不影響，假設你的系統有100個實例，也就有100個生產者，100個消費者，因為消息中間件的出現，你的系統自然而然就變成了分佈式計算系統了，最大程度地提高系統的可用性和每個系統實例的參與度，提供計算的整體性能

2.支付異步通知回調，做過微信和支付寶的支付接口開發的同學都知道，客戶完成支付之後，支付寶和微信都會異步通知後臺系統的支付結果，如果通知失敗，支付寶和微信都會進行重試，都會每隔5s,1mins，15mins ,1hour, 1day ,90days不斷地通知，直到收到你的系統確認成功消費的通知，才會停止，做到最大努力通知，達到數據最終一致性，雖然不知道內部的實現原理，但是這個使用消息中間件可以完美地解決這樣的問題，但可以想象支付寶和微信的支付量，消息中間件的延遲消息的部署實例數應該是一個恐怖的量，但這個不是我們需要考慮的

3.系統解耦，例如訂單系統和財務系統，訂單系統把一些訂單的系統通過MQ扔給財務系統，不需要關心財務系統的處理邏輯，就可以完整訂單模塊的邏輯處理，並返回數據給用戶了，後續的一些給財務的支付訂單數據，並不需要實時做處理，並且在一定程度上允許消費失敗，只需要消息消費者設置失敗重試等，或者一些其他的手段來控制

​消息中間件的產品很多，例如ActiveMQ,RabbitMQ,kafka,RocketMQ等等，本文不去討論各個中間件的好壞，每個產品都有它的特定和長處，我第一次接觸到RocketMQ的時候是15年，當時RcoketMQ基本上也屬於半死狀態，比Dubbo好一點，雖然當時有人維護，但是當時文檔不全，源代碼中各種殭屍代碼，各種代碼不可達，而且當時有人是這麼說的“RocketMQ只能阿里能用，因為它的運維過於複雜，各種系統優化配置不是外部公司能夠駕馭的”，所以當時學的人很多，實際生產運用的人不多，後來阿里巴巴把其捐給了Apache，慢慢地孵化成了apache頂級項目，代碼的健壯性和一些新特性也被加了進來，用的公司也是越來越多，所以我們也會整合rocketMQ到我們的spring boot腳手架中，並且學習RocketMQ的一些核心設計和其核心功能的實現原理，不單單做整合也要做到知其所以然

​RocketMQ目前的官網地址如下

http://rocketmq.apache.org/

五.MYSQL,Redis,Elasticsearch

​目前國內互聯網用的最多的關係型數據庫應該是MySQL,面試問的最多的也是MySQL,例如主從原理，索引優化，B+樹，索引下推，數據庫鎖，存儲引擎，MySQL的執行計劃等等，Spring boot2.x使用MySQL最多的方式還是使用MyBatis加數據庫連接池的方式使用，數據庫連接池高性能的目前主流的有2種，一個是阿里巴巴開源的Druid，一個是HikariCP，我們到時候都會一一整合

​Redis也是我們在平時開發中用的非常多的工具，它能夠做緩存，減少DB的壓力，能夠做分佈式鎖，並提供豐富的數據結構，常用的有5大類型的數據結構，平時開發中也是用的最多，還提供了布隆過濾器，HyberLoglog，BitMap等等的實用的工具，而且面試中，Redis也是必問的一個重要的知識點，5大數據類型底層數據結構，pipeline，單線程模型快的原因，主從原理，Sentinel哨兵機制，緩存雪崩，緩存無底洞，Redis部署的注意點等等都是面試中必問的熱點，所以Redis也是我們整合到Spring boot2.X的重點

​整合到Spring boot 我們一般不會整合的特別重，在java中一般使用jedis，lettuce，兩個實現類上主要是連接到redis服務端的方式不一樣，還有一個是線程安全的問題，在大家熟知的開發中jedis用的比較多，功能也比較完善，jedisPool更是我們經常用的，所以我們在整合的時候，應該會整合基本實現，具體使用結合具體的業務場景

Elasticsearch 說起Elasticsearch,不得不佩服它的成功，它的所屬公司已經上市了，希望國內的PingCAP也能上市成功吧，Elasticsearch是目前最火的搜索引擎了，它是一個基於 JSON 的分佈式搜索和分析引擎，目前用的公司也是越來越多，它的底層是Lucene,不過它屏蔽了Lucene的具體實現，提供了DSL語法，並且提供分佈式存儲，大大提升了搜索的擴展性和可用性，我來說說近幾年我自己使用Elasticsearch的體會吧

1.最簡單的它可以當做數據庫來使用，所有字段不需要進行分詞，所有查詢使用Term匹配，這樣做的好處就是可以保存千萬級甚至數十億級數據，這樣可以解決使用Mysql分表分庫不能聚合的問題

2.它是非常優秀的搜索引擎，它提供了大量的簡單的查詢語法，參數是json，只要按照它的語法就能夠查詢符合你需求的數據，並且支持插件式的分詞方法，支持pinyin，ik等等目前主流的中文分詞插件，並且配置方式非常靈活，可以通過設置mapping，mapping類似數據庫的建表語句，定義好每個字段的類型和屬性，本菜鳥在多個項目使用ES來做搜索，效果和反響都很好，達到預期的效果

3.數據分析，Elasticsearch做數據分析也是非常強大，提供各式各樣的緯度和方式來達到數據分析的效果，並且與Kibana整合，提供非常炫酷的數據展示功能

​本教程也會將elasticsearch整合到spring boot2.x中，但是並不會使用spring-boot-data的方式，而是使用原生的方式，使用elasticsearch提供的原生jar包，這樣做的原因是這樣足夠輕量，api也是比較易懂，並且方便擴展，並且講解elasticsearch的一些基本原理和使用的時候注意事項，方便大家在工作中更加快速的上手Elasticsearch

六.ShardingSphere

​ShardingSphere目前國內比較火的分表分庫的中間件成熟解決方案，我也只是用過ShardingJDBC,其他的我也沒有在實戰項目中使用過，它的定位應該是輕量級Java數據庫JDBC層框架，我們到時候也會根據實際的場景去使用，整合spring boot和ShardingSphere，完成各類場景的分表分庫的使用，這個框架我用的也不是非常多，算是和大家一起學習

ShardingSphere官網

https://shardingsphere.apache.org/document/current/cn/overview/

最後再附上一個SharingJDBC的基本架構圖

七.整個系統docker和kubernetes部署

​在過去的一年，上班的時候一直坐在運維小夥伴的旁邊，也或多或少的學習了一點Docker和kubernetes的知識，再加上自己利用業餘時間學習了一下docker和kubernetes的基本使用，並且現在很多中間件都提供了上雲的支持，所以我們可以嘗試將我們上述的所有的一套東西，完整上雲，體驗一下系統從開發到上線的基本流程和原理，這樣能夠更加開闊自己的視野和系統規範能力

小結

​這是本java系列教程的基礎大綱，估計全部寫完應該要耗費數月之久，我們不僅僅要做整合，部分的原理我們也要掌握，docker的基本原理，基本網絡原理也要基本掌握，各個組件的核心組件和原理也要一一掌握，在整合這些常用的工業級框架的時候，也能夠了解其周邊的產品，將這些點串化，網狀化，形成完整的知識體系，增加我們實戰的能力，也可以在無形中增加自己面試的能力

注意:如果上述內容很多小夥伴關注的話，麻煩大家加一個關注，方便以後再PC端看系列教程的文章，因為接下來的文章我會貼部分核心的代碼實現，在PC端查詢會更加方便，並且也是我們原創寫作的動力，謝謝~