單元化架構(gòu)在金融行業(yè)的最佳實踐

認識單元化

1. 單元化是怎么來的呢？

系統(tǒng)架構(gòu)在前中期的快速發(fā)展階段，往往更多的是考慮如何快速上線，中臺如何支撐更多的系統(tǒng)。但單個機房整體的資源利用率總會存在上限，即使各種技術(shù)優(yōu)化手段再有效，也很難有明顯提升，那么單一機房本身就成為了系統(tǒng)瓶頸，瓶頸表現(xiàn)在數(shù)據(jù)庫連接不足、可用區(qū)內(nèi)無法擴容、無法提供異地容災等情況。

軟件系統(tǒng)架構(gòu)的發(fā)展歷程中，每一次架構(gòu)的演進都在解決原有問題，同時帶來新的問題。解決系統(tǒng)架構(gòu)設(shè)計問題的有效手段之一是“解耦”，可以簡單歸結(jié)為將“大問題”分解為”小問題”，再將”小問題”分解為更小的問題，直到這個”小問題”可以被我們解決。

單元化架構(gòu)正是眾多優(yōu)秀架構(gòu)師將“大問題”分解為“小問題”后實踐和思考的結(jié)晶。其本質(zhì)是數(shù)據(jù)和邏輯的立體拆分，將數(shù)據(jù)和邏輯劃分為相似的“切片”，提高系統(tǒng)對外服務(wù)能力的性價比，增加“切片”內(nèi)鏈路流轉(zhuǎn)的效率。

可以理解為，單元化垂直切開的是全集的數(shù)據(jù)和邏輯關(guān)系，是AKF立方體中Z軸拆分的一種高級形式。

另外，單元化架構(gòu)不是憑空出現(xiàn)的，它是分布式架構(gòu)發(fā)展日積月累的產(chǎn)物。也不是所有的業(yè)務(wù)系統(tǒng)都適合單元化架構(gòu)，需要系統(tǒng)架構(gòu)具備一定的技術(shù)前提和改造動力，比如微服務(wù)化程度、DevOps能力、高可用規(guī)劃等多方面要求。

2. 單元化，能干啥？

一般情況下，單元化應用場景多是較大規(guī)模的分布式系統(tǒng)，尤其是遇到單機房物理限制的情況，快速發(fā)展的行業(yè)尤其明顯，如下簡單介紹一些問題場景。

首先，是業(yè)務(wù)快速發(fā)展、流量爆發(fā)性增長，給單機房系統(tǒng)帶來難以持續(xù)擴容的問題。

應用層水平擴容難以有效緩解對于數(shù)據(jù)層的壓力，同時還會造成數(shù)據(jù)庫連接吃緊。

分庫分表能暫時緩解數(shù)據(jù)庫壓力，但需要封裝統(tǒng)一的數(shù)據(jù)訪問代理，同時有一定的代碼侵入。如果采用開源數(shù)據(jù)訪問代理，又會有技術(shù)組件遷移和維護的問題。另外，開發(fā)人員拆的太開反而會增加數(shù)據(jù)庫壓力，尤其在秒殺或者雙11的高并發(fā)場景甚至會引發(fā)宕機。

單元化架構(gòu)通過統(tǒng)一的切分規(guī)則，將應用層和數(shù)據(jù)層進行立體拆分，無論是彈性擴縮容場景，還是多地多中心場景，都可以根據(jù)數(shù)據(jù)中心容量自由劃分邏輯“切片”的多少。就好像香蕉樹（整個系統(tǒng)）上面的每個香蕉（邏輯切片），可以根據(jù)袋子（單元）的大小自由分配和調(diào)整，當一個袋子裝滿了，可以隨時將多出的香蕉裝到其它袋子中。

其次，跨地域數(shù)據(jù)中心間服務(wù)調(diào)用和數(shù)據(jù)同步時高耗時、低穩(wěn)定性問題，也是單元化重要的應用場景之一。

