目錄
去年的時候，有個朋友，聯合了幾個身邊的朋友，整理了一套java後端目前最常用的工具和框架，有幸，我也在其中，於是我就將一些經常用到的技術整理了一下發給他了，原來覺得沒啥用，沒想到疫情過去之後，公司招聘後端研發團隊成員，從初級到高級全方位招聘，所以就將當時的那份文檔重新整理了一下，整理一份技術棧的資料給他們，但是想來這份文檔也適應於後端開發工程師，所以去掉了敏感內容，把它呈現於此，本文重在概述，畢竟篇幅有限，歡迎「關注」，後續可能把單點拓展成文，詳細地一一闡述，另外筆者見識有限，畢竟也沒有可能在所有大廠工作過，所以如果有疏漏可以在留言處賜教，謝謝
後端開發概述
何爲後端開發？以一個網站爲例，通常來說，前端研發注重頁面的展示，交互邏輯。而後端研發，則注重在發生在前端背後（backend）的邏輯上，例如給前端返回數據，存儲數據。對於一個電商網站，一個簡單的下單動作，後端可能包括商品數據查詢，優惠信息計算，庫存維護，用戶優惠券維護，訂單生成，商家通知觸發等等。在很多大公司前後端的配比是1：3甚至更高，因爲一個複雜的業務系統，前端的展示僅僅是冰山一角，更復雜的業務邏輯都隱藏在後端。
本文將要闡述的技術棧公衆號 Java後端 都有發佈過相關文章，關注 Java後端 公衆號，回覆 666 下載 PDF 版本。
通常來說，當用戶觸發某個行爲後，客戶端會通過http/https請求，和我們的服務器建立連接，發送請求，往往這個請求首先會被鏈接到負載均衡（LB）上，負載均衡根據配置，將請求轉發到內部的API服務上。這些API服務，根據不同的業務邏輯會請求其他服務（Service），這些服務各司其職，例如讀寫某 Mysql 表、讀寫緩存，甚至請求搜索引擎來完成相應的任務。而API服務在完成相應的步驟後，也會將數據返回給客戶端，客戶端根據前端邏輯完成相關的展示。
下面這個圖，簡單的展示了服務端研發可能使用服務組織方式和相關技術棧，後續會對所有技術棧和大廠使用場景一一簡述。
負載均衡 - Load Balance(LB)
負載均衡作爲連接內外的門戶，在分佈式系統中，有這非常核心的作用。下面的圖是負載均衡最直觀的呈現：
它將流量從外部轉發到內部系統，對於同樣的請求內容，不同時序的請求會被轉發到不同的服務實例上。對每個服務實例而言，它只需要承擔系統總流量的 1/N 從而降低了單個服務的負載，提升了服務整體相應速度和系統穩定性。負載均衡器會保持跟蹤所有下游服務的狀態，如果服務不可用，則會被從調度移除。
一個最常用的負載均衡就是Nignx反向代理，在上圖中，如果使用Nginx做負載均衡，最簡單的方法就是配置 upstream，例如下:
#配置負載均衡實例 upstream user_api { server 10.0.6.108:7080; server 10.0.0.85:8980; } #配置轉發到 user_api upstream location /user { proxy_pass http://user_api; }
顯然，這份配置中要指定 user api 服務已經部署實例的 IP 地址和端口。如果沒有自動化的發佈方案，意味着每次開發新的API都需要在服務發佈好以後，更新 Nginx 配置，然後通過 reload nginx 的方式將API發佈上線。如果API不經常變動，這種做法也能支撐業務發展；但是如果公司業務快速發展，經常頻繁發佈API風險就會比較大了。在服務重啓切換配置的過程中，可能導致一些請求處理被丟棄，就連服務擴容和縮容（增加減少負載均衡實例），也要變更相應的nginx配置。
所以很多大廠，都會建設自己的 LB 平臺，在這裏你可以配置需要暴露出去的 URL，提供服務的內部服務標識，也會支持一些額外的配置，包括限流、熔斷參數等。而要做到這些，往往需要對 Nginx 原生的負載均衡能力做拓展，例如使用 dyups 模塊支持動態上下線配置；需要一個額外的管理平臺，來管理所有對外API；需要服務註冊中心維護所有的服務對應的集羣和實例。
同時需要啓動一個 API Watch的在線常駐服務，負責監聽API配置變更和註冊中心每個服務實例的上下線變更，生成 dyups 模塊可以識別的 Nginx 配置，在線 load 到 Nginx 就可以完成服務動態上下線了。原理如下圖：
當然，這只是一個最基本的功能和原理展示，大廠們往往根據不同的在線使用場景會有很多優化和系統設計的考量。
微服務生態
微服務 - 也被稱爲微服務架構 - 一種將整個後端服務，按照領域、模塊分解爲若干獨立小應用的一種架構方式。微服務有如下特點
-
服務可以單獨編寫、發佈、測試、部署，相比於所有功能集中於一體的單體服務，可維護性更強
-
服務彼此之間依賴服務通信的方式鬆耦合
-
按照業務領域來組織服務，每個團隊維護各自的服務
下圖直觀的闡述微服務的概念：
既然微服務體系是按照組織結構、功能模塊獨立進行開發、測試、部署的，那麼微服務架構就要解決因爲獨立部署帶來一些問題，例如通訊協議，遠程調用（RPC），服務發現，服務治理等。有能力的大廠往往會有自己的框架來解決上面的問題，例如淘寶的HSF、阿里開源的 dubbo，能力不足的小廠也可以從開源社區中選擇合適技術爲我所用，“拼湊”出合理的解決方案，下面主要從開源社區選擇一些可用爲我所用的技術來介紹。
Thrift
Thrift不僅僅是一個輕量的，高性能的遠程調用（RPC）通訊協議，也是一個優秀的RPC框架。Thrift 使用一種被稱爲 IDL 的接口定義語言，來定義遠程調用的接口。使用官方提供的工具可以將IDL文件生成微服務服務端（Server）和客戶端（Client）代碼。這裏 Server 端指提供服務的一方，而 Client 則指服務調用方，Client 通過 RPC 對 Server進行調用。
利用這份生成的代碼，就可以實現Client通過指定IP和端口的調用Server服務了。個人感覺 Thrift 最大的優勢是高性能，跨語言，以及足夠輕量。跨語言是很好的特性，因爲一個大公司的不同部門，可能語言技術棧會有差異，使用 Thrift 可以屏蔽這種差異，讓彼此專注。
服務發現
上面提到，如果只依賴 Thrift 我們可以實現通過指定IP端口的方式進行服務調用，但是顯然這是不可行的，我們需要 Client 動態感知 Server 端服務的存在以及提供服務的所有實例。服務註冊中心就是解決這個問題而誕生的概念，可以簡單理解註冊中心就是一個保存着服務狀態的”數據庫“，服務成功啓動後到註冊中心去註冊，並且保持和註冊中心的心跳以維持服務在註冊中心的最新狀態，當服務下線或者異常退出，服務可以主動通知註冊中心下線或者被註冊中心通過心跳失敗感知到。
常見的服務註冊中心例如 Spring Cloud 框架中官方提供的 Eureka，Dubbo 默認使用的 Zookeeper。Spring Cloud 和 Dubbo 也對 Consul 增加了原生支持，這裏也主要介紹下Consul。具體對比可以參考[1]
Consul
Consul是基於GO語言開發的開源工具，主要面向分佈式，服務化的系統提供服務註冊、服務發現和配置管理的功能。Consul的功能都很實用，其中包括：服務註冊/發現、健康檢查、Key/Value存儲、多數據中心和分佈式一致性保證等特性。Consul本身只是一個二進制的可執行文件，所以安裝和部署都非常簡單，只需要從官網下載後，在執行對應的啓動腳本即可。
如果使用 Spring Cloud 或者 Dubbo 等微服務框架，可以通過配置實現使用 Consul 作爲服務註冊中心，服務啓動後，在Consul提供的Web界面就可以查到相應的服務。服務客戶端可以在第一次調用服務端前，通過Consul進行服務端實例的查詢然後按照查詢奧的服務實例進行遠程調用。
Consul 的 web界面：
微服務框架
開源社區中知名的微服務框架包括 Spring Cloud, Dubbo 等，這些框架配合生態中的一切其他組件可以解決例如服務註冊&發現、負載均衡、熔斷限流、調用鏈追蹤等絕大多數問題。不過當業務發展到一定階段，還會有更多問題要解決，例如服務調用鑑權等問題。
所以各個大廠幾乎都自研自己的微服務框架，但是基本的做法都是在開源社區選擇一部分，自己擴展一部分，例如通訊協議和RPC選擇Thrift，服務註冊中心選 Zookeeper/Consul，然後需要自研擴展的部分就是例如服務註冊，服務發現，負載均衡，統一監控，鑑權等公司特色的需求。
數據庫（Database）
對於一個小公司而言，可能會選擇把所有數據保存在 Mysql 中，因爲全部業務數據的容量可能也只有百G。但是對於大廠，每天產生的數據可能都是T級別的，如果都保存在Mysql中會有諸多問題，例如存儲成本、後續的修改查詢效率、高併發場景下存儲的極限能力等。
數據有它不同業務特性和使用場景，業務特性很好理解，例如我們不容忍交易數據發生丟失並且在很多操作它的場景，要求強一致性；而用戶評論，則能容忍很小比例丟失，並且評論計數器和評論數目之前的如果出現微小差距，用戶也很難察覺到；而服務日誌數據，則能容忍更大程度的丟失，只要不影響開發Debug可能就不會有人追究。
數據不同的使用場景，也對存儲有不同方面的要求。例如同樣是用戶資料，用戶資料查看自己的資料，一定要保證資料是用戶最新更新的，並且不能容忍出錯，哪怕是頁面相應速度略微慢一點；但是用在推薦場景作爲用戶畫像作爲模型輸入的時候，就能容忍這個數據不是最新的，但是要求數據訪問速度要高，因爲推薦場景往往對成千上萬個候選排序，畫像數據訪問慢則直接拖累了整個推薦系統的效率。
Mysql
對於Web應用而言，關係型數據庫的選型中 Mysql 無疑是最佳選擇。它體積小、速度快、開源授權使得它擁有成本低，支持多種操作系統，有豐富的社區支持，支持多種語言連接和操作。
Mysql是保存業務數據的理想之選，首先關係型數據庫在設計之初，從概念上就在支持業務數據建模的概念，關係型數據庫能結構化的描述業務需求。Mysql 對ACID屬性的支持，也能滿足不同業務場景下對數據操作的不同訴求。但是在大廠背景下，Mysql也有它的限制。
首先，對於在線大表DDL幾乎不太可能，DDL指表結構變更之類的操作。對於一張動輒幾千萬數據的表，Alter Table 可能需要幾小時，除非提供備案方案，否則服務在這段時間將不可用。
其次，在線查詢要注意性能優化，避免慢SQL拖垮DB的場景。常見的性能問題包括查詢未命中索引而觸發全表掃描；使用了聚合查詢（group by）觸發全表掃描等
還有，大廠特別是ToC常見的大廠，每天產生的業務數據異常的大，Mysql存儲超過幾千萬性能會下降，所以需要使用分庫分表的方式來解決海量數據場景下的存儲問題。
Mycat
Mycat就是一個解決數據庫分庫分表等問題的數據庫中間件，也可以理解爲是數據庫代理。在架構體系中是位於數據庫和應用層之間的一個組件，Mycat 實現了 Mysql 的原生協議，對於應用它感知不到連接了 Mycat，因爲從協議來講，兩者是一樣的。而Mycat將應用的請求轉發給它後面的數據庫，對應用屏蔽了分庫分表的細節。Mycat的三大功能：分表、讀寫分離、主從切換。
下圖通過 Mycat schema 配置和實際 DB 部署來簡要說明 Mycat 分庫分表功能的實現：
例如表 A，配置中它有兩個數據節點，分別是 datanode1 和 datanode2，含義是邏輯表 A實際對應了兩個物理存儲，分別是 db1 和 db2。對於應用而言，應用連接 Mycat 感知到的時候邏輯表 A，而在底層 A 被拆分，存儲在兩個 db 中。
DRC
DRC 是 Data Replication Center 的縮寫，在使用Mysql作爲核心存儲的場景下，我們可以使用Mysql原生的主備方案，實現同城災備。但是如果 Mysql 部署在跨國，跨洲的場景下，原生的災備方案就有諸多問題了，所以各大廠幾乎都有自己的DRC方案。
不過，雖然各自有不同的實現，但是原理和依賴的核心組件基本相同，本文從互聯網上找到餓了麼DRC組件闡述其原理。
本圖中，異地機房分別爲北京機房和上海機房。本地機房（圖中爲北京機房）會啓動一個 DRC Replicator，它和Master節點通信並在通信協議上模擬 Mysql Slave，Replicator將Master數據庫的binlog變更實時拉取到本地。然後把binlog解析，通過消息中間件將變更發送到異地機房（北京機房）。異地機房啓動一個DRC Applier的應用消費數據變更消息，然後把這個變更操作同步到本機房的Master上，就完成了異地數據同步的操作。圖中展示的是北京機房數據同步到上海機房的場景，實際反過來也是一樣。
DRC在設計和實踐中最常見的問題就是DB自增類型主鍵衝突，以及數據因爲同步消息丟失而最後導致的不一致，前者可以通過強制使用ID生成器或者自增ID設置相同的增加值和不同的初始值等方式解決。而後者要麼採用一個規則同步最終數據，或者進行人爲數據干預。
緩存（Cache）
如果稍微深入研究Mysql的存儲原理，我們不難發現，數據是存儲在磁盤中的，雖然我們可以通過索引等數據結構，降低每次查找數據的響應時間，但是對於高併發的在線應用，直接查找數據庫依然很容易觸碰Mysql性能瓶頸，所以我們需要緩存來緩解DB查詢的壓力，當要查詢的數據命中緩存後，直接從緩存中獲取數據，從而降低DB的訪問壓力。常見的緩存有兩種策略：
本地緩存：不需要序列化，速度快，緩存的數量與大小受限於本機內存，很多語言提供一些框架來支持內存緩存，例如 guava cache，spring默認集成的 Ehcache。
分佈式緩存：需要序列化，速度相較於本地緩存較慢，但是理論上緩存的數量與容量無限制（因爲分佈式緩存機器可以不斷擴展），常見的分佈式緩存包括 Redis 和 Memcache。本文主要介紹下 Redis。
Redis
Redis 是基於內存的緩存中間件，正因爲基於內存，所以具有非常快的相應速度。支持豐富的數據結構，例如 string、hashes、list、set、sorted set等等，應用非常廣泛的應用。
常見的緩存讀寫策略包括Cache-Aside，Read Through，Write Through，具體可以參考[2]，不過文中缺少一種Cache 讀寫方案，這也是很多高併發在線應用比較常用的一種方式。
Write Behind Caching模式
Write Behind Caching 這種模式通常是先將數據寫入到緩存裏面，然後再異步地將DB更新的數據寫入到cache中，這樣的設計既可以直接的減少我們對於數據的database裏面的直接訪問，降低壓力，同時對於database的多次修改可以進行合併操作，極大的提升了系統的承載能力。這個模式下，應用在讀數據的時候，不感知DB，只感知Cache，優勢在於簡化了設計，缺點在於強依賴Cache，如果Cache出現問題例如宕機，則讀會失效。
Redis 集羣方案
伴隨着需要緩存的數據量增加和高可用的依賴，大廠的Redis都是需要集羣化方式部署的。一方面通過主從模式提升了系統的高可用，另一方面通過集羣模式將系統演化爲可用無限擴容的模式。
Redis 從 3.0 版本開始，原生的支持了集羣模式，通過 Sentinel 集羣實現動態的主從模式[3]；原生的集羣模式，將所有的數據劃分到 16384 slots中，而集羣中的每個節點，會分配若干 slots。然而原生集羣的方案，雖然簡化了集羣的設計，但是卻增加了客戶端的負擔，需要客戶端對Moved/ASK [4] 事件做封裝處理，同時需要維護路由表提高訪問效率，增加了客戶端設計的複雜度。
所以大廠往往不會選擇 Redis 原生的集羣化方案，而是使用基於Proxy的集羣化方案，業界比較知名開源 Proxy 有 Twemproxy 和 Codis [5]，本文簡要介紹下 Codis，實際上很多知名大廠的 Proxy 都來源於Codis。
Codis 引入了Group的概念，每個Group包括 1 個 Redis Master 及至少1個 Redis Slave，可以認爲每個Group是一個系統分片（Shard），與 Redis-cluster 一樣，Codis 也採用預分片的機制，整個集羣分成 1024 個 slots，通過一致性哈希算法，將Key映射到某個 slot，再通過維護在 Zookeeper 裏的分片路由表，將Key的請求轉發到對應的Group上。
Codis 提供了一套運營監控界面，運維人員可通過 Dashboard “自助式”地進行主從切換。
而對於應用而言，訪問 codis 和訪問原生的 Redis 並沒有任何區別，節點的動態上下線，slot 分配的變更都在 Proxy 層完美的對應用屏蔽了。
KV-DB
前文講述了 Mysql 和 Redis，或許對於大多數公司，這兩類存儲已經足夠。前者用於保存業務數據，後者用於集中式緩存。但是對於大廠，還有若干場景上面兩種存儲無法滿足：例如推薦系統在線預測場景，需要將用戶畫像、商品畫像、商家畫像、用戶商戶交叉畫像在線加載預測上下文，特徵處理後給到模型做預測打分。ToC的互聯網產品的註冊用戶很可能過億，所以用戶畫像總存儲很可能百G甚至T。
如果是這樣規模的數據，Mysql的讀性能肯定扛不住在線預測場景；Redis 是內存緩存，存儲昂貴，同時在容災恢復時候，Redis需要將AOF或者RDB數據載入內存後才能提供服務，數據量過大需要很長的恢復時間。所以需要另外一種存儲能解決這個問題。
幾乎所有大廠都有屬於自己的KV-DB，例如360開源的Pika，餓了麼通過購買Tikv封裝而成Ekv，字節跳動的 Abase。Pika 和 Tikv在存儲底層都使用了RocksDB作爲數據存儲，而RocksDB它是將數據存儲在硬盤上的，Pika 和Tikv在上層構建的都是集羣化方案，主從模式等，基於內存的一致性Cache等。下圖是Pika架構圖：
消息隊列(MQ)
伴隨着業務的複雜，我們往往會遇到這個場景，一個數據操作後，需要觸發下游若干個子操作。例如外賣場景，用戶下訂單成功，要通知商家用戶訂單，要物流平臺對訂單進行調度和派單，要觸發一些後置的風控邏輯對訂單合法性進行校驗等。如果是同步的設計，需要在訂單完成後對後續的操作一一進行API調用，這樣的做法讓訂單流程依賴更多外部服務，提升了業務複雜度，降低了服務的穩定性，所以我們需要消息中間件來解耦操作。依賴的服務依賴下單消息，而不是在下單結束後，通過接口調用的方式觸發。
我們可以把消息隊列（MQ）比作是一個存放消息的容器，Producer 負責生產消息，將消息發送到MQ，Consumer取出消息供自己使用。如圖所示：
消息隊列是分佈式系統中重要的組件，使用消息隊列主要是爲了通過異步處理降低系統耦合性，除此之外，還可以依賴消息隊列提高系統性能和削峯填谷。
關於削峯填谷這裏我舉一個應用場景 —— 搶購。搶購是很多網站促銷的重要場景，呈現方式往往是通過倒計時的方式，在某個固定時間放出限量的優惠產品。開放時間到來時，會有大量用戶觸發購買動作，我們知道下訂單往往是一個耗時比較久的操作，需要對庫存，營銷信息，用戶等多方面數據做查詢、校驗、計算操作，同時爲了控制超賣，可能會引入鎖機制。如果處理不好搶購的瞬時流量，可能會打垮系統。一種優化思路是可以將瞬間的購買請求轉發到消息隊列中，再由消息隊列的消費者消費消息，進行後續的訂單操作，從而對系統進行流量削峯。
從大的應用場景上，我們可以將消息隊列的應用拆分成兩類，一類是業務場景，例如上文提到查到用戶訂單消息，這類場景的吞吐量未必很大，但是需要消息中間件具有一些更高級的易於業務使用的特性，例如支持消息持久化，延遲消息等。另外一類是大數據場景，該類場景對吞吐量有極高的訴求，例如用戶行爲蒐集（User Behavior Tracking）等。這裏只介紹兩種上面場景適合的消息隊列中間件。
RocketMQ
RocketMQ是一款分佈式、隊列模型的消息中間件，是由阿里巴巴設計的，經過多次雙十一流量洪峯的洗禮，讓它更有光環效應；RocketMQ是純java編寫，基於通信框架Netty這也讓它擁有更好的社區基礎和可改造的空間。相比於Kafka，RocketMQ支持很多業務友好的特性，具有以下特點：
支持嚴格的消息順序，支持Topic與Queue兩種模式，億級消息堆積能力，比較友好的分佈式特性，同時支持Push與Pull方式消費消息
Kafka
Kafka 的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，毫秒級的延遲，極高的可用性以及可靠性，而且分佈式可以任意擴展。同時 kafka 最好是支撐較少的 topic 數量即可，保證其超高吞吐量。kafka 唯一的一點劣勢是有可能消息重複消費，那麼對數據準確性會造成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響可以忽略。
對象存儲
對象存儲是面向對象/文件的、海量的互聯網存儲，它也可以直接被稱爲“雲存儲”。對象儘管是文件，它是已被封裝的文件，也就是說，在對象存儲系統裏，你不能直接打開/修改文件，但可以像ftp一樣上傳文件，下載文件等。另外對象存儲沒有像文件系統那樣有一個很多層級的文件結構，而是隻有一個“桶”（bucket）的概念（也就是存儲空間），“桶”裏面全部都是對象，是一種非常扁平化的存儲方式。其最大的特點就是它的對象名稱就是一個域名地址，一旦對象被設置爲“公開”，所有網民都可以訪問到它；它的擁有者還可以通過REST API的方式訪問其中的對象。因此，對象存儲最主流的使用場景，就是存儲網站、移動app等互聯網/移動互聯網應用的靜態內容（視頻、圖片、文件、軟件安裝包等）
不過自建對象存儲成本很高，很多中等規模的廠，都會選擇商業化對象存儲方案，例如七牛雲，阿里OSS等，用來降低研發和維護成本。
Elastic Search
無論是在線應用還是管理後臺，都有模糊搜索的需求，例如用戶搜索感興趣的帖子，評論，視頻。管理員對命中一些關鍵詞的內容進行批量下架等處理。這種模糊搜索，如果使用Mysql原生的查詢，效率是非常低的，能想到的樸素做法可能先將用戶Query進行分詞處理，然後用分詞的結果依次提交到Mysql做某字段的Contains條件查詢。Contains操作會對錶進行全掃描，如果有千萬數據，效率難以想象。
針對這樣的場景，倒排索引是非常理想的方案，倒排索引(Inverted Index)是實現“單詞-文檔矩陣”的一種具體存儲形式，通過倒排索引，可以根據單詞快速獲取包含這個單詞的文檔列表。
如果需要索引的數據不多，索引更新頻率也不高，簡單的做法可以使用 Apache Lucene 構建一個非常輕量的倒排索引，將需要倒排的數據，通過 Lucene 提供的API 灌到索引文件中，而該索引文件可以在後續的搜索服務中被 Lucene 加載，提供查詢服務。
但是大廠場景往往是擁有海量需要索引的數據，同時要支持在線構建索引文件和災備能力，在開源社區中 Elastic Search 就是非常好的選擇之一，ES 底層也是基於 Lucene，但是它提供分佈式的文檔存儲引擎，分佈式的搜索引擎和分析引擎，支持PB級數據。
除此之外，還有其它技術，例如容器、分佈式等等。後面介紹
爲了不掉大家的胃口，我也將這份技術圖譜進行展示，有需要的朋友可以點贊+關注，轉發後私信“體系圖”獲取高清圖，更有精美資料相送
Java後端工程師阿里p5
Java高級架構師阿里p7
由於圖片文件太大了，就不給大家一一詳細截圖，下面只給大家截出部分圖片
阿里P5java後端工程師1
阿里P5java後端工程師2
阿里p7Java高級架構師
圖片每一個技術點都可以放大
阿里p7Java高級架構師2
好了，架構圖已經展示完了，最後是我整理的一些資料，和體系圖基本配套
關注公衆號：Java架構師聯盟，回覆“架構圖”獲取高清圖，更有每日更新技術好文
