深度分析：高併發系統架構設計原理,史上最全系列！

架構設計是一系列相關的抽象模式，是人們對一個結構內的元素及元素間關係的一種主觀映射的產物。

1、計算機網絡基礎

A. OSI模型

OSI
Open System Interconnection，簡稱OSI模型或七層模型。
開放系統互連參考模型，是國際標準化組織（ISO）和國際電報電話諮詢委員會（CCITT）聯合制定的開放系統互連參考模型，爲開放式互連信息系統提供了一種功能結構的框架。
OSI模型從低到高分別是：（1）物理層 （2）數據鏈路層 （3）網絡層 （4）傳輸層 （5）會話層 （6）表示層 （7）應用層
1. 物理層
創建、維護、斷開物理鏈接。
由底層網絡定義協議。
2. 數據鏈路層
創建邏輯鏈接、進行硬件地址尋址、差錯校驗等功能。
將比特組合成字節進而組合成幀，用MAC地址訪問介質，錯誤發現但不能糾正。
由底層網絡定義協議。
3. 網絡層
進行邏輯地址尋址，實現不一樣網絡之間的路徑選擇。
主要協議有：ICMP / IGMP / IP（IPV4, IPV6）。
ICMP
Internet Control Message Protocol，Internet控制報文協議，面向無鏈接的協議。
用於在IP主機、路由器之間傳遞控制信息（控制信息是指網絡通不通、主機是否可達、路由是否可用等網絡自己的消息）。
IGMP
Internet Group Management Protocol，互聯網組管理協議。
是TCP/IP協議族中負責IP組播成員管理的協議。
用來在IP主機和與其直接相鄰的組播路由器之間創建、維護組播組成員關係。
IP
Internet Protocol，網際互連協議，根據端到端的設計原則。
IP只爲主機提供一種無鏈接的、不可靠的、盡力而爲的數據報傳輸服務。
4. 傳輸層
定義傳輸數據的協議端口號，以及流控和差錯校驗。
主要協議有：TCP / UDP。
TCP
Transmission Control Protocol，傳輸控制協議。
是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議。
UDP
User Datagram Protocol，用戶數據報協議。
是一種無序創建鏈接就能夠發送封裝的IP數據包的方法。
5. 會話層
創建、管理、終止會話。
對應主機進程，指本地主機與遠程主機正在進行的會話。
6. 表示層
數據的表示、安全、壓縮。
主要格式有：JPEG / ASCII / EBCDIC / 加密格式。
JPEG
Joint Photographic Experts Group，聯合圖像專家組。
是用於連續色調靜態圖像壓縮的一種標準，文件後綴名爲 .jpg 或 .jpeg。
ASCII
American Standard Code for Information Interchange，美國信息交換標準代碼。
是基於拉丁字母的一套電腦編碼系統，主要用於顯示現代英語和其它西歐語言。
7. 應用層
網絡服務與最終用戶的一個接口
主要協議有：HTTP / FTP / TFTP / SMTP / SNMP / DNS / TELNET / HTTPS / POP3 / DHCP。
HTTP
HyperText Transfer Protocol，超文本傳輸協議，是因特網上應用最普遍的一種網絡傳輸協議。
全部的WWW文件都必須遵照這個標準。
HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML文件、圖片文件、查詢結果等）。

HTTP工做原理：
HTTP協議工做於 客戶端~服務端 架構上，瀏覽器做爲HTTP客戶端經過URL向HTTP服務端（即WEB服務器）發送請求。
WEB服務器根據接收到請求後，向客戶端發送響應信息。
HTTP默認端口號爲80，可是也能夠改成8080或者其它端口。
FTP
File Transfer Protocol，文件傳輸協議，是TCP/IP協議族中的協議之一。
FTP協議包括兩個組成部分，（1）FTP服務器 （2）FTP客戶端。
其中FTP服務器用來存儲文件。
用戶可使用FTP客戶端經過FTP協議訪問位於FTP服務器上的資源。
TFTP
Trivial File Transfer Protocol，簡單文件傳輸協議。
是TCP/IP協議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸的協議。
提供不復雜、開銷不大的文件傳輸服務，端口號爲69。
SMTP
Simple Mail Transfer Protocol，簡單郵件傳輸協議，是一種提供可靠且有效的電子郵件傳輸的協議。
SNMP
簡單網絡管理協議，是專門設計用於在IP網絡管理網絡節點（服務器、工做站、路由器、交換機等）。
DNS
Domain Name System，域名系統（服務）協議，是一種分佈式網絡目錄服務。
主要用於域名與IP地址的相互轉換，以及控制因特網的電子郵件的發生。
TELNET
Telnet協議是TCP/IP協議族中的一員，是Internet遠程登陸服務的標準協議和主要方式。
它爲用戶提供了在本地計算機上完成遠程主機工做的能力。
HTTPS
Hyper Text Transfer Protocol over SecureSocket Layer，超文本傳輸安全協議。
是在HTTP的基礎上經過傳輸加密和身份認證保證了傳輸過程的安全性。
它被普遍用於萬維網上安全敏感的通信（例如：交易支付等）。
POP3
Post Office Protocol – Version 3，郵局協議版本3，是TCP/IP協議族中的一員。
主要用於支持使用客戶端遠程管理在服務器上的電子郵件。
DHCP
Dynamic Host Configuration Protocol，動態主機配置協議，是一個局域網的網絡協議。
指的是由服務器控制一段IP地址範圍。
客戶機登陸服務器時就能夠自動得到服務器分配的IP地址和子網掩碼。
B. TCP / IP 模型
TCP/IP 是一個四層協議系統。
TCP/IP模型從低到高分別是：（1）數據鏈路層 （2）網絡層 （3）傳輸層 （4）應用層。
1. 數據鏈路層
對應OSI模型的物理層與數據鏈路層。
數據鏈路層實現了網卡接口的網絡驅動程序，以處理數據在物理媒介上的傳輸。
主要協議有：ARP / RARP。
ARP/RARP主要實現IP地址和機器物理地址（一般是MAC地址）之間的相互轉換。
ARP
Address Resolve Protocol，地址解析協議，是根據IP地址獲取物理地址的一個TCP/IP協議。
RARP
ReverseAddress Resolve Protocol，反地址解析協議。
容許局域網的物理機器從網關服務器的ARP表或者緩存上請求其IP地址。
2. 網絡層
對應OSI模型的網路層。
網絡層實現數據包的選路和轉發。
網絡層的任務就是選擇路由器，以肯定兩臺主機之間的通訊路徑。
網路層最核心的協議是IP協議。
3. 傳輸層
對應OSI模型的傳輸層。
傳輸層爲兩臺主機上的應用程序提供端到端（end to end）的通訊。
傳輸層只關心通訊的起始端和目的端，而不在意數據包的中轉過程。
主要協議有：TCP / UDP。
4. 應用層
對應OSI模型的會話層、表示層、應用層。
應用層負責處理應用程序的邏輯。