比如對于數(shù)據(jù)一致性比較高的業(yè)務(wù)，寫操作的接入點往往會在某一數(shù)據(jù)中心A，則當數(shù)據(jù)中心B有寫操作時，數(shù)據(jù)會通過A數(shù)據(jù)中心主庫寫入，再從A將數(shù)據(jù)復制回B。這種跨地域的調(diào)用延時可能在秒級，是很難接受的。

另外，在異地多機房情況下，服務(wù)間調(diào)用鏈路可能會在本機房和跨機房中隨機選擇，這樣也提高了調(diào)用鏈路的不穩(wěn)定性。

單元化架構(gòu)通過“單元”，將邏輯調(diào)用和數(shù)據(jù)訪問在“單元”內(nèi)形成閉環(huán)，只有少數(shù)特定場景的調(diào)用會跨單元訪問，這樣幾乎大部分的請求在地域內(nèi)就可以返回，極大程度地減少了訪問耗時，避免了跨異地訪問鏈路擁堵造成的服務(wù)夯死，提高了鏈路穩(wěn)定性。重要的是單元帶來的顯著的故障隔離效果，鏈路的可觀測性方面也得到了明顯改善，即從鏈路訪問層面屏蔽了跨地域訪問所帶來的上述問題。

最后，基于單元化靈活的流量調(diào)配策略，其還可應用于單元級的全鏈路灰度發(fā)布、訪問冷熱不均場景，此處通過單元級的全鏈路灰度發(fā)布做簡單的解釋。

常見的方式有兩種，分為總控型和自控型。

?

1. 總控型：一般在流量入口處統(tǒng)一切換流量，單元內(nèi)應用會在同一時間點準備好新版本并統(tǒng)一發(fā)布，適用于如金融、保險等鏈路上下游強關(guān)聯(lián)、發(fā)布版本相對穩(wěn)定和固定的業(yè)務(wù)場景。

優(yōu)點在于管控力度強，故障回滾時產(chǎn)生的損失?。?/span>

缺點在于一旦鏈路中僅個別應用在實際生產(chǎn)發(fā)布時故障需回滾（如有BUG），會連帶鏈路中未故障應用也需回滾，打亂未故障應用的版本發(fā)布節(jié)奏。

2. 自控型：一般由各應用自身負責應用的灰度發(fā)布過程，通常適用于服務(wù)間松耦合、迭代頻繁的業(yè)務(wù)場景。

優(yōu)點在于灰度的控制粒度更小、更靈活，不會出現(xiàn)總控型統(tǒng)一回滾的問題；

缺點在于可能需要應用自己保證對外版本的兼容性等。

單元化，沒毛病？

1. 成本高

單元化建設(shè)意味著現(xiàn)在或未來需要買更多的機器、建更多的機房、搭更多的框架平臺做支撐，以及架構(gòu)升級過程中帶來的各種各樣的問題，這就需要更多的錢、人、時間。

有“爸爸”的不差錢，不差錢的企業(yè)也大概不發(fā)愁人才，但時間對每個企業(yè)都是公平的，誰都沒法獲得更多的時間。

2. 改造風險大

單元化改造的參與者眾多、落地時間周期長、業(yè)務(wù)影響面大，比如架構(gòu)師需要重新做架構(gòu)設(shè)計、研發(fā)人員需要針對單元化做適配開發(fā)、運維人員需要采購和部署、測試人員需要全量回歸所有業(yè)務(wù)等等，其中某一環(huán)出現(xiàn)問題就可能造成延期或者埋下隱患。

所以，單元化改造是一件風險很高的操作，也并不是所有的業(yè)務(wù)場景都建議單元化改造，需要反復的評估和詳細權(quán)衡改造的ROI。

3. 運維復雜

單元化建設(shè)之前，如果不是特別痛的痛點，運維同學還可以“忍受”。單元化改造后，除了對數(shù)據(jù)流、控制流的所有層次都增加了路由邏輯，在基礎(chǔ)設(shè)施（消息隊列、緩存、數(shù)據(jù)庫等）方面也增加了很多新的問題，比如跨地域數(shù)據(jù)同步一致性、應對異地網(wǎng)絡(luò)尖刺和高延遲等。

