應(yīng)用架構(gòu)演進(jìn)

這里的架構(gòu)演進(jìn)應(yīng)該是從服務(wù)化的角度來說，應(yīng)該說隨著業(yè)務(wù)發(fā)展，應(yīng)用規(guī)模擴大，系統(tǒng)的一些公共服務(wù)就會抽取出來，獨立開發(fā)，部署，維護(hù)，用來解決并發(fā)，擴展，維護(hù)的問題。

傳統(tǒng)垂直架構(gòu)

有的地方也叫單體應(yīng)用，以mvc模式開發(fā)：

1. 所有應(yīng)用代碼統(tǒng)一打包，代碼所有接口本地api調(diào)用，很少存在遠(yuǎn)程服務(wù)調(diào)用;
2. 單機或主備，應(yīng)用做集群部署；
3. DB主從等。

這種并沒有什么不好，發(fā)展初期大多是這樣，體量沒那么大，也不需要考慮高并發(fā)大流量可擴展性什么的，簡單粗暴，解決業(yè)務(wù)需求就好，活下去才能活的更好。

但是必須明白這種簡單架構(gòu)存在的一些問題：

1. 業(yè)務(wù)不斷發(fā)展，功能逐漸增多，應(yīng)用的開發(fā)維護(hù)成本變高，部署效率降低，隨便改個代碼，編譯一次十幾分鐘就浪費了。悲劇，我們有個系統(tǒng)才開發(fā)3年，就碰到這種情況，一次打包編譯部署，13分鐘結(jié)束。

2. 不同的人負(fù)責(zé)不同的部分，一些通用代碼、公共代碼就各寫各的，不能復(fù)用，如果只是util還好，但是一些外部服務(wù)的都有重復(fù)，那就happy了（不過這種情況的出現(xiàn)，不一定是架構(gòu)問題，更多可能是管理）；

3. 不斷地上新需求，不斷地改代碼，有時測試不到位，指定哪里埋了bug，上生產(chǎn)后系統(tǒng)就down了，牽一發(fā)而動全身；

4. 可維護(hù)性，可靠性，擴展性變差。

既然有這些問題，就要解決啊，業(yè)務(wù)就會提要求，你要解決啊，要不然影響我業(yè)務(wù)發(fā)展，影響我ipo上市啊，苦逼的碼農(nóng)開始干活了。

不提應(yīng)用的拆分主從那些手段，但從拆分后應(yīng)用交互看，原來的本地api交互變成的遠(yuǎn)程api的調(diào)用，這里就出現(xiàn)了rpc，當(dāng)然也有走esb，webservice。其實拆分后挺麻煩的，光一個分布式事務(wù)就能折騰死人。

RPC架構(gòu)

Remote Procedure Call，遠(yuǎn)程方法調(diào)用，屏蔽底層實現(xiàn)細(xì)節(jié)，像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程服務(wù)。

上個作者的圖：

這個圖對于大多數(shù)rpc框架通用，實現(xiàn)的幾個技術(shù)點：

1. 服務(wù)提供者發(fā)布服務(wù)：服務(wù)接口定義，數(shù)據(jù)結(jié)構(gòu)，服務(wù)提供者信息等；

2. 客戶端遠(yuǎn)程調(diào)用：通常是使用jdk的代碼代理攔截；

3. 底層通信：現(xiàn)在應(yīng)該更多是使用netty吧，當(dāng)然也有走支持http的；

4. 序列化：關(guān)注序列化反序列性能，xml，json，hessiaon，pb，protostuff，kryo等；

作者給了個socket實現(xiàn)簡單demo，來實現(xiàn)遠(yuǎn)程調(diào)用，說明上面幾個技術(shù)點。

常用的rpc框架

1. Thrift；

2. Hadoop的Avro-RPC;

3. Hessian；

4. gRPC;

單論rpc的話，沒太多可說的，可是如果加上服務(wù)治理，那復(fù)雜度就幾何倍數(shù)增長了。服務(wù)治理里面東西太多了，動態(tài)注冊，動態(tài)發(fā)現(xiàn)，服務(wù)管控，調(diào)用鏈分析等等問題這些問題，單憑rpc框架解決不了，所以現(xiàn)在常用的說的服務(wù)化框架，通常指的是rpc+服務(wù)治理2個點。

SOA服務(wù)化架構(gòu)

感覺soa架構(gòu)應(yīng)該是在rpc之前出現(xiàn)，用來解決異構(gòu)系統(tǒng)的交互，通常的實現(xiàn)是通過ESB，WSDL來處理。其粒度通常來說是比較粗的。也存在服務(wù)治理方面的問題。

微服務(wù)

MSA也是一種服務(wù)化架構(gòu)風(fēng)格，正流行ing，服務(wù)劃分

1. 原子服務(wù)，粒度細(xì)；