C. 網絡基本概念

1. 局域網（Local Area Network（LAN））
局域網是指在某一區域內由多臺計算機互聯組成的計算機組。
局域網能夠由一個辦公室的兩臺計算機組成，也能夠由一個公司內的幾千臺計算機組成。
局域網能夠實現文件管理、應用軟件共享、打印機共享、電子郵件、傳真等功能。
2. 路由器（Router）
是鏈接兩個或多個網絡的硬件設備，在網絡間起網關的做用。
路由器讀取每個數據包中的地址而後決定如何傳送的專用智能型的網絡設備。
路由器會根據信道的狀況自動選擇和設定路由、以最佳路徑、按先後順序發送信號。
3. 廣播
主機之間「一對全部」的通信模式。
網絡對其中每一臺主機發出的信號都進行無條件複製並轉發，全部主機均可以接收到全部信息（不管是否須要）。

例：有限電視網就是典型的廣播型網絡。
4. mac地址
指網卡的地址，每塊網卡出廠時都被燒製上一個世界惟一的mac地址，長度爲48位的二進制。
一般由12位16進制數表示（前6位是廠商編號，後6位是流水線號）。
5. IP地址 與 IP協議
規定網絡地址的協議叫IP協議。
IP協議的做用主要有兩個，一個是爲每臺計算機分配IP地址，另外一個是肯定哪些地址在同一個子網絡。
IP協議定義的地址稱之爲IP地址，普遍採用的是ipv4，由32位二進制表示。範圍0.0.0.0 ~ 255.255.255.255。
6. 端口
一臺擁有IP地址的主機所對應的不一樣服務。
經過不一樣的IP地址能夠獲取不一樣主機，經過「IP地址 + 端口號」來區分不一樣的服務。

例：WEB服務、FTP服務、SMTP服務，這些服務能夠由一個IP地址來實現，但不一樣的服務則對應不一樣的端口。
7. 子網掩碼
表示子網絡特徵的一個參數。
子網掩碼不能單獨存在，它必須結合IP地址一塊兒使用。
子網掩碼只有一個做用，就是將某個IP地址劃分紅網絡地址和主機地址兩部分。

2、 高併發架構設計基本概念

A. 分佈式系統
系統中的多個模塊在不一樣服務器上的部署。
一組獨立的計算機展示給用戶的是一個統一的總體。

例：Tomcat與數據庫分佈部署在不一樣的服務器上。
B. 系統集羣
一個特定領域的軟件部署在多臺服務器上並做爲一個總體提供一類服務。
在集羣中，多臺服務器內容、工做過程等徹底同樣，客戶端能夠鏈接任意一個節點得到服務。
而且當集羣中一個節點掉線時，其它節點能夠自動的接替它繼續提供服務。
C. 系統高可用性
一般來描述一個系統通過特殊的設計，從而減小停工時間，而保持其服務的高度可用性。
系統中部分服務器掉線時，其它服務器可以接替它繼續提供服務，則可認爲系統具備高可用性。
D. 負載均衡
將負載（工做任務）進行平衡、分攤到多個操做單元上進行運行。
當客戶端請求發送到系統時，經過某種算法把請求分發到多個可用的服務器上。
使系統中每一個服務器都可以均勻的處理請求。
E. 代理
當客戶端沒法直接跟服務端發起請求的時候，就須要代理服務。代理分爲：（1）正向代理 （2）反向代理
1. 正向代理
正向代理 是一臺 位於客戶端和目標服務器之間的 代理服務器。
當客戶端須要獲取目標服務器中的數據時、先向代理服務器發送請求並指定目標服務器。
由代理服務器向目標服務器發送請求獲取數據、並將獲取到的數據返回給客戶端。
正向代理的做用
訪問客戶端不能訪問的資源。
對客戶端訪問進行受權、認證。
能夠作緩存，加速訪問資源。
記錄用戶訪問記錄，對外隱藏用戶信息。
2. 反向代理
反向代理 也是一臺位於客戶端和服務器之間的代理服務器。
可是客戶端並不知道目標服務器，當客戶端須要獲取目標服務器中的數據時、先向代理服務器發送請求。
由代理服務器將請求轉發給內部網絡上的服務器，並將從目標服務器上獲取到的數據返回給客戶端。
反向代理的做用
保證內網的安全，阻止web***。
負載均衡，經過反向代理服務器優化網站的負載。

3、 軟件架構設計中經常使用的技術

A. Tomcat
是一個免費的開源代碼的web應用服務器，屬於輕量級應用服務器。
在中小型系統和併發訪問用戶不是不少的場合下被廣泛使用，是開發和調試JSP程序的首選。
B. Nginx
engine x，是一款自由的、開源的、高性能的HTTP和反向代理web服務器。
同時也提供了IMAP/POP3/SMTP服務。
C. LVS
Linux Virtual Server，即Linux虛擬服務器，是一個虛擬的服務器集羣系統。
使用集羣技術和Linux操做系統實現一個高性能、高可用的服務器。
D. F5
F5負載均衡服務器（硬件）。
F5 BIG_IP提供12種靈活的算法將全部流量均衡的分配到各個服務器。
優勢
可以直接經過智能交換機實現，處理能力更強，並且與系統無關，負載性能強，適用於大訪問量、簡單的應用。
缺點
成本高，配置冗餘。
E. Docker
Docker是一個開源的應用容器引擎，讓開發者能夠打包他們的應用以及依賴包到一個可移植的鏡像中。
而後發佈到任何流行的Linux或Windows機器上。
也能夠實現虛擬化，容器是徹底使用沙箱機制，相互之間不會有任何接口。
F. NoSQL
非關係型數據庫。
NoSQL也稱Not Only SQL的縮寫，是對不一樣於傳統的關係型數據庫的數據庫管理系統的統稱。
NoSQL適用於超大規模數據的存儲，這些類型的數據存儲不須要固定的模式，無需多餘操做就能夠橫向擴展。
NoSQL知足CAP定理（CAP定理見分佈式章節），而非ACID屬性。
1. NoSQL優勢
高可擴展性。
分佈式計算。
低成本。
架構的靈活性，半結構化數據。
沒有複雜的關係。
2. NoSQL缺點
沒有標準化。
有限的查詢功能。
3. NoSQL的數據庫分類
（key, value）鍵值對存儲
能夠經過key快速查詢到其value，通常來講，存儲無論value的格式。

如：Redis，Oracle BDB。
列存儲
按列存儲數據，方便存儲結構化和半結構化，方便作數據壓縮。