這就需要在基礎(chǔ)設(shè)施的運維可觀測性、穩(wěn)定性、容災恢復等方面具備較高的水準。另外，保證多地域數(shù)據(jù)一致性及災備恢復也極具挑戰(zhàn)。

4. 難以理解

單元化改造后，研發(fā)人員理解整體架構(gòu)和業(yè)務(wù)的難度明顯增大了，尤其是系統(tǒng)處于單元化改造過程中時，由于各業(yè)務(wù)線團隊的不同分工和業(yè)務(wù)上線壓力，改造的過程很難保證順暢的溝通和信息完全同步，很容易在系統(tǒng)邊界灰色地帶因為理解不一致導致的返工、延期。

再比如，部分遺留系統(tǒng)內(nèi)部代碼混亂、邏輯復雜、沒人講的明白，一般不會主動修改，還有一些訪問量很少、極度松耦合的非核心系統(tǒng)，沒有單元化的必要，所以整體設(shè)計上它們可能不涉及單元化改造，但是對于新加入團隊的同學是不了解這里有坑的，那么就可能會存在隱患。

單元化架構(gòu)設(shè)計

1. 如何決策？

架構(gòu)設(shè)計的決策者們對于單元化建設(shè)普遍面臨進退兩難，有的迫于現(xiàn)有的業(yè)務(wù)壓力預期，冒著“邊開飛機邊換發(fā)動機”的風險；有的一直在觀望，但由于企業(yè)間實際情況不同，自身單元化建設(shè)遲遲不能落地，錯過最好的改造時機。

可見，決策過程艱難并且會被諸多問題拉扯，比如現(xiàn)有痛點是不是只有單元化才能解決？不通過技術(shù)而通過業(yè)務(wù)變通的手段能否改善？服務(wù)和數(shù)據(jù)的耦合程度是否太高以致難以進行單元化改造?需要準備多長時間作為過渡階段？整體成本有多大，最終會有哪些有效收益，如何評估收益？

個人理解，單元化改造是個復雜工程，想做到有限時間內(nèi)精準的評估決策并不容易，而且一旦開始投入就會產(chǎn)生沉沒成本。但企業(yè)的技術(shù)與業(yè)務(wù)往往是相輔相成，很難說是業(yè)務(wù)倒逼技術(shù)更新迭代，還是技術(shù)創(chuàng)新業(yè)務(wù)發(fā)展。

所以，可以嘗試跳出僅從技術(shù)來分析評估的方式，升維到以企業(yè)的視角思考，以當前和未來的技術(shù)架構(gòu)與業(yè)務(wù)架構(gòu)持續(xù)匹配為目標，可能會讓決策者有更清晰明確的結(jié)論。

2. 核心要素

單元化設(shè)計五個核心要素：

• 單元化規(guī)則設(shè)計

• 應用代碼改造

• 基礎(chǔ)設(shè)施改造

• 數(shù)據(jù)存儲改造

• 改造落地規(guī)劃

3. 單元化規(guī)則設(shè)計

首先，需要確定一個統(tǒng)一的單元化規(guī)則中心，用于存儲和下發(fā)單元化規(guī)則。實現(xiàn)方式可以是自身實現(xiàn)單元化規(guī)則服務(wù)，也可以借助注冊配置中心，或者兩者共存。

單元化規(guī)則啟用后很難再進行更改，所以在選擇單元化切片的切分維度時要十分慎重。大部分落地的單元化架構(gòu)使用偏多的是用戶ID，比如常見的電商場景，因為通常服務(wù)的最終對象都是終端的用戶，最需要被“單元”的也是用戶的數(shù)據(jù)。