2. 獨立部署，主要是容器；

分享篇文章：云棲肥俠的文章 微服務(wù)（Microservice）那點事 。

MSA與SOA的對比：

1. 服務(wù)拆分粒度：soa首要解決的是異構(gòu)系統(tǒng)的服務(wù)化，微服務(wù)專注服務(wù)的拆分，原子服務(wù)；
2. 服務(wù)依賴：soa主要處理已有系統(tǒng)，重用已有的資產(chǎn)，存在大量服務(wù)間依賴，微服務(wù)強調(diào)服務(wù)自治，原子性，避免依賴耦合的產(chǎn)生；
3. 服務(wù)規(guī)模：soa服務(wù)粒度大，大多數(shù)將多個服務(wù)合并打包，因此服務(wù)實例數(shù)有限，微服務(wù)強調(diào)自治，服務(wù)獨立部署，導(dǎo)致規(guī)模膨脹，對服務(wù)治理有挑戰(zhàn)；
4. 架構(gòu)差異：微服務(wù)通常是去中心化的，soa通常是基于ESB的；
5. 服務(wù)治理：微服務(wù)的動態(tài)治理，實時管控，而soa通常是靜態(tài)配置治理；
6. 交付：微服務(wù)的小團(tuán)隊作戰(zhàn)。

感覺在有了docker后，微服務(wù)這個概念突然火了起來，總結(jié)就是微服務(wù)+容器+DevOps。

分布式服務(wù)框架入門

背景

應(yīng)用從集中式走向分布式

隨著業(yè)務(wù)的發(fā)展導(dǎo)致功能的增多，傳統(tǒng)的架構(gòu)模式開發(fā)，測試，部署整個流程變長，效率變低，后臺服務(wù)的壓力變大，只能通過硬件擴容來暫時緩解壓力，但解決不了根本性問題：

1. 應(yīng)用規(guī)模變大，開發(fā)維護(hù)成本變高，部署效率降低；
2. 代碼復(fù)用：原來是本地api調(diào)用，導(dǎo)致一些公用功能可能是按需開發(fā)，不統(tǒng)一，隨意等問題；
3. 交付面臨困難：主要是業(yè)務(wù)變得復(fù)雜，新增修改測試變得困難，拉長整個流程。

通用法寶：拆分，大系統(tǒng)拆小系統(tǒng)，獨立擴展和伸縮。

1. 縱向：分業(yè)務(wù)模塊；
2. 橫向：提煉核心功能，公共業(yè)務(wù)；

需要服務(wù)治理

大拆小，核心服務(wù)提煉后，服務(wù)的數(shù)量變多，而且需要一些運行態(tài)的管控，這時候就需要服務(wù)治理：

1. 服務(wù)生命周期管理；
2. 服務(wù)容量規(guī)劃；
3. 運行期治理；
4. 服務(wù)安全。

服務(wù)框架介紹

Dubbo

阿里開源的Dubbo應(yīng)該是業(yè)界分布式服務(wù)框架最出名的了吧，看過公司的rpc框架，Dubbo的擴展性比我們的好的多了，我們的框架每次升級，改動都很多，改天要看下Dubbo的源碼了解了解擴展性。

HSF

淘寶的體量決定了他對極致性能的追求，HSF跨機房特性挺牛。

Coral Service

這個沒聽說過，孤陋寡聞了。

框架設(shè)計

架構(gòu)原理

萬變不離其中，這張圖可以概括rpc的一些通用原理：

細(xì)化了下：

1. rpc層：底層的通訊框架，通訊協(xié)議，序列化和反序列化；
2. 服務(wù)發(fā)布訂閱；
3. 服務(wù)治理；

功能

性能

可靠性

分布式的，面試會問，用池子的話講就是，知識點啊。

服務(wù)治理

通訊框架

技術(shù)點

1. 長連接：主要是鏈路的創(chuàng)建過程到最后的關(guān)閉，耗時耗資源；每次調(diào)用都要創(chuàng)建的話，調(diào)用時延的問題，很可能鏈路創(chuàng)建的耗時比代碼真正執(zhí)行時長還多；
2. BIO還是NIO：主要是線程模型的選擇，推薦篇文章 IO - 同步，異步，阻塞，非阻塞 （亡羊補牢篇）；
3. 自研還是使用開源NIO框架：一般來說還是使用開源吧，技術(shù)成熟，社區(qū)支持，現(xiàn)在netty和mina使用較多了吧。

在功能設(shè)計方面，作者基于netty給了demo服務(wù)端和客戶端的代碼，個人理解：

1. 通用性api；

2. 擴展性，封裝底層，提供上層接口，隔離協(xié)議和底層通訊；

可靠性設(shè)計

談分布式系統(tǒng)必談可靠性。

鏈路有效性

