Java Web系統架構概覽

大型網站系統架構的演進都是隨着業務增加不斷演進，全部的出發點都是爲了知足業務需求。最初訪問量下，功能簡單時，單體軟件能夠解決全部問題；後來訪問量逐漸增大，功能越發豐富，此時單體軟件的架構逐漸成爲開發和運維的瓶頸。因此微服務拆分，集羣化部署，消息中間件，內存數據庫，數據庫中間件等解決方案逐漸走進視野。

下圖爲簡略版的Web系統架構，本文圍繞此圖展開，簡要介紹其中涉及組件的功能和應用場景。

 

回到最初，Web項目的源頭幾乎全來源於用戶的請求(此處忽略運維相關的定時監控等任務)，當海量的請求併發量超過Tomcat服務器的峯值時，Tomcat的集羣化應運而生，與之同時反向代理組件Ngnix走進視野。Ngnix自己做爲入口，其穩定性是關鍵因素，因此利用keepalived實現高可用是正常思惟。

綜上，能夠看到集羣化的目的在於解決單服務能力不足的問題，高可用的機器備份方案是爲了實現系統的穩定運行。可是，在集羣化時又引入了負載均衡，高可用時怎樣實現異常故障自動切換等技術問題，這裏均不深刻討論，僅引入一個概念基礎。另，每一種組件有不少相關的產品，這裏僅針對圖中列出的組件進行介紹。

 

拆分後的微服務部署在不一樣的機器上，服務間如何通訊實現業務調用？先解釋一個概念，調用有同步和異步兩種，同步是在調用時發起方會阻塞線程等待調用結果返回後再往下執行，異步調用是調用方按約定將消息發送出去，不關注調用的執行結果，二者適用的場景不一樣。對應到上圖中同步調用的方案爲Dubbox，消息中間件ActiveMQ爲異步調用。

 

• Dubbox

Dubbox 是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，Dubbox 就是個服務框架，只有在分佈式的時候，纔有Dubbox 這樣的分佈式服務框架的需求，起本質上是個遠程服務調用的分佈式框架。

節點角色說明：

· Provider: 暴露服務的服務提供方。

· Consumer: 調用遠程服務的服務消費方。

· Registry: 服務註冊與發現的註冊中心。

· Monitor: 統計服務的調用次調和調用時間的監控中心。

· Container: 服務運行容器。

調用關係說明：

1. 服務容器負責啓動，加載，運行服務提供者。

2. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。

3. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。

4. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

5. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。

6. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

 

Dubbox推薦使用 zookeeper 註冊中心。註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。因此在服務集成時須要同步部署Zookeeper。

 

• ActiveMQ

消息中間件利用高效可靠的消息傳遞機制進行平臺無關的數據交流，並基於數據通訊來進行分佈式系統的集成。經過提供消息傳遞和消息排隊模型，它能夠在分佈式環境下擴展進程間的通訊。對於消息中間件，常見的角色爲Producer(生產者)、Consumer(消費者)。

ActiveMQ 是Apache的開源項目，是能力強勁的消息總線。ActiveMQ 是一個徹底支持JMS1.1和J2EE 1.4規範的JMS Provider實現。

    什麼是JMS？

JMS（Java Messaging Service）是Java平臺上有關面向消息中間件的技術規範，它便於消息系統中的Java應用程序進行消息交換,而且經過提供標準的產生、發送、接收消息的接口簡化企業應用的開發。

JMS自己只定義了一系列的接口規範，是一種與廠商無關的 API，用來訪問消息收發系統。它相似於 JDBC(java Database Connectivity)：這裏，JDBC 是能夠用來訪問許多不一樣關係數據庫的 API，而 JMS 則提供一樣與廠商無關的訪問方法，以訪問消息收發服務。許多廠商目前都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，這只是幾個例子。 JMS 使您可以經過消息收發服務（有時稱爲消息中介程序或路由器）從一個 JMS 客戶機向另外一個 JML 客戶機發送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關該消息的元數據組成。消息主體則攜帶着應用程序的數據或有效負載。

JMS規定的消息類型有兩種：點對點(一對一)，發佈/訂閱模式(一對多)，咱們在使用消息中間件時只需聽從JMS提供的操做接口進行開發。

 

ActiveMQ集羣化有兩種方式Master/Slave(ActiveMQ5.10開始支持使用Zookeeper搭建集羣)，Broker Cluster。