然而，也有一些強地域場景使用“地域”作為單元化規(guī)則的，比如教育類培訓機構(gòu)，中學生校外補課時產(chǎn)生的數(shù)據(jù)基本都會在本地域內(nèi)消化，比如報班基本是用戶所在地的班級（可能老師就是他在學校里的老師），看課程回放也是在當?shù)貜土晻r看。

強地域類型的還有地圖類APP，有些場景會使用設(shè)備ID作為單元化路由規(guī)則，大部分用戶活動的所在地一般不會變，在本地域內(nèi)產(chǎn)生的數(shù)據(jù)也會在本地域內(nèi)被消費。如果有地域遷移的問題，短期內(nèi)可以通過跨地域訪問，長期也可以通過大數(shù)據(jù)等手段發(fā)現(xiàn)后，進行數(shù)據(jù)遷移。

總的說，單元化規(guī)則有兩種常見模式：一種通過算法對固定的key運算，比如取模；另一種是自定義，比如多級路由、自定義路由表。也有兩種組合使用的情況，比如先進行默認的取模路由規(guī)則，如果發(fā)現(xiàn)是路由表中的大客戶，則路由到指定的數(shù)據(jù)中心。

4. 應用代碼改造

應用作為承載業(yè)務(wù)的主要載體，需要對接各方要素，在單元化改造中是主要的改造對象。

首先，要對接單元化規(guī)則，識別被標記流量，需要開發(fā)單元化SDK。在本地緩存單元化規(guī)則，并做到實時更新，使得服務(wù)或網(wǎng)關(guān)可以根據(jù)標記快速、正確地流轉(zhuǎn)流量到正確的單元中，當進行單元流量調(diào)配時也可及時作出反應。

其次，對接各類基礎(chǔ)設(shè)施組件，比如負載均衡、消息隊列、數(shù)據(jù)庫、緩存等。部分系統(tǒng)由于特殊原因在負載均衡中會涉及一些業(yè)務(wù)相關(guān)的腳本，比如根據(jù)UA或業(yè)務(wù)參數(shù)進行頁面重定向，此時要一并進行修改。

最后，應用代碼改造的主要難點在于改造成本，每個部分的對接都涉及到代碼修改，也就意味著要進行開發(fā)、測試、發(fā)布等全流程。而且單元化改造非一蹴而就，應用代碼需要在單元化架構(gòu)過渡階段，做好兼容兩種架構(gòu)的代碼準備，當出現(xiàn)問題時可及時回滾。另外，也要注意單元化作為架構(gòu)調(diào)整的整體需求就會與業(yè)務(wù)開發(fā)需求相沖突，可能會打亂原有上線計劃，給開發(fā)人員造成額外的成本和心理負擔。

5. 基礎(chǔ)設(shè)施改造

首先，需要從全局視角思考基礎(chǔ)設(shè)施改造，比如注冊發(fā)現(xiàn)中心、配置中心、消息隊列、緩存訪問代理、數(shù)據(jù)庫訪問代理等組件，以實現(xiàn)通過“單元”的維度重新分割服務(wù)調(diào)用的范圍和方式，管理單元級的全局配置和消息消費，數(shù)據(jù)層根據(jù)單元化規(guī)則進行的數(shù)據(jù)切片訪問等。

另外，改造還包括支持單元化部署的DevOps、服務(wù)治理、任務(wù)調(diào)度、日志服務(wù)、監(jiān)控告警、資源編排等平臺，以實現(xiàn)基于單元的應用版本管理、全鏈路灰度發(fā)布、單元內(nèi)及跨單元的鏈路跟蹤，單元綁定的鑒權(quán)、限流、熔斷、路由規(guī)則，運維運營方面的單元維度可視化和統(tǒng)計，彈性單元的自動化擴縮容等。

上述場景只是冰山一角，各企業(yè)的單元化改造方案因為自身情況的不同而大相徑庭，而且涉及眾多“準備活動”，比如保證底層網(wǎng)絡(luò)跨AZ跨region的連通性，底層Iaas資源對自身AZ和region的標記，增加分組標簽以形成“單元+虛擬分組”的二層單元結(jié)構(gòu)，Paas平臺（負載均衡、MQ、數(shù)據(jù)庫、緩存等）的高可用、數(shù)據(jù)一致性保障，流量前端的APP添加切流相關(guān)的參數(shù)或標簽，針對單元化對中間件調(diào)用的應用代碼修改等等。