通過心跳來確認(rèn)雙方c、s存活，保證鏈路可用，心跳檢測機制分為3個層面：

1. tcp層面，即tcp的keep-alive，作用于整個tcp協(xié)議棧；

2. 協(xié)議層的心跳檢測，主要存在于長連接協(xié)議中，例如smpp協(xié)議；

3. 應(yīng)用層的心跳，業(yè)務(wù)雙方的定時發(fā)送心跳消息；

第2個沒聽說過，常用的是1,3。一般使用netty的話用的是netty的讀寫空閑來實現(xiàn)心跳。

斷連

不管因為網(wǎng)絡(luò)掛了還是服務(wù)端宕機，還是心跳超時什么的，導(dǎo)致鏈路不可用關(guān)閉，這時候就需要鏈路重連，需要注意的一點就是短連后，不要立即重連，留時間給系統(tǒng)釋放資源，可以scheduler處理。

消息緩存重發(fā)

底層消息不會立即發(fā)送（也會導(dǎo)致半包粘包），斷鏈后，導(dǎo)致消息丟失，看有無業(yè)務(wù)需求，有就支持?jǐn)噫満笙⒅匕l(fā)。

資源釋放

主要是斷鏈后，一定要保證資源銷毀和釋放，當(dāng)然也包括一些線程池，內(nèi)存等的釋放。

性能設(shè)計

性能差的三宗罪

對于底層通訊框架來說，主要是下面幾個：

1. 通訊模型的選擇，主要是阻塞非阻塞那些東西；

2. 序列化反序列化（后面有章單講序列化）；

3. 線程模型，主要是服務(wù)端選擇什么樣的線程模型來處理消息。

通信性能三原則

既然有上面的3個問題，那就針對這些做優(yōu)化了：

1. 傳輸：BIO\NIO\AIO的選擇；
2. 選擇自定義協(xié)議棧，便于優(yōu)化；
3. 服務(wù)端線程模型，單線程處理還是線程池，線程池是一個，還是分優(yōu)先級，Reactor還是其他什么的。

高性能之道這節(jié)作者講了netty的優(yōu)勢。

序列化與反序列化

也就是通常所說的編碼、解碼。通常的通訊框架會提供編解碼的接口，也會內(nèi)置一些常用的序列化反序列化工具支持。

與通訊框架和協(xié)議的關(guān)系，感覺可以理解為：通訊框架是通道，其上跑的碼流數(shù)據(jù)是利用各種序列化編碼后的各種協(xié)議。

功能設(shè)計

各種序列化框架需要考慮的主要有：

• 序列化框架本身的功能的豐富，支持的數(shù)據(jù)類型；
• 多語言的支持；
• 兼容性，往大了說：

1. 服務(wù)接口的前后兼容；
2. 協(xié)議的兼容；
3. 支持的數(shù)據(jù)類型的兼容。

• 性能，目的是最少的資源，最快的速度，最大的壓縮：

1. 序列化后碼流大??；
2. 序列化的速度；
3. 序列化的資源占用。

在擴展性這節(jié)，作者講了netty的對序列化的一些內(nèi)置支持，但實際開發(fā)中，一般不太會使用這些東西，都會提供序列化反序列接口，自行擴展定義，所以擴展性特重要。

常用的序列化，xml，json，hessian，kryo，pb，ps，看需求需要支持那種，具體可以搜索各序列化的性能和壓縮后大小。

協(xié)議棧

這一章最主要的是講了自定義協(xié)議棧的設(shè)計，已經(jīng)交互的過程，其他講的可靠性設(shè)計什么的跟之前通訊框架一章有重復(fù)。

通信模型

服務(wù)提供者和消費者之間采用單鏈路，長連接通信，鏈路創(chuàng)建流程：

1. 客戶端發(fā)送握手請求，攜帶節(jié)點ID等認(rèn)證信息；

2. 服務(wù)端校驗：節(jié)點ID有效性，重復(fù)登錄，ip地址黑白名單等，通過后，返回握手應(yīng)答信息；

3. 鏈路建立后，客戶端發(fā)送業(yè)務(wù)消息；

4. 客戶端服務(wù)端心跳維持鏈路；

5. 服務(wù)端退出時，關(guān)閉連接，客戶端感知連接關(guān)閉，關(guān)閉客戶端連接。

協(xié)議消息定義

通過attachment兼容了擴展性。作者還講了將消息頭的通用序列化和消息體的自定義序列化，看需求吧，我們公司的框架沒做這部分支持，做了簡化，將消息頭和消息體統(tǒng)一封裝，然后再加一個序列化方式組成一條消息發(fā)送。

安全性設(shè)計

1. 內(nèi)部的，不一定需要認(rèn)證，也有基于系統(tǒng)，域名，ip的黑白名單，安全認(rèn)證的；
2. 外部開發(fā)平臺的話，基于秘鑰認(rèn)證；