如：HBase，Cassandra。
文檔存儲
通常用相似json的格式存儲，存儲的內容是文檔型的。

如：MongoDB，CouchDB。
圖像存儲
圖形關係的最佳存儲。

如：Neo4J，FlockDB。
對象存儲
經過相似面嚮對象語言的語法操做數據庫，經過對象的方式存取數據。

如：db4o， Versant。
Xml數據庫
高效的存儲XML數據，並支持XML的內部查詢語法。

如：Berkeley DB XML， BaseX。
G. Redis
Redis是徹底開源免費的，遵照BSD協議，是一個高性能的（key - value）數據庫。
Redis是一個開源的使用ANSI C語言編寫，提供多種語言的API。
Redis一般被稱爲數據結構服務器。
1. Redis特色
Redis支持數據的持久化，能夠將內存中的數據保存在磁盤上，重啓的時候能夠再次加載進行使用。
Redis不只僅支持簡單的（key - value）類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
Redis支持數據的備份，即master-slave模式的數據備份。

Redis性能極高，讀的速度是 110000次/s，寫的速度是81000次/s。
Redis的全部操做都是原子性的。
2. Redis支持五種數據類型
（1）String（字符串）。
（2）hash（哈希）。
（3）list（列表）。
（4）set（集合）。
（5）zset（sorted set：有序集合）。
String（字符串）
String是redis最基本的類型，一個key對應一個value。
String類型是二進制安全的，也就是string能夠包含任何數據。
String類型的值最大能存儲512MB。

例：
DEL key ：刪除key。
SET key value ：存儲數據。
GET key ：根據key獲取數據。
Hash（哈希）
Redis hash是一個鍵值（key=>value）對集合。
Redis hash是一個String類型的field和value的映射表，hash特別適合用於存儲對象。

例：
HDEL key field ：刪除一個field字段。
HMSET key field1 value1 field2 value2 ：存儲數據
HGET key field1 ：根據key獲取對象field1的值
HGET key field2 ：根據key獲取對象field2的值
List（列表）
Redis列表是簡單的字符串列表，按照插入順序排序，也能夠添加一個元素到列表的頭部或者尾部。
列表最多可存儲2^32 – 1個元素（4294967295， 每一個列表可存儲40多億個元素）。

例：
LPOP key ：移出並獲取到列表的第一個元素。
LPUSH key values ：添加一個元素到key對應的list列表中。
LRANGE key begin end ：獲取list列表指定範圍內的元素。
LREM key count value ：移除列表元素。
Set（集合）
Redis的Set是String類型的無序集合。
集合是經過哈希表實現的，因此添加、刪除、查找的複雜度都是O(1)。
集合最多可存儲2^32 – 1個元素（4294967295， 每一個集合可存儲40多億個元素）。

例：
SPOP key ：移除並返回集合中的一個隨機元素。
SADD key member ：添加一個元素到key對應的set集合中，成功返回1，若是元素已存在返回0。
SMEMBERS key ：獲取集合中的全部成員。
zset（sorted set：有序集合）
和set同樣，也是String類型元素的集合，且不容許重複的成員。
zset爲每一個元素都關聯一個double類型的分數，redis經過分數來爲集合中的成員進行從小到大的排序。
zset的成員是惟一的，但分數（score）卻能夠重複。

例：
ZREM key member ：移除有序集合中的一個成員。
zadd key score member ：添加元素到集合，元素在集合中存在則更新對應的score。
ZRANGEBYSCORE key min max ：經過分數返回有序集合指定區間內的成員。

3. Redis事務
Redis事務能夠一次執行多個命令，而且帶有三個重要的保證：
批量操做在發送EXEC命令前被放入隊列緩存。
收到EXEC命令後進入事務執行，事務中任意命令執行失敗，其他的命令依然被執行。
在事務執行過程當中，其它客戶端提交的命令請求不會插入到事務執行命令序列中。
一個事務從開始到執行經歷三個階段
開始事務
命令入隊
執行事務
事務函數
MULTI ：開始事務
EXEC ：執行事務
DISCARD ：取消事務

WATCH key[key …] ：監視一個（或多個）key。
若是在事務執行以前這個（或這些）key被其它命令所改動，那麼事務將被打斷。

UNWATCH ：取消WATCH命令對全部key的監視。
H. ElasticSearch
ElasticSearch是一個基於Lucene的搜索服務器。
它提供了一個分佈式多用戶能力的全文搜索引擎。
ElasticSearch基於RESTful web接口，用Java語言開發，是一種流行的企業級搜索引擎。
ElasticSearch底層採用了分段的存儲模式，使它在讀寫時幾乎徹底避免了鎖的出現，大大提高了讀寫性能。
實現原理
首先用戶將數據提交到ElasticSearch數據庫中。
再經過分詞控制器將對應的語句分詞，將其權重和分詞結果一併存入數據。
當用戶搜索數據的時候，再根據權重將結果排名、打分，最後返回結果呈現給用戶。
I. HDFS
Hadoop Distributed File System，是指適合運行在通用硬件上的分佈式文件系統。
HDFS是分佈式計算中數據存儲管理的基礎，是基於流數據模式訪問和處理超大文件的需求而開發的。
1. HDFS特色
高容錯性、可構建在廉價機器上。
適合批處理。
適合大數據處理。
流式文件訪問。
2. HDFS侷限
不支持低延遲訪問。
不適合小文件存儲。
不支持併發寫入。
不支持修改。
3. HDFS底層架構
HDFS是一個主/從（Mater/Slave）體系結構，HDFS集羣擁有一個NameNode和一些DataNode。
NameNode管理文件系統的元數據，DataNode存儲實際的數據。
HDFS Client
客戶端，提供一些命令來管理、訪問HDFS，好比啓動或者關閉HDFS。
與DataNode交互，讀取或者寫入數據。
讀取時，要與NameNode交互，獲取文件的位置信息。
寫入HDFS的時候，Client將文件切分紅一個一個的Block，而後進行存儲。
NameNode
即Master，管理HDFS的名稱空間。
管理數據塊（Block）映射信息。
配置副本策略。
處理客戶端讀寫請求。
DataNode
即Slave，NameNode下達命令，DataNode執行實際的操做。
存儲實際的數據塊。
執行數據塊的讀/寫操做。
Secondary NameNode
並不是NameNode的熱備，當NameNode掛掉的時候，它並不能立刻替換NameNode並提供服務。
輔助NameNode，分擔其工做量。
按期合併fsimage和fsedits，並推送給NameNode。
在緊急狀況下，可輔助恢復NameNode。
J. zookeeper
zookeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務。
zookeeper主要是用來解決分佈式應用中常常遇到的一些數據管理問題。
提供的功能包括：配置維護，域名服務，分佈式同步，組服務等。
zookeeper功能很是強大，能夠實現諸如分佈式應用配置管理、統一命名服務、狀態同步服務、集羣管理等功能。