6. 數(shù)據(jù)存儲改造

數(shù)據(jù)的單元化方案在改造過程中是重中之重，比如單元化數(shù)據(jù)庫同步方案，一般本地域的數(shù)據(jù)采用強同步或半同步，異地采用異步同步；數(shù)據(jù)根據(jù)單元化規(guī)則拆分、遷移的方案，可在完成分庫分表后，配合數(shù)據(jù)訪問代理層、手動禁寫、服務(wù)路由、限流等服務(wù)治理手段，以系統(tǒng)或產(chǎn)品線維度逐步遷移的方式，完成系統(tǒng)的數(shù)據(jù)單元化操作。

另外，盡量在單元化改造中不要“順手”進行其它架構(gòu)改造操作，如微服務(wù)拆分、數(shù)據(jù)冷熱拆分等，最好能提前完成。同時并行多想改造會增加實施難度，遷移過程出現(xiàn)問題也難以定位。

7. 改造落地規(guī)劃

單元化改造是一項整體工程，大部分情況是基于原有架構(gòu)做改造，大致的改造過程都會經(jīng)過如下階段。

架構(gòu)設(shè)計：包括技術(shù)可行性評估、應用架構(gòu)、物理部署架構(gòu)、業(yè)務(wù)架構(gòu)、成本及風險評估等，需要技術(shù)團隊主要決策人統(tǒng)一通過，為后續(xù)改造的整體計劃推進提供保障。

改造測試：邏輯理論再完備，還是需要在實際的環(huán)境中進行可行性驗證。此處可選擇在測試環(huán)境先進行技術(shù)驗證，在驗證過程中把改造設(shè)計時沒想到的坑都踩一遍。

并行過渡：測試環(huán)境驗證完畢后，可先選擇邊緣系統(tǒng)改造，再選擇核心系統(tǒng)改造的順序（如果是全新系統(tǒng)則直接進行代碼開發(fā)和系統(tǒng)間對接即可），依次在開發(fā)環(huán)境->測試環(huán)境->預生產(chǎn)環(huán)境->生產(chǎn)環(huán)境逐步過渡上線，注意代碼需同時兼容單元化/非單元化兩種架構(gòu)，以備回滾。

改造完成：在完成所有核心/非核心系統(tǒng)的單元化改造后，體驗單元化帶來的優(yōu)勢，并等待未來業(yè)務(wù)的檢驗。

TSF單元化

1. 微服務(wù)平臺TSF簡介

騰訊微服務(wù)平臺（Tencent Service Framework，簡稱TSF）是一個圍繞著應用和微服務(wù)的PaaS平臺，提供應用全生命周期管理、數(shù)據(jù)化運營、立體化監(jiān)控和服務(wù)治理等功能。TSF擁抱Spring Cloud 、Service Mesh微服務(wù)框架，幫助企業(yè)客戶解決傳統(tǒng)集中式架構(gòu)轉(zhuǎn)型的困難，打造大規(guī)模高可用的分布式系統(tǒng)架構(gòu)，實現(xiàn)業(yè)務(wù)、產(chǎn)品的快速落地。針對原生Spring Cloud應用與Mesh方式零成本接入。

TSF以騰訊云中間件團隊多款成熟的分布式產(chǎn)品為核心基礎(chǔ)組件，提供秒級推送的分布式配置服務(wù)、鏈路追蹤等高可用穩(wěn)定性組件。此外，TSF 與騰訊云 API 網(wǎng)關(guān)和消息隊列打通，幫助企業(yè)輕松構(gòu)建大型分布式系統(tǒng)。

2. TSF的單元化能力

