大型網站系統架構的演進都是隨着業務增長不斷演進，所有的出發點都是為了滿足業務需求。最初訪問量下，功能簡單時，單體軟件可以解決所有問題；后來訪問量逐漸增大，功能愈加豐富，此時單體軟件的架構逐漸成為開發和運維的瓶頸。所以微服務拆分，集群化部署，消息中間件，內存數據庫，數據庫中間件等解決方案逐漸走進視野。
下圖為簡略版的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的主從復制機制配合。