例：
假設咱們的程序是分佈式部署在多臺機器上，若是咱們要改變程序的配置文件。
須要逐臺機器去修改，很是麻煩。
如今把這些配置所有放到zookeeper上去，保存在zookeeper的某個目錄節點中。
而後全部相關應用程序對這個目錄節點進行監聽。
一旦配置信息發生變化，每一個應用程序就會收到zookeeper的通知。
而後從zookeeper獲取新的配置信息應用到系統中。
1. zookeeper數據結構
zookeeper與標準的文件系統很是類似，也是用「/」表示上下層級關係。
zookeeper的數據存儲結構就像一顆樹，這顆樹由節點（zNode）組成。
zookeeper分爲服務端和客戶端，由客戶端來操做節點。

zookeeper的每一個節點均可以作ACL（Access Controller List）權限控制。
權限分爲：CREAT，READ，WRITE，DELETE，ADMIN，ALL。
2. zNode節點
每一個zNode節點都能存儲數據，每一個zNode默認存1M的數據，能夠用配置最大存4M數據。
zookeeper有4種節點類型
持久節點（PERSISTENT）
默認的節點類型，建立節點的客戶端與zookeeper斷開鏈接後，該節點依然存在。
持久排序節點（PERSISTENT_SEQUENTIAL）
所謂排序節點，就是在建立節點的同時，zookeeper根據建立的時間順序給該節點名稱進行編號。
臨時節點（EPHEMERAL）
和持久節點相反，當建立節點的客戶端與zookeeper斷開鏈接後，臨時節點也會被刪除。
臨時排序節點（EPHEMERAL_SEQUENTIAL）
在建立節點時，zookeeper根據建立的時間順序給該節點名稱進行編號。
當建立節點的客戶端與zookeeper斷開鏈接後，臨時節點也會被刪除。
K. MQ
全稱Message Queue，消息隊列。
消息隊列中間件是分佈式系統中重要的組件。
消息隊列主要解決應用耦合、異步消息、流量削鋒、日誌處理等問題。
實現高性能、高可用、可伸縮和最終一致性架構，是大型分佈式系統不可缺乏的中間件。

消息隊列也可簡單理解爲在消息的傳輸過程當中保存消息的容器。
消息隊列的主要目的是提供路由並保證消息的傳遞。
若是發送消息時接收者不可用，消息隊列會保留消息，直到能夠成功地傳遞它。
1. 消息隊列使用案例
以下圖所示：使用消息隊列應用於日誌的技術架構體系。

日誌採集客戶端
負責日誌數據採集，定時寫入消息隊列（Kafka）中。
消息隊列（Kafka）
負責日誌數據的接收，存儲和轉發。
Logstash
日誌解析，統一成JSON輸出給Elasticsearch。
Elasticsearch
實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，經過index組織數據，兼具強大的搜索和統計功能。
Kibana
基於Elasticsearch的數據可視化組件，提供超強的數據可視化能力。
2. JMS消息服務
JMS（Java Message Service），Java消息服務，是一個消息服務的標準規範。
容許應用程序組件基於JavaEE平臺建立、發送、接收和讀取消息。
它使分佈式通訊耦合度更低，消息服務更加可靠以及異步性。

JMS標準中，有兩種消息模型：（1）P2P（Point to Point）； （2）Publish / Subscribe（Pub/Sub）。
P2P（Point to Point）
每一個消息都被髮送到一個特定的隊列中，接收者從隊列中獲取消息。
隊列保留着消息，直到它們被消費或超時。

P2P特色：
每一個消費只有一個消費者（Consumer），一旦被消費，消息就再也不保留在消息隊列中。
發送者和接收者之間沒有時間上的依賴性。
接收者在成功接收消息以後需向隊列應答成功。
Pub/Sub模式
多個發佈將消息發送到Topic，系統將這些消息傳遞給多個訂閱者。

Pub/Sub特色：
每一個消息能夠有多個消費者。
發佈者和訂閱者之間有時間上的依賴性。
爲了消費消息，訂閱者必須保持運行的狀態。
JMS中能夠經過兩種方式來消費消息：
同步
訂閱者或接收者經過receive()方法接收消息。
receive()方法在接收到消息以前（或超時以前）將一直阻塞。
異步
訂閱者或接收者能夠註冊爲一個消息監聽器。
當消息到達以後，系統自動調用監聽器的onMessage()方法。
3. JMS編程模型
ConnectionFactory
建立Connection對象的工廠，針對兩種不一樣的JMS消息模型。
分別有QueueConnectionFactory和TopicConnectionFactory兩種。
Destination
Destination的意思是消息生產者的消息發送目標或者說消息消費者的消息來源。
Connection
Connection表示在客戶端和JMS系統之間創建的鏈接（對TCP/IP Socket的包裝）。
Connection能夠產生一個或多個Session。
Connection也有兩種類型：QueueConnection和TopicConnection。
Session
Session是操做消息的接口，能夠經過session建立生產者、消費者、消息等。
Session提供了事務的功能，當須要使用session發送/接收多個消息時。
能夠將這些發送/接收動做放到一個事務中。
一樣也有兩種類型：QueueSession和TopicSession。
消息生產者
消息生產者由Session建立，並用於將消息發送到Destination。
也有兩種類型：QueueSender和TopicPublisher。
消息消費者
消息消費者由Session建立，用於接收被髮送到Destination的消息。
也有兩種類型：QueueReceiver和TopicSubscriber。
可分別經過session的createReceiver(Queue)或createSubscriber(Topic)建立。
MessageListener
消息監聽器。
若是註冊了消息監聽器，一旦消息到達，將自動調用監聽器的onMessage()方法。
4. 經常使用消息隊列
ActiveMQ
ActiveMQ是Apache出品的，是最流行、能力最強勁的開源消息總線。

ActiveMQ特性：
多種語言和協議編寫客戶端。
徹底支持JMS1.1和J2EE1.4規範（持久化，XA消息，事務）。
對Spring的支持。
支持多種傳送協議：TCP，UDP，SSL。
支持經過JDBC和journal提供高速的消息持久化。
從設計上保證了高性能的集羣，客戶端-服務器，點對點。
支持Ajax，支持與Axis的整合。
RabbitMQ
RabbitMQ是流行的開源消息隊列系統。
支持Ajax、持久化，用於在分佈式系統中存儲轉發消息。
ZeroMQ
號稱史上最快的消息隊列，ZeroMQ是一個簡單好用的傳輸層。
像框架同樣的一個socket library，它使得socket編程更加簡單、簡潔和性能更高。