TSF支持使用單元化功能以達到讓不同的業(yè)務(wù)流量根據(jù)一定的單元化規(guī)則分發(fā)到指定的單元里，不同單元之間通過微服務(wù)網(wǎng)關(guān)實現(xiàn)跨單元調(diào)用，當某個單元內(nèi)的服務(wù)器實例出現(xiàn)問題時也不會影響到其他單元業(yè)務(wù)的使用，使得業(yè)務(wù)受影響粒度達到最小，同時單元化也為業(yè)務(wù)容災高可用提供了強有力的保障。

相關(guān)控制臺操作流程詳見：

https://cloud.tencent.com/document/product/649/55879

TSF微服務(wù)網(wǎng)關(guān)SDK支持提供基于Zuul、SCG的單元化能力。核心原理為通過TSF命名空間的服務(wù)隔離機制，實現(xiàn)單元內(nèi)閉環(huán)、單元外隔離管控的服務(wù)發(fā)現(xiàn)效果。

SDK配置過程詳見：

https://cloud.tencent.com/document/product/649/55877

3. 兩地三中心示例

方案說明：

• 基于智能DNS解析實現(xiàn)域名->地域的IDC機房統(tǒng)一，入口通過調(diào)整DNS解析規(guī)則實現(xiàn)跨地域流量切換。
• 通過入口負載->接入網(wǎng)關(guān)，按權(quán)重比例配置路由，實現(xiàn)流量切分，同城雙活應用互為主備。
• 接入路由到應用，基于網(wǎng)關(guān)的標簽化路由實現(xiàn)單元服務(wù)路由規(guī)則匹配。
• 基于本地緩存的單元路由規(guī)則進行服務(wù)尋址實現(xiàn)單元路由調(diào)用。

注意事項：

• 單元內(nèi)服務(wù)調(diào)用盡量在單元內(nèi)閉環(huán)，盡量減少跨單元調(diào)用。
• 如果業(yè)務(wù)需要跨單元調(diào)用，交由微服務(wù)網(wǎng)關(guān)管理跨單元請求的轉(zhuǎn)發(fā)。
• 業(yè)務(wù)南北向流量應盡早完成正確單元的路由尋址，出現(xiàn)單元錯誤時可正常重定向。
• 當出現(xiàn)單元化路由KEY不符合任何單元或訪問時不攜帶KEY時，可報錯或按默認單元化規(guī)則處理。
• 針對正常/錯誤的單元化調(diào)用流向，做到可監(jiān)控、可預警、可管理。

4. 調(diào)用說明

如上圖所示，以銀行轉(zhuǎn)賬為例，說明TSF單元化三類服務(wù)調(diào)用順序。

• 紅：代表單元內(nèi)調(diào)用。全部是個人業(yè)務(wù)數(shù)據(jù)操作，不涉及與其它單元數(shù)據(jù)交互，均在本單元內(nèi)完成閉環(huán)
• 黃：同AZ內(nèi)進行跨單元調(diào)用。如DB1中用戶向DB2中用戶轉(zhuǎn)賬，此時服務(wù)內(nèi)置SDK感知到請求需跨單元時，會將請求路由給網(wǎng)關(guān)進行二次尋址

• 黑：代表跨網(wǎng)關(guān)調(diào)用。如DB1中用戶向DB3中用戶轉(zhuǎn)賬，此時對gatewayB來說可理解為一次外部調(diào)用。

某國有大行單元化落地實踐

1. 案例背景

該銀行是國內(nèi)全球化和綜合化程度很高的銀行。截至目前，在中國內(nèi)地及60個國家和地區(qū)為客戶提供全面的金融服務(wù)，主要包括公司金融、個人金融、金融市場、保險、投資、基金、資管等。此外，還持續(xù)投入建設(shè)金融科技創(chuàng)新平臺。

自與騰訊簽署《全面戰(zhàn)略合作協(xié)議》以來，雙方在云計算、大數(shù)據(jù)、分布式數(shù)據(jù)庫、智能風控、移動協(xié)同辦公、智能客服等金融科技領(lǐng)域都進行了深入合作。