服務(wù)路由

服務(wù)路由指的是服務(wù)提供者集群部署，消費端如何從服務(wù)列表中選擇合適的服務(wù)提供者提供服務(wù)進(jìn)行調(diào)用。

透明化路由

1. 基于zk的服務(wù)注冊中心的發(fā)布訂閱；
2. 消費者本地緩存服務(wù)提供者列表，注冊中心宕機后，不影響已有的使用，只是影響新服務(wù)的注冊和老服務(wù)的下線。

負(fù)載均衡

• 隨機
• 輪循
• 服務(wù)調(diào)用時延
• 一致性Hash

1. 有個一致性hash算法，挺有意思的，redis的客戶端shard用的

• 黏滯連接

1. 這個應(yīng)該不太常用，服務(wù)提供者多數(shù)無狀態(tài)，一旦有狀態(tài)，不利于擴展

這些都是點對點的連接，負(fù)載均衡大多會在客戶端執(zhí)行，有種場景會取決于服務(wù)端負(fù)載，就是服務(wù)端服務(wù)配置的是域名。

本地路由優(yōu)先策略

• injvm：jvm也提供了消費端的服務(wù)，可以改成優(yōu)先本jvm，對于消費端來說，不需關(guān)注提供者；
• innative：injvm比較少，多得是可能是這種，一個物理機部署多個虛擬機，或者一個容器部署多個服務(wù)提供者，消費者不需遠(yuǎn)程調(diào)用，本機，本地或本機房優(yōu)先。

路由規(guī)則

除了上面提供的各種路由負(fù)載均衡，還容許自定義路由規(guī)則:

- 條件路由：主要是通過條件表達(dá)式來實現(xiàn)；

- 腳本路由：通過腳本解析實現(xiàn)。

其實應(yīng)該還有一種客戶端通過代碼自定義路由選擇。這些主要是為了擴展性。

路由策略定制

自定義路由場景：

1. 灰度；

2. 引流；

路由策略：

1. 框架提供接口擴展；

2. 配置平臺提供路由腳本配置；

配置化路由

1. 本地配置：包括服務(wù)提供者和消費者，全局配置3種；
2. 注冊中心：路由策略統(tǒng)一注冊到服務(wù)注冊中心，集中化管理；
3. 動態(tài)下發(fā)：配置后動態(tài)下發(fā)各服務(wù)消費端。

集群容錯

指的是服務(wù)調(diào)用失敗后，根據(jù)容錯策略進(jìn)行自動容錯處理。

集群容錯場景

• 通信鏈路故障：

1. 通信過程中，對方宕機導(dǎo)致鏈路中斷；
2. 解碼失敗等原因Rest掉鏈接；
3. 消費者read-write socketchannel發(fā)生IOException導(dǎo)致鏈路中斷；
4. 網(wǎng)絡(luò)閃斷故障；
5. 交換機異常導(dǎo)致鏈路中斷；
6. 長時間Full GC導(dǎo)致；

• 服務(wù)端超時：

1. 服務(wù)端沒有及時從網(wǎng)絡(luò)讀取客戶端請求消息，導(dǎo)致消息阻塞；
2. 服務(wù)端業(yè)務(wù)處理超時；
3. 服務(wù)端長時間Full GC；

• 服務(wù)端調(diào)用失?。?/li>

1. 服務(wù)端解碼失??；
2. 服務(wù)端流控；
3. 服務(wù)端隊列積壓；
4. 訪問權(quán)限校驗失?。?/li>
5. 違反SLA策略；
6. 其他系統(tǒng)異常；

業(yè)務(wù)執(zhí)行異常不屬于服務(wù)端異常。

容錯策略

這圖不錯，關(guān)系很清晰。

• 失敗自動切換（Failover）：

1. 調(diào)用失敗后切換鏈路調(diào)用；
2. 服務(wù)提供者的防重；
3. 重試次數(shù)和超時時間的設(shè)置。

• 失敗通知（FailBack）：失敗后直接返回，由消費端自行處理；
• 失敗緩存（Failcache）：主要是失敗后，緩存重試重發(fā)，注意：

1. 緩存時間、緩存數(shù)量；
2. 緩存淘汰算法；
3. 定時重試的周期T、重試次數(shù)；

• 快速失?。‵ailfast）：失敗不處理，記錄日志分析，可用于大促期間，對非核心業(yè)務(wù)的容錯。

容錯策略擴展

1. 容錯接口的開放；
2. 屏蔽底層細(xì)節(jié)，用戶自定義；
3. 支持?jǐn)U展。

其實還有一點，感覺也挺重要，就是支持容錯后本地mcok。調(diào)用失敗后的鏈路切換和快速失敗肯定要支持，緩存重發(fā)可以不用。