特色：
高性能、非持久化，可單獨部署或集成到應用中使用，可做爲socket通訊庫使用。
Kafka
Kafka是一種高吞吐量的分佈式發佈訂閱消息系統。
它能夠處理消費者規模的網站中的全部動做流數據。

4、 分佈式中經常使用的技術

A. CAP原則
CAP原則又稱CAP定理，在一個分佈式系統中，CAP原則指的是如下三條要素最多隻能同時實現兩條、不可能三者兼顧。
1. 一致性（Consistency）
在分佈式系統中的全部數據備份，在同一時刻是不是一樣的值。
也就是說分佈式系統中的全部節點訪問同一份最新的數據副本。
2. 可用性（Availability）
在分佈式系統中部分節點故障後，系統總體是否還能響應客戶端的讀寫請求 ？
在分佈式系統中，提供的服務要一直保持可用，而且是正常的響應時間。
3. 分區容錯性（Partition tolerance）
在分佈式系統中，遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性或可用性的服務。
B. 分佈式通訊技術
進程間通訊（IPC）是在多任務操做系統或聯網的計算機之間運行的程序和進程所用的通訊技術。
兩種類型的進程間通訊（IPC）
本地過程調用：共享內存空間、使任務同步和互相發送信息。
遠程過程調用：經過網絡進行傳輸（RPC）。
1. JAVA NIO
全稱Java non-blocking IO，提供緩存支持的數據容器，Java NIO能夠提供非阻塞式的高伸縮性網絡。

JAVA NIO有三大核心：（1）Channel（通道）； （2）Buffer（緩存區）； （3）Selector。
Channel
也稱「通道」，Channel是雙向的，便可以用來進行讀操做，也能夠用來進行寫操做。
Channel有點相似IO流，不一樣點是IO流是單向的，Channel是雙向的。

JAVA NIO的Channel主要實現有：
FileChannel：從文件中讀寫數據。
DatagramChannel：經過UDP讀寫網絡中的數據。
SocketChannel：經過TCP讀寫網絡中的數據。
ServerSocketChannel：監聽新進來的TCP鏈接，對每個新進來的鏈接都會建立一個SocketChannel。
Buffer（緩存區）
JAVA NIO中的Buffer主要實現有：
ByteBuffer。
CharBuffer。
DoubleBuffer。
FloatBuffer。
IntBuffer。
LongBuffer。
ShortBuffer。

寫入數據到Buffer。
調用flip()方法。
從Buffer中讀取數據。
調用clear()方法或者compact()方法。
Selector
Selector運行單線程處理多個Channel。
JAVA NIO 的特色
便可以從通道中讀取數據，也能夠寫數據到通道中。
通道能夠異步讀寫。
通道中的數據老是要先讀到一個Buffer，或者老是要從一個Buffer中寫入。

2. TCP與UDP
TCP協議
全稱Transmission Control Protocol，即傳輸控制協議。
TCP是一種面向鏈接的、可靠的、基於字節流的通訊協議。

面向鏈接：先鏈接，再通訊。
可靠的：相對於UDP鏈接，TCP傳輸更可靠。
TCP經過一序列的機制（面向鏈接機制、發送應答機制）來保障傳輸的可靠性。
UDP協議
User Datagram Protocol，用戶數據報協議。
UDP是一種無鏈接的傳輸協議，UDP爲應用程序提供了一種無需創建鏈接就能夠發送封裝的IP數據報的方法。
TCP與UDP不一樣點
TCP基於字節流的方式收發數據，UDP基於數據報通訊的方式收發數據。
TCP是面向鏈接的（先創建鏈接、再進行通訊），UDP是面向無鏈接的。
TCP提供可靠的服務，UDP不保證可靠性。
應用場景
TCP適合通訊質量要求較高的場景。

例：HTTP傳輸，文件傳輸，SMTP傳輸，目前大部分的傳輸都是基於TCP協議進行傳輸。

UDP相對於TCP傳輸速度更快，實時性更好，消耗資源更少，但穩定性、可靠性比TCP差。
適合對網絡通信質量要求不高，速度要求儘可能快，更實時的場景，例：QQ語音，QQ視頻。
TCP的三次握手
第一次握手：客戶端A向服務端B發送鏈接請求（客戶端服務端）。
第二次握手：服務端B向客戶端A發送確認鏈接，同時向客戶端A發送鏈接請求（服務端客戶端）。
第三次握手：客戶端A收到服務端的確認信息，正確無誤後，再向客戶端發送確認鏈接信息（客戶端服務端）。
3. RPC 通訊
全稱Remote Procedure Call，即遠程過程調用。
它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。
RPC 實現原理
若客戶端想要調用服務器端提供的函數/方法，因爲不在同一個內存空間，所以沒法直接調用。
須要經過網絡來表達調用的語義和傳達調用的數據。

一個基本的RPC架構裏面應該至少包含如下4個組件：
1）客戶端（Client）：服務調用方（服務消費者），經過本地調用的方式調用服務。
2）客戶端存根（Client stub）：存放服務端地址信息，將客戶端的請求參數數據信息打包成網絡信息（序列化、反序列化），再經過網絡傳輸發送給服務端。
3）服務端存根（Server stub）：接收客戶端發送過來的請求消息並進行解包（序列化、反序列化），而後再調用本地服務進行處理。
4）服務端（Server）：服務的真正提供者。

以下圖所示

整個調用過程以下：
1） 創建通訊
主要是經過在客戶端和服務器之間創建TCP鏈接，遠程過程調用的全部交換的數據都在這個鏈接裏傳輸。
鏈接能夠是按需鏈接，調用結束後就斷掉，也能夠是長鏈接，多個遠程過程調用共享同一個鏈接。
2） 服務尋址
客戶端和服務器之間創建TCP鏈接後，就要解決尋址問題。
也就是客戶端如何獲取服務器端的地址呢（如主機名或IP地址、端口）？
可靠的尋址方式是RPC的實現基石（好比能夠採用Redis或者zookeeper來註冊服務等等）。
以下圖所示