單元化落地過程中，行方技術(shù)架構(gòu)相關(guān)部門經(jīng)過了多次技術(shù)選型和考量，最終確定了以TSF為單元化改造核心，組合TDSQL、TDMQ、CRS、TBDS等產(chǎn)品形成整體矩陣，構(gòu)建統(tǒng)一的PaaS開發(fā)云平臺。

2. 核心問題

該銀行經(jīng)過多年經(jīng)營和沉淀，行內(nèi)業(yè)務(wù)有覆蓋用戶廣、產(chǎn)品線眾多、系統(tǒng)交互調(diào)用復雜、業(yè)務(wù)數(shù)據(jù)及并發(fā)量大等特點，如下為行內(nèi)應用架構(gòu)示意圖。

行內(nèi)規(guī)劃上線核心系統(tǒng)節(jié)點總數(shù)約為10000左右，同時根據(jù)業(yè)務(wù)范圍、產(chǎn)品形態(tài)等劃分為6大整體層次、9個細分層次，其中應用產(chǎn)品線/平臺總數(shù)約130+。

另外，行內(nèi)在業(yè)界首次提出“四地八中心”的異地多活架構(gòu)，對應用側(cè)及支撐側(cè)的RPO、RTO都提出很高要求，整體刷新了金融行業(yè)高可用標準的高度。

基于上述整體情況，由當前架構(gòu)支撐首先會遇到無法擴容問題，即單一數(shù)據(jù)中心無法提供如此量級的節(jié)點數(shù)量，也曾考慮增加異地機房構(gòu)成多活架構(gòu)，但由于跨地域調(diào)用高延時會出現(xiàn)嚴重性能問題而作罷。

其次，行內(nèi)缺乏有效的故障隔離和灰度發(fā)布手段，限流、熔斷、容錯只能解決點的問題，難以從整體進行管理，同時灰度發(fā)布在長鏈路情況下運維成本高，不易頻繁操作。

最后，行內(nèi)龐大的微服務(wù)數(shù)量，導致微服務(wù)連接數(shù)據(jù)庫的連接數(shù)飆升，等待可用連接時造成服務(wù)響應慢。同時在可觀測性方面，海量調(diào)用中追蹤單個請求的難度增加，使得排障速度慢、統(tǒng)計數(shù)據(jù)難分析。

基于以上問題，騰訊微服務(wù)團隊與行內(nèi)技術(shù)架構(gòu)部門多次溝通探討，利用目前TSF已有的語義結(jié)構(gòu)，通過命名空間模擬“單元”，實現(xiàn)服務(wù)間調(diào)用鏈路切分，又通過?“多層標簽”?規(guī)則模型將單元化規(guī)則配置在網(wǎng)關(guān)中?（TSF支持最多16層單元化規(guī)則的且/或邏輯），實現(xiàn)對請求的最細粒度管控。

此外，結(jié)合騰訊云TDSQL、CRS、TDMQ等多款中間件，滿足了行內(nèi)異地多活場景下數(shù)據(jù)最終一致性和高可用容災的要求。整體單元化架構(gòu)示意圖如下。

TSF單元化架構(gòu)中，深度增強了開源微服務(wù)網(wǎng)關(guān)（Zuul、SCG）的功能，通過“命名空間+標簽”的設(shè)計體系，系統(tǒng)可以更方便的進行系統(tǒng)擴容，實現(xiàn)資源的彈性擴縮。

基于命名空間，可以將故障隔離在每個命名空間（單元）中，同時也可方便調(diào)整單元化路由規(guī)則分配的權(quán)重，實現(xiàn)單元級別的全鏈路灰度；

單元切分后，單元內(nèi)鏈路、跨單元鏈路的整體拓撲情況、單個請求調(diào)用情況更加清晰，提高了研發(fā)人員運維排障速率。

根據(jù)行內(nèi)單元化架構(gòu)物理部署，做如下關(guān)鍵要素及說明（從上至下）：