• Master/Slave實現了主從複製，實現高可用；

• Broker Cluster實現了負載均衡。

能夠將兩種方式結合起來同時實現負載均衡和高可用。

 

爲了進一步緩解服務集羣的壓力，能夠將高頻訪問量大或者資源消耗嚴重的服務單獨拆分出來，如圖中的搜索和文件服務。

• SolrCloud

SolrCloud是Solr提供的分佈式搜索方案，當你須要大規模，容錯，分佈式索引和檢索能力時使用SolrCloud。當一個系統的索引數據量少的時候是不須要使用SolrCloud的，當索引量很大，搜索請求併發很高，這時須要使用SolrCloud 來知足這些需求。

SolrCloud 是基於Solr和Zookeeper的分佈式搜索方案，它的主要思想是使用 Zookeeper做爲集羣的配置信息中心。

它有幾個特點功能：

1）集中式的配置信息

2）自動容錯

3）近實時搜索

4）查詢時自動負載均衡

 

問題來了，何爲Solr?

Apache Solr是一個流行的開源搜索服務器，它經過使用相似REST的HTTP API，構建搜索應用程序。它創建在Lucene(全文搜索引擎)之上。 Solr是企業級的，快速的和高度可擴展的。 使用Solr構建的應用程序很是複雜，可提供高性能。

Solr能夠和Hadoop一塊兒使用。因爲Hadoop處理大量數據，Solr幫助咱們從大的源中找到所需的信息。不只限於搜索，Solr也能夠用於存儲目的。像其餘NoSQL數據庫同樣，它是一種非關係數據存儲和處理技術。

 

使用Solr時須要整合中文分析器，例如IK Analyzer。

IK Analyzer 是一個開源的，基亍 java 語言開發的輕量級的中文分詞工具包。IK已發展爲面向 Java 的公用分詞組件，獨立亍 Lucene 項目，同時提供了對 Lucene 的默認優化實現。在2012版本中，IK 實現了簡單的分詞歧義排除算法，標誌着 IK 分詞器從單純的詞典分詞向模擬語義分詞衍化。

 

Solr如何使用？

咱們能夠利用Spring將Solr服務集成到項目中。Spring Data Sol就是爲了方便Solr的開發所研製的一個框架，其底層是對SolrJ（官方API）的封裝。搜索服務的功能開發參考Spring Data Solr相關接口。

 

• FastDFS

FastDFS 是用 c 語言編寫的一款開源的分佈式文件系統。FastDFS 爲互聯網量身定製，充分考慮了冗餘備份、負載均衡、線性擴容等機制，並注重高可用、高性能等指標，使用 FastDFS很容易搭建一套高性能的文件服務器集羣提供文件上傳、下載等服務。

FastDFS 架構包括 Tracker server 和 Storage server。客戶端請求 Tracker server 進行文件上傳、下載，經過 Tracker server 調度最終由 Storage server 完成文件上傳和下載。

Tracker server 做用是負載均衡和調度，經過 Tracker server 在文件上傳時能夠根據一些策略找到 Storage server 提供文件上傳服務。能夠將 tracker 稱爲追蹤服務器或調度服務器。

Storage server 做用是文件存儲，客戶端上傳的文件最終存儲在 Storage 服務器上，Storage server 沒有實現本身的文件系統而是利用操做系統 的文件系統來管理文件。能夠將Storage稱爲存儲服務器。

服務端兩個角色：

Tracker：管理集羣，tracker 也能夠實現集羣。每一個 tracker 節點地位平等。收集 Storage 集羣的狀態。

Storage：實際保存文件   Storage 分爲多個組，每一個組之間保存的文件是不一樣的。每一個組內部能夠有多個成員，組成員內部保存的內容是同樣的，組成員的地位是一致的，沒有主從的概念。

 

由上圖可知，FastDFS集羣搭建完成後，咱們須要開發client端向服務器發起請求實現文件上傳下載功能，相關開發接口在client的jar包中提供如：fastdfs_client_v1.20.jar。

 

最後，說說數據庫在大型軟件系統中的改變。

• Redis Cluster

爲什麼要搭建Redis集羣。Redis是在內存中以Key-Value格式保存數據的，而電腦內存通常都不大，這也就意味着Redis不適合存儲大數據，Redis更適合處理高併發。爲了擴展設備的存儲能力，搭建服務集羣是正常思路。