從服務提供者的角度看
當提供者服務啓動時，須要自動向註冊中心註冊服務。
當提供者服務中止時，須要向註冊中心註銷服務。
提供者須要定時向註冊中心發送服務請求。
一段時間註冊中心未收到來自提供者的服務請求時，認爲提供者已中止服務。
從註冊中心上摘掉對應的服務。
從調用者角度看
調用者啓動時訂閱註冊中心的消息並從註冊中心獲取提供者的地址。
當有提供者上線或者下線時，註冊中心會告知到調用者。
調用者下線時，取消訂閱。
3) 網絡傳輸
序列化
當客戶端機器上的應用發起一個RPC調用時。
調用方法和其入參等信息須要經過底層的網絡協議進行傳輸（如TCP）。
因爲網絡協議是基於二進制的，那就須要將全部須要傳輸的參數數據都先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網絡中進行傳輸。
而後經過尋址操做和網絡傳輸協議將序列化或編組以後的二進制數據發送給服務器端機器上。
反序列化
當服務器端機器接收到客戶端機器的應用發來的請求以後。
須要對接收到的參數等信息進行反序列化操做（序列化的逆操做）。
即將二進制信息恢復爲內存中的表達方式。
而後再找到對應的方法進行本地調用（通常是經過生成代理Proxy去調用），以後獲得調用的返回值。
4) 服務調用
服務器端機器進行本地調用（經過代理Proxy）以後獲得了返回值進行計算處理。
此時還須要再把計算結果再發送回客戶端機器，一樣也須要通過序列化操做。
而後再通過網絡傳輸將二進制數據發送回客戶端機器。
而客戶端機器接收到這些返回值後，則再次進行反序列化操做，恢復內存中的表達方式。
最後再交給客戶端機器上的具體應用進行相關處理。
以下圖所示

C. 分佈式鎖
分佈式鎖是一種分佈式協調技術來實現多個進程之間的協調運行。
Synchronized、 ReentranLock
只能使用在多線程之間調用共享內存的場景。
不能使用在多進程中（多個JVM）。
在多進程中每一個進程對應的都是不一樣的內存空間。
分佈式鎖的特徵
在分佈式系統環境下使用，同一個方法在同一時間只能被一個進程的其中一個線程執行。
分佈式鎖具有可重入特性，具有鎖實現機制，防止死鎖。
分佈式鎖還必須具有非阻塞特性，即沒有獲取到鎖將直接返回獲取鎖失敗。
1. Redis鎖
基於redis分佈式鎖實現的三個核心要素：（1）加鎖； （2）解鎖； （3）鎖超時。
加鎖
setnx（key, value）
key是鎖的惟一標識，能夠根據業務來命名；value是一個隨機生成的UUID。
setnx（key, 1）。

加鎖原理：
當一個線程執行setnx返回1時，說明key不存在，該線程獲取鎖成功。
當一個線程執行setnx返回0時，說明key已經存在，該線程獲取鎖失敗。
解鎖
del（key）
當獲得鎖的線程執行完任務，須要釋放鎖，以便其它線程能夠進入。
釋放鎖以後，其它線程就能夠繼續執行setnx命令來得到鎖。
鎖超時
若是一個獲得鎖的線程在執行任務的過程當中斷開，還將來得及顯示地釋放鎖。
那麼已經被鎖住的資源將會永遠被鎖住，其它線程也沒法進來。
expire（key, 30）：30是超時時間（單位second），
一個簡單的加鎖、釋放鎖、設置超時時間的僞代碼

if (setnx(key, 1) == 1){
    expire(key, 30);
    try{
        ……
    }finally{
        del(key);
    }
}

setnx和expire的非原子性
極端狀況1舉例：
當線程在setnx 與 expire之間忽然斷開.
這個時候setnx成功獲取到鎖，但expire尚未執行到也就不會有超時時間.
那麼這個時候，那麼已經被鎖住的資源仍是永遠會被鎖住，沒法釋放。
避免這種狀況可使用：set命令， set（key, 1, 30, NX）；

極端狀況2舉例：
當線程1執行完setnx與expire時，假如加鎖expire設置30秒超時時間。
可是此處代碼邏輯過於複雜，超過30秒還未執行到del釋放鎖命令。
這時線程1的鎖超時自動釋放。
此時線程2獲取到同一把鎖。
隨後線程1終於執行完了代碼開始執行del命令釋放鎖。
此時實際上線程1釋放的是線程2的鎖。
避免這種狀況的兩種方案：
執行del以前能夠先經過鎖的value值UUID進行判斷，如果本身加的鎖則執行del進行鎖釋放。
給得到鎖的線程開啓一個守護線程，用來給快要過時的鎖「續航」。
2. zookeeper鎖
zookeeper分佈式鎖應用了zookeeper節點中的臨時排序節點的原理。
zookeeper第三方庫Curator客戶端中封裝了一個可重入的鎖服務。
獲取鎖
首先在zookeeper當中，建立一個持久節點ParentLock。
當線程1想要獲取鎖的時候，須要在這個ParentLock節點下面建立一個臨時排序節點Lock。
以後線程1查找ParentLock下面全部的臨時順序節點。
首先判斷本身建立的節點Lock是不是第一個節點。
若是是則成功獲取鎖。
若是不是，則獲取鎖失敗，向位於它的前一個節點註冊Watcher，進入等待狀態。
這種模式跟多線程鎖中的ReentrantLock中使用的AQS隊列差很少。
釋放鎖
當已經獲取到鎖的線程任務完成，會顯示地調用刪除節點的指令。
若是此結點存在Watcher，則它後面必然有正在等待鎖資源的節點存在。
同時它後面第一個等待鎖資源的節點就會收到通知、獲取到鎖。
3. zookeeper鎖與redis鎖區別
zookeeper鎖有封裝好的框架，容易實現，有等待鎖的隊列，大大提高搶鎖效率。
zookeeper添加和刪除節點性能較低。

Redis鎖中使用set和del指令的性能較高。
Redis鎖實現複雜，須要考慮超時、原子性、誤刪等狀況。
Redis鎖沒有等待鎖的隊列，只能在客戶端自旋來等鎖，效率低下。

D. 分佈式事務

1. 事務
事務是由一組操做構成的可靠的獨立的工做單元，事務具有ACID的特性，即原子性、一致性、隔離性、持久性。
2. 分佈式事務
是指事務的參與者、資源管理器、事務管理器分別位於不一樣的服務器上。