3. 規(guī)則設(shè)計

行內(nèi)單元化建設(shè)過程中，TSF參與了最核心的單元化規(guī)則的設(shè)計及落地，以下做簡要說明。

行內(nèi)單元化規(guī)則模型目前使用?全局+產(chǎn)品線?層次單元化規(guī)則模型，先以用戶ID尾號為單元化KEY，將存量用戶劃分為00-99等量的100個單元，此為第一層全局分片規(guī)則。而后基于各產(chǎn)品線業(yè)務(wù)分片需求自定義二層分片規(guī)則，如對公對私場景，以用戶ID前添加的公/私前綴字符串為KEY進行二次路由計算。

例如，假設(shè)用戶標簽tag值為：B_20210817，一層標簽根據(jù)用戶ID尾號的“17”進行全局分片路由，二層標簽根據(jù)對公對私的業(yè)務(wù)標記“B”（B為對公，P為對私）進行產(chǎn)品線分片路由，最終得出唯一的單元編碼（命名空間ID）。

通過上述?全局+產(chǎn)品線?的層次規(guī)則模型，同時從行內(nèi)現(xiàn)有應用架構(gòu)出發(fā)，在保證穩(wěn)定性、可擴展性、可伸縮性的同時，解決了行內(nèi)單元化切分難題。

4. 改造細節(jié)

由于行內(nèi)應用呈產(chǎn)品矩陣的形態(tài)，即每個產(chǎn)品線由一個微服務(wù)網(wǎng)關(guān)+多個微服務(wù)構(gòu)成，且整個產(chǎn)品線的API暴露、服務(wù)治理均由微服務(wù)網(wǎng)關(guān)控制。這就造成每個產(chǎn)品線的單元化改造需要網(wǎng)關(guān)和微服務(wù)協(xié)同執(zhí)行，增加了改造的難度。

單元化架構(gòu)改造對行內(nèi)原有運維系統(tǒng)也造成一定影響，如對接日志分析系統(tǒng)。之前沒有單元化維度時，相同應用的日志是統(tǒng)一分析的，在單元化改造后，需要在日志打印時增加單元化標記，使得分析結(jié)果可以根據(jù)單元進行統(tǒng)計和展示。

5. 價值體現(xiàn)

TSF單元化架構(gòu)核心價值體現(xiàn)在運維及開發(fā)成本、管理效率、高可用容災、彈性伸縮方面，對比客戶自建單元化架構(gòu)具備運維簡單、可用性高、開發(fā)便捷、配置靈活的特點，且可與TSF平臺本身在諸多功能上進行聯(lián)動。

于此，微服務(wù)平臺TSF給出了一套完整的單元化架構(gòu)方案，解決了行內(nèi)系統(tǒng)擴容、海量調(diào)用、異地容災、故障隔離、灰度發(fā)布等一系列問題。

結(jié)語

經(jīng)過對單元化架構(gòu)相關(guān)概念的梳理，以及TSF單元化在金融行業(yè)的落地案例討論，可以發(fā)現(xiàn)單元化架構(gòu)是一個即復雜又靈活的架構(gòu)，復雜在改造需要一定的前提條件，同時要設(shè)計合理的單元化規(guī)則，謹慎把控整體改造過程；靈活在基于單元化路由可提供的靈活的彈性擴縮及單元級全鏈路灰度發(fā)布，保障業(yè)務(wù)系統(tǒng)多活容災的要求。

單元化架構(gòu)的優(yōu)勢和劣勢還有待繼續(xù)深入研究，在未來助力企業(yè)數(shù)字化轉(zhuǎn)型不斷添磚加瓦。

【參考資料】：

1.https://cloud.tencent.com/developer/article/1823732?

2.https://www.infoq.cn/article/how-weibo-do-unit-architecture

歡迎掃碼進群交流

掃描下方二維碼關(guān)注本公眾號，

了解更多微服務(wù)、消息隊列的相關(guān)信息！

解鎖超多鵝廠周邊！