Redis 3.0以後版本支持Redis-Cluster集羣，它是Redis官方提出的解決方案，Redis-Cluster採用無中心結構，每一個節點保存數據和整個集羣狀態,每一個節點都和其餘全部節點鏈接。其架構圖以下：

客戶端與 Redis 節點直連,不須要中間代理層。客戶端不須要鏈接集羣全部節點鏈接集羣中任何一個可用節點便可。全部的 Redis 節點彼此互聯(PING-PONG 機制)，內部使用二進制協議優化傳輸速度和帶寬。

 

Redis-Cluster分佈存儲機制-槽

（1）Redis-Cluster 把全部的物理節點映射到[0-16383] slot上，cluster 負責維護node<->slot<->value。

（2）Redis-Cluster中內置了 16384 個哈希槽，當須要在 Redis 集羣中放置一個 key-value 時，Redis 先對 key 使用 crc16 算法算出一個結果，而後把結果對 16384 求餘數，這樣每一個key 都會對應一個編號在 0-16383 之間的哈希槽，Redis 會根據節點數量大體均等的將哈希槽映射到不一樣的節點。

Redis-Cluster容錯機制-投票

（1）選舉過程是集羣中全部master參與,若是半數以上master節點與故障節點通訊超過(cluster-node-timeout),認爲該節點故障，自動觸發故障轉移操做。故障節點對應的從節點自動升級爲主節點。

（2）何時整個集羣不可用(cluster_state:fail)?

若是集羣任意master掛掉，且當前master沒有slave。集羣進入fail狀態，也能夠理解成集羣的slot映射[0-16383]不完成時進入fail狀態.。

 

爲什麼要使用Redis？

高頻高併發的訪問數據庫會給數據庫形成很大的訪問壓力，甚至是癱瘓。爲了解決此問題，咱們可使用Redis將經常使用數據進行緩存，分流訪問流量。

 

如何使用Redis？

相似Solr，Spring提供了Spring Data Redis框架，在Srping應用中經過簡單的配置訪問Redis服務。Spring Data Redis對Reids底層開發包(Jedis,  JRedis, and RJC)進行了高度封裝，RedisTemplate提供了Redis各類操做、異常處理及序列化，支持發佈訂閱，並對Spring 3.1 cache進行了實現。

 

Spring Data Redis針對JRedis提供了以下功能：
1.鏈接池自動管理，提供了一個高度封裝的「RedisTemplate」類。
2.針對jedis客戶端中大量api進行了歸類封裝,將同一類型操做封裝爲operation接口。
ValueOperations：簡單K-V操做
SetOperations：set類型數據操做
ZSetOperations：zset類型數據操做
HashOperations：針對map類型的數據操做
ListOperations：針對list類型的數據操做

 

• MyCat

MyCat是基於cobar(阿里開源產品)演變而來，對 cobar 的代碼進行了完全的重構，使用 NIO 重構了網絡模塊，而且優化了 Buffer 內核，加強了聚合，Join 等基本特性，同時兼容絕大多數數據庫成爲通用的數據庫中間件。

簡單的說，MyCat就是：一個新穎的數據庫中間件產品支持MySQL集羣，或者mariadb cluster，提供高可用性數據分片集羣。你能夠像使用MySQL同樣使用MyCat。對於開發人員來講根本感受不到MyCat的存在。

MyCat分片

分片是指經過某種特定的條件，將咱們存放在同一個數據庫中的數據分散存放到多個數據庫(主機)上面，以達到分散單臺設備負載的效果。

數據的切分(Sharding)根據其切分規則的類型，能夠分爲兩種切分模式。

   （1）一種是按照不一樣的表(或者Schema)來切分到不一樣的數據庫(主機)之上，這種切分能夠稱之爲數據的垂直(縱向)切分。

（2）另一種則是根據表中的數據的邏輯關係，將同一個表中的數據按照某種條件拆分到多臺數據庫(主機)上面，這種切分稱之爲數據的水平(橫向)切分。

MyCat分片策略：

 

數據庫的讀寫分離：

數據庫讀寫分離對於大型系統或者訪問量很高的互聯網應用來講，是必不可少的一個重要功能。對於MySQL來講，標準的讀寫分離是主從模式，一個寫節點Master後面跟着多個讀節點，讀節點的數量取決於系統的壓力，一般是1-3個讀節點的配置。

MyCat讀寫分離和自動切換機制，須要MySQL的主從複製機制配合。