例：
在微服務系統當中，有兩個服務（1）庫存服務，對應數據庫1； （2）訂單服務，對應數據庫2。
正常狀況下，兩個數據庫同時更新成功，兩邊的數據才能保持一致性。
非正常狀況下，數據庫1更新成功，數據庫2更新失敗，兩邊的數據失去了應有的一致性。
這種狀況下，就須要使用分佈式事務進行（commit、rollback）進行管理。
由全局事務管理器來管理和協調多個資源管理器之間的一致性。
3. 名詞解釋
資源管理器
能夠是一個DBMS、或者是一個消息服務器管理系統，資源管理器負責控制和管理實際的資源。
事務管理器
負責協調和管理事務，事務管理器控制着全局事務，管理事務的生命週期，而且協調資源。
本地事務
當事務由資源管理器本地管理時被稱做本地事務，優勢是具有ACID的特性，高效、可靠、實現簡單。
全局事務
當事務由全局事務管理器進行全局管理時被稱做全局事務。
事務管理器負責管理全局的事務狀態和參與的資源，協同資源的一致提交和回滾。
4. 幾種經常使用的實現分佈式事務的技術
XA分佈式事務協議
XA分佈式事務協議（分佈式事務規範），是全局事務管理器與資源管理器的接口。
該規範主要定義了全局事務管理器和局部資源管理器之間的接口（主流的數據庫產品都實現了XA接口）。
XA協議包含2PC（兩階段提交）和3PC（三階段提交）
2PC
第一階段：
全局事務管理節點首先向全部的參與事務的節點發送Prepare請求。
參與事務的節點在接到Prepare請求後，每個參與者節點會各自執行與事務有關的數據更新。
並同時寫入Undo Log和Redo Log日誌中（Undo Log與Redo Log的詳解見數據庫一章）。
若是參與者執行成功，暫時不提交任務，而是向全局事務管理節點返回Done（完成）消息。
當全局事務管理節點接到了全部參與者的返回消息後，整個分佈式事務將會進入第二個階段。

第二階段：
若是全局事務管理節點收到的全部參與者的返回消息都是Done（完成）。
那麼它將會向全部事務參與者發出Commit請求。
參與事務的節點接到Commit請求以後。
事務參與者節點會各自進行本地事務的提交，並釋放資源。
當本地事務完成提交後，將會向全局事務管理節點返回ACK（完成）信息。
當全局事務管理節點接收到全部事務參與者的ACK（完成）反饋以後，整個分佈式事務成功完成。

若在XA的第一階段，若是某個事務參與者反饋失敗信息。
說明該節點的本地事務執行不成功，須要回滾（rollback）。
在第二階段，全局事務管理節點向全部的事務參與者發送Abort請求。
接收到Abort請求以後，各個事務參與者節點須要在本地進行事務的回滾操做。
回滾操做依照Undo Log進行。

XA兩階段的缺點：
性能問題：
XA協議遵循強一致性，在事務執行過程當中，各個節點佔用着數據庫資源。
只有當全部節點準備完畢，全局事務管理節點纔會通知提交，參與者提交後釋放資源
這樣的過程有着很是明顯的性能問題。
可使用MQ消息中間件解決性能問題（異步處理）。

單點故障問題：
全局管理節點是整個XA模型的核心。
若是其宕機，事務參與者將一直處於中間狀態沒法完成事務，可使用3PC進行解決。

數據不一致問題：
在XA協議的第二個階段，若是發生局部網絡問題。
若一部分事務參與者收到了提交信息，另外一部分事務參與者沒收到提交信息。
那麼就致使了節點之間數據的不一致。
3PC
XA三階段提交在兩階段提交的基礎上增長了CanCommit階段，而且引入了超時機制。
一旦事務參與者遲遲沒有接收到全局事務管理節點的commit請求，會自動進行本地commit。
這樣能夠解決單點故障問題，但仍是沒法解決性能與數據不一致問題。

TCC補償事務
TCC事務是Try、Commit、Cancel三種指令的縮寫。
其邏輯模式相似於XA兩階段提交，可是實現方式是在代碼層面人爲實現。

例：A轉帳給B，有一個本地方法，裏面依次調用：
Try階段：
首先在Try階段，要先調用遠程接口把A和B的錢凍結。

Confirm階段：
執行遠程調用的轉帳操做，轉帳成功進行解凍處理。
只要Try階段成功，默認Confirm階段是不會出錯的。

Cancel階段：
若是第二步執行成功，那麼轉帳成功。
若是第二步執行失敗，則將A和B的錢作解凍處理，轉帳失敗。
本地消息表（異步處理）
本地消息表與業務數據表處於同一個數據庫中。
這樣就能利用本地事務來保證在對這兩個表的操做知足事務特性，而且使用了消息隊列來最終一致性。

例：A轉帳100元給B
A對應的本地數據庫中的帳戶減小100（更新成功）。
以後A向本地消息表發送一個消息，本地事務能保證這個消息必定會被寫入本地消息表中。
以後A將本地消息表中的消息轉發到消息隊列中（Kafka等）。
若是轉發成功則將消息從本地消息表中刪除，不然繼續從新轉發。

以後B從消息隊列中讀取消息，並執行消息中的操做，B對應的本地數據庫中的帳戶加100。
轉帳成功。

5、 系統架構介紹

重要的事情說三遍：
架構設計的複雜度必定要根據實際業務場景進行分析。
架構設計的複雜度必定要根據實際業務場景進行分析。
架構設計的複雜度必定要根據實際業務場景進行分析。

對於通常類產品，架構設計到可以知足系統的性能指標要求就足夠了。
對於電商類產品，應設計到能知足下一階段用戶量和性能指標要求的程度，並根據業務的增加不斷的迭代升級架構，以支持更高的併發和更豐富的業務。
A. 軟件架構模型
此架構模型適用小型軟件項目。
軟件架構設計通常將整個業務應用分爲三層架構模型：（1）UI表示層 （2）DLL業務邏輯層 （3）DAL數據訪問層。
1. UI表示層
提供交互式的界面，用於直接和用戶交互，也稱爲交互層，一般是網頁、UI等。
2. DLL業務邏輯層
負責數據的傳遞與處理。

例：用戶錄入的信息要通過業務邏輯層的處理後，才能展示給用戶。
3. DAL數據訪問層
用於操做數據庫，對數據的保存、讀取和更新。

B. 單體架構
單體架構是指由一臺或多臺計算機組成中心節點，將數據集中存儲在這個中心節點中。
而且整個系統的全部業務功能也均在此集中處理。

一個典型的單體應用就是將全部的業務場景的UI表示層、DLL業務邏輯層和DAL數據訪問層放在一個工程中。
最終通過編譯、打包，部署在一臺服務器上。

例：
典型的J2EE工程。
它是將表示層的JSP、業務邏輯層的Service、Controller和數據訪問層的Dao，打包成war包。
部署在Tomcat、Jetty或者其它Servlet容器中運行。

