架構設計是一系列相關的抽象模式，是人們對一個結構內的元素及元素間關系的一種主觀映射的產物。
一、計算機網絡基礎
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模型的會話層、表示層、應用層。
應用層負責處理應用程序的邏輯。
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地址划分成網絡地址和主機地址兩部分。
A. 分布式系統
系統中的多個模塊在不同服務器上的部署。
一組獨立的計算機展現給用戶的是一個統一的整體。
例：Tomcat與數據庫分布部署在不同的服務器上。
B. 系統集群
一個特定領域的軟件部署在多台服務器上並作為一個整體提供一類服務。
在集群中，多台服務器內容、工作過程等完全一樣，客戶端可以連接任意一個節點獲得服務。
並且當集群中一個節點掉線時，其它節點可以自動的接替它繼續提供服務。
C. 系統高可用性
通常來描述一個系統經過特殊的設計，從而減少停工時間，而保持其服務的高度可用性。
系統中部分服務器掉線時，其它服務器能夠接替它繼續提供服務，則可認為系統具有高可用性。
D. 負載均衡
將負載（工作任務）進行平衡、分攤到多個操作單元上進行運行。
當客戶端請求發送到系統時，通過某種算法把請求分發到多個可用的服務器上。
使系統中每個服務器都能夠均勻的處理請求。
E. 代理
當客戶端無法直接跟服務端發起請求的時候，就需要代理服務。代理分為：（1）正向代理 （2）反向代理
1. 正向代理
正向代理 是一台 位於客戶端和目標服務器之間的 代理服務器。
當客戶端需要獲取目標服務器中的數據時、先向代理服務器發送請求並指定目標服務器。
由代理服務器向目標服務器發送請求獲取數據、並將獲取到的數據返回給客戶端。
正向代理的作用
訪問客戶端不能訪問的資源。
對客戶端訪問進行授權、認證。
可以做緩存，加速訪問資源。
記錄用戶訪問記錄，對外隱藏用戶信息。
2. 反向代理
反向代理 也是一台位於客戶端和服務器之間的代理服務器。
但是客戶端並不知道目標服務器，當客戶端需要獲取目標服務器中的數據時、先向代理服務器發送請求。
由代理服務器將請求轉發給內部網絡上的服務器，並將從目標服務器上獲取到的數據返回給客戶端。
反向代理的作用
保證內網的安全，阻止web攻擊。
負載均衡，通過反向代理服務器優化網站的負載。
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是一種高吞吐量的分布式發布訂閱消息系統。
它可以處理消費者規模的網站中的所有動作流數據。
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鎖沒有等待鎖的隊列，只能在客戶端自旋來等鎖，效率低下。
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。
轉賬成功。
重要的事情說三遍：
架構設計的復雜度一定要根據實際業務場景進行分析。
架構設計的復雜度一定要根據實際業務場景進行分析。
架構設計的復雜度一定要根據實際業務場景進行分析。
對於一般類產品，架構設計到能夠滿足系統的性能指標要求就足夠了。
對於電商類產品，應設計到能滿足下一階段用戶量和性能指標要求的程度，並根據業務的增長不斷的迭代升級架構，以支持更高的並發和更豐富的業務。
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. 分布式架構圖（此處以某金融平台核心系統為例）
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. 微服務架構圖（此處以某金融平台核心系統為例）