1. 單體架構的缺陷
複雜性高
全部業務都集中處理。
全部計算都集中處理。
全部的相關數據都統一存儲、集中訪問。
模塊的邊界模糊，依賴關係不清晰，代碼質量不能獲得有效保證。
可靠性差，若發生某個應用的BUG，可能會波及整個系統的使用，形成全局性的影響。
維護困難
單體架構通常不存在業務系統間的互相調用。
代碼冗餘性很高，隨着時間推移、需求變動和人員更迭，會造成應用程序的技術債務逐漸上升。
隨着業務的發展和功能膨脹，這種架構很容易發生腐化現象。
擴展性差
單體架構只能做爲一個總體進行擴展，沒法結合業務模塊的特色按需擴展。
單體架構通常使用統一的技術平臺或方案解決全部問題，團隊的每一個成員都必須使用相同的開發語言和架構，想要引入新的框架或技術平臺很是困難。
C. 集羣架構
集羣是一組相互獨立的、經過高速網絡互連的計算機，它們構成了一個組，並以單一系統的模式加以管理。
集羣主要是簡單加機器解決問題，對於問題自己不作任何分解。
集羣架構同樣存在單體架構的缺陷。
集羣優點
提升性能、下降成本、提升可擴展性、加強可靠性。
集羣也能夠簡單理解爲
把單體架構複製幾份，這樣就構成了一個集羣。
集羣中的每臺應用服務器稱爲一個節點，每一個節點都提供相同的服務。
這樣系統的處理能力就至關於提高了好幾倍（具體取決於有多少節點就提高多少倍）。
集羣架構圖

D. 分佈式架構
1. 分佈式架構簡介
分佈式架構簡單能夠理解爲（分工 + 協做）。
分佈式系統是一組獨立的計算機展示給用戶的是一個統一的總體。
系統擁有多種通用的物理和邏輯資源，能夠動態分配任務，分散的物理和邏輯資源經過計算機網絡實現信息交換。
系統中存在一個以全局的方式管理計算機資源的分佈式操做系統。
在操做系統之上有一層軟件中間件負責實現這個模型。

例：萬維網就是典型的分佈式系統的例子。
2. 分佈式系統的特徵
分佈性
分佈式系統由多臺計算機組成，它們在地域上是分散的。
能夠散佈在一個單位、一個城市、一個國家，甚至全球範圍內。
自治性
分佈式系統中的各個節點都包含本身的處理機和內存，各自具備獨立的處理數據的功能。
並行性
一個大的任務能夠劃分爲若干個子任務，分別在不一樣的主機上執行。
全局性
分佈式系統中必須存在一個單一的、全局的進程通訊機制。
使得任何一個進程都能與其它進程通訊，而且不區分本地通訊與遠程通訊。
3. 分佈式系統的優勢
資源共享。
加快計算速度。
可靠性高。
通訊方便、快捷。
4. 常見分佈式架構
1）應用層實現分佈式（單元化架構），每一個單元都有本身的數據，能夠綁定應用資源。
2）業務進行分庫分表，事務一致性設計，經過數據庫中間件負責鏈接管理和路由。
3）分佈式事務數據庫（理論上對應用透明，複雜SQL支持完備度）。

5. 分佈式架構圖（此處以某金融平臺核心系統爲例）

E. 微服務架構

1. SOA
全稱Service Oriented Architecture，即面向服務的架構。
SOA是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）進行拆分。
並經過這些服務之間定義良好的接口和協議聯繫起來。

在SOA模型中，全部的功能都定義成了獨立的服務。
服務之間經過交互和協調完成業務的總體邏輯。
全部的服務經過服務總線或流程管理器來鏈接，最終提供一系列完整的功能。
各個服務一般以獨立的形式部署運行，服務之間經過網絡進行調用。
2. ESB
全稱 Enterprise Service Bus，即企業服務總線。
提供了網絡中最基本的鏈接中樞，是構築企業神經系統的必要元素。
簡單來講ESB就是一根管道，用來鏈接各個服務節點。
ESB的存在是爲了集成基於不一樣協議的不一樣服務。
ESB作了消息的轉化、解釋以及路由的工做，以此來讓不一樣的服務互聯互通。
ESB的核心內容
服務元數據管理：包括服務註冊、生命週期等。
協議適配：支持各類集成和通訊協議，支持各類消息傳輸和業務集成方式。
中介服務：支持各類集成場景，支持各類消息處理與轉換模式。
治理與監控：服務調用與消息處理的日誌及統計分析，服務質量、服務降級、流控等等。
安全性：傳輸通訊安全性，數據安全性，服務調用安全性，身份驗證等等。

其它還有事務管理、高性能、高可用、高可靠性、高穩定性等等。
3. 微服務
微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線，同時以SOA的思想進入到單個業務系統內部實現真正的組件化。
微服務架構和SOA架構很是相似，微服務架構更強調的是「業務須要完全的組件化及服務化」。
原單個業務系統會被拆分爲多個能夠獨立開發、設計、部署運行的小應用。
這些小應用間經過服務化完成交互和集成。
微服務的特徵
經過服務實現組件化。
按業務能力來劃分服務和開發團隊。
去中心化。
基礎設施自動化。
微服務架構須要關注的幾個點
微服務顆粒度拆分策略、服務邊界定義，同時要從功能和性能方面綜合考慮。
職責單一化、運行隔離化，理論上支持單一微服務獨立發佈、獨立部署、獨立運行。
支持並行開發，下降構建及部署耗時，提升開發效率，同時下降系統影響範圍，經過集成DevOps體系，提升生產版本發佈頻率。
分佈式事務支持，微服務應用設計要徹底知足分佈式架構平臺事務規範要求。
4. 雲計算的三個層次
假設有一家不須要其它任何公司提供服務的大牛公司。
那這家公司就必需擁有：（1）基礎設施； （2）平臺； （3）軟件。

基礎設施：包括服務器、網絡設備、存儲設備等。
平臺則包括：操做系統、中間件、運行庫等。
軟件包括：應用程序、數據等。

瞭解了這些，其實IaaS / PaaS / SaaS就是雲計算的三種服務：
IaaS
Infrastructure-as-a-Service：基礎設施即服務。
IaaS公司會提供場外服務器、存儲和網絡硬件（也能夠選擇租用），節省維護成本和辦公場地。
公司能夠在任什麼時候候利用這些硬件來運行其應用。

特色：
費用因消費而異。
服務高度可擴展。
一般在單個硬件上包括多個用戶。
爲組織提供對基礎架構的徹底控制。
動態靈活。
PaaS
Platform-as-a-Service：平臺即服務。
PaaS公司能夠提供各類開發和分發應用的解決方案，好比虛擬服務器和操做系統等。

特色：
資源可輕鬆擴展或縮小。
提供各類服務以協助開發，測試和部署應用程序。
許多用戶能夠訪問相同的開發應用程序。
SaaS
Software-as-a-Service：軟件即服務。
也是目前普通用戶接觸最多的層面，在網絡上任意一個遠程服務器上的應用都屬於SaaS。

特色：
統一的管理。
可經過互聯網訪問。
用戶不負責硬件或軟件更新。
託管在遠程服務器上。
5. 微服務架構圖（此處以某金融平臺核心系統爲例）