序言

該篇文章由我的好朋友飛哥完成，傾注了公司全局架構(gòu)組以及各個領(lǐng)域?qū)＜宜健⒓夹g(shù)專家以及業(yè)務負責人的建設性理念驳规。本人很榮幸參與到架構(gòu)大圖討論之中。也希望這篇文章在大家架構(gòu)建設及治理上貢獻一份力量医男。

一镀梭、現(xiàn)狀

• 隨著微服務架構(gòu)貌似不可回頭的發(fā)展、以及業(yè)務加速的前進研底，本地生活的系統(tǒng)架構(gòu)越來越復雜笙什。原到家業(yè)務已有數(shù)百個服務組成琐凭，服務治理浊服、穩(wěn)定性保障牙躺、業(yè)務交付效率的挑戰(zhàn)不言而喻。
• 面對越來越龐大的架構(gòu)和業(yè)務吨掌，組織越來越希望有更多具有全局視角的全局架構(gòu)師脓恕，來做保大促炼幔、產(chǎn)品架構(gòu)方案、中臺架構(gòu)融合方案等肛著，這些都需要全局視角能力跺讯。
• 到目前為止沒有一個元系統(tǒng)或者一個架構(gòu)師刀脏，能夠從整個業(yè)務視角進行全局架構(gòu)層面的掌控。而架構(gòu)往往需要從整體上下文去考慮業(yè)務的運轉(zhuǎn)機制危队，不能掌控全局，這意著架構(gòu)發(fā)展的正確性金麸、穩(wěn)定性有可能依靠的是運氣挥下、某些突出的個體桨醋，而不是體系喜最。

二、愿景

無論是全局架構(gòu)師迷雪、垂直領(lǐng)域架構(gòu)師虫蝶，他們都需要一把利劍：架構(gòu)大圖能真。之前沒人做出來過，而現(xiàn)在我們要做疼约。

• 架構(gòu)大圖不是告訴我們架構(gòu)怎么設計（DDD忆谓、SLOID原則設計模式踱承、系統(tǒng)邊界問題不在本文探討范圍內(nèi)，但是后面會稍微扯一下^_）昙沦，而是告訴我們商業(yè)背后的支撐能力是什么盾饮，現(xiàn)狀是什么，從而做到對架構(gòu)未來的可見和可控普办。
• 現(xiàn)在一個業(yè)務的架構(gòu)文檔有幾個問題：無沉淀徘钥、非最新呈础、分散在各種wiki空間，文檔之間沒有關(guān)聯(lián)性沙廉。架構(gòu)大圖來解這個臼节。
• 需要以商業(yè)視角去看架構(gòu)官疲。做到兩個能力：可見亮隙、可控溢吻。
  注意：可見是可控的前提。
  大圖的能力圍繞可見犀盟、可控兩點展開阅畴。
  

1迅耘、 可見

可見分為四個關(guān)鍵子能力

• 架構(gòu)元數(shù)據(jù)可見
• 變更可見
• 服務級別可見
• 服務目標颤专、服務協(xié)議可見
  

1.1栖秕、架構(gòu)元數(shù)據(jù)"可見"

架構(gòu)元數(shù)據(jù)"可見"是后面變更可見、服務級別可見只壳、服務目標可見的基礎吼句。分為兩個關(guān)鍵：元數(shù)據(jù)結(jié)構(gòu)和瀏覽方式

1.1.1 元數(shù)據(jù)結(jié)構(gòu)由來

怎么才能跟上時代的變化，架構(gòu)的變化况毅，從互聯(lián)網(wǎng)到移動互聯(lián)網(wǎng)尔许，從傳統(tǒng)零售到新零售...現(xiàn)在我們思考的是：究竟什么才是隱藏在諸多變化背后不變的東西终娃？什么才是支配著萬千變化的那雙看不見的手棠耕？
追隨前者會讓我們疲憊不堪，迷失不斷變化的幻象當中辉巡；而找到后者蕊退，則能讓我們擁有一顆堅定的心瓤荔，并擁有長期主義的心態(tài)。
架構(gòu)大圖追求的是長期主義今瀑，并使用基于領(lǐng)域的概念來結(jié)構(gòu)化元數(shù)據(jù)橘荠。為什么用領(lǐng)域愉粤，先來嘮叨下幾個變和不變:

• 架構(gòu)的變和不變
  只要世界一直存在衣厘，架構(gòu)所支持的組織压恒、KPI探赫、商業(yè)伦吠、規(guī)則都會一直發(fā)生變化魂拦，不變的是架構(gòu)的辯論及自我批判：擴展性芯勘、邊界、復用性衡怀、穩(wěn)定性等抛杨，架構(gòu)的辯論和演化是沒有終點的荐类，這是不變的掉冶。

• 商業(yè)的變和不變
  所謂技術(shù)支撐商業(yè)，在商業(yè)這個層面，很多東西都在瞬息萬變璧亚，但至少有兩件事是永遠不會變的：第一癣蟋，一切商業(yè)的起點永遠都是消費者獲利狰闪；第二埋泵，人性是不變的罪治。

• 行業(yè)的變和不變
  再來看看下面三個行業(yè)的變和不變：

  • 零售行業(yè)：阿里投資或合作了聯(lián)華觉义、百聯(lián)浴井、大潤發(fā)磺浙、銀泰和三江購物，騰訊則選擇了沃爾瑪箍鼓、永輝和家樂福款咖。很多傳統(tǒng)零售行業(yè)的從業(yè)者都發(fā)出了“被時代拋棄”的感慨奄喂。同時跨新，盒馬、天貓小店等又涌了出來赘被。整個零售行業(yè)讓我們看到了非常大的變化民假。但其實龙优，從傳統(tǒng)零售到新零售有一點是一直不曾改變的：那就是所有消費者都希望買到的產(chǎn)品更加便宜彤断、品質(zhì)更好宰衙、選擇更多、送貨更快一屋。所以陆淀，不論線上電商，還是線下零售楚堤，這個核心都是不變的身冬。
  • 媒體行業(yè)：雖然現(xiàn)在傳統(tǒng)媒體已經(jīng)式微岔乔，但有一點是不變的雏门，那就是消費者對好的內(nèi)容的需求---消費者永遠希望媒體提供內(nèi)容更全面、更有趣宙帝、更深入透徹步脓、更通熟易懂浩螺，同時內(nèi)容的傳遞速度更快要出。所以不論是傳統(tǒng)媒體，還是新媒體相嵌，這個核心都不曾改變。
  • 互聯(lián)網(wǎng)行業(yè)：一直在日新月異地飛速發(fā)展格了，從互聯(lián)網(wǎng)到移動互聯(lián)網(wǎng)徽鼎，從博客到微博再到微信，從APP時代到5年后的可能出現(xiàn)Non Ui 時代棠隐『纯浚可有什么不變的嗎？至少有一樣不變嗡贺，那就是人們對互聯(lián)網(wǎng)的核心需求不變---人們希望通過互聯(lián)網(wǎng)能夠高效便捷地實現(xiàn)現(xiàn)實生活中所需要的一切诫睬。比如帕涌，通過互聯(lián)網(wǎng)滿足閱讀、社交亲澡、娛樂辟躏、學習捎琐、消費瑞凑、理財、約X等需求练慕，以及通過互聯(lián)網(wǎng)處理生活中各種事務铃将。

• 行業(yè)+商業(yè)的不變
  上面把商業(yè)的變和不變劲阎、行業(yè)的變和不變分別講了下鸠真，那么它們兩者當中共同不變的就是都需要”業(yè)務主角“和”價值鏈“，
  比如外賣行業(yè)的業(yè)務主角：

  • 消費者：

    • 希望能在自己所在地域（3公里內(nèi)）內(nèi)沦零，快速精準地找到需要的商品和服務（外賣路操、堂食茴她、娛樂丈牢、洗浴、電影己沛、咖啡茶飲等）申尼。
    • 如果到家需要送貨快师幕，到店需要服務好霹粥。

  • 商家：

    • 提升業(yè)務范圍：希望自己的業(yè)務范圍從原來的1000米內(nèi)擴展到3公里內(nèi)后控。
    • 短路經(jīng)濟：外賣到家業(yè)務捌朴，需要有高效的物流服務张抄。
    • 增加流量：提高品牌的曝光度砂蔽，增加客流和訂單轉(zhuǎn)化。
    • 提升人效和坪效：有效提高生產(chǎn)和出貨效率署惯、餐廳業(yè)務提高翻臺率等察皇。
    • 供應鏈：降低采購成本、提高運輸效率泽台、標準化貨物標準，庫存流程怀酷、提升食品安全稻爬、選品、選址等蜕依。
    • 客戶服務：通過數(shù)字化運營能力確蔽Τ客訴的有效處理、從而提升消費者體驗和商品復購率样眠。

  • 騎手：

    • 希望到店后友瘤，商家有及時的出餐效率。
    • 希望精準的目的地路徑規(guī)劃檐束，提高運輸效率辫秧。
    • 在騎手接單、送貨被丧、和商戶盟戏、消費者溝通的同時，解放騎手的大腦甥桂、雙手柿究、雙腳。

看了上面的內(nèi)容就能明白商業(yè)壓根就不關(guān)心后面是不是分表分庫黄选、是否使用了設計模式蝇摸、是否寫了100多個分支的if else。業(yè)務最關(guān)心的是用什么能力來支撐“業(yè)務的運轉(zhuǎn)機制”办陷。這個“業(yè)務運轉(zhuǎn)機制”就能夠幫助業(yè)務主角產(chǎn)生價值貌夕，而這個產(chǎn)生價值的過程就是價值鏈：

• 招商入住：外賣平臺招募符合要求的餐飲商戶入駐懂诗。
• 商品維護：餐飲商戶將合適的商品上傳至平臺進行銷售蜂嗽。
• C端需求：消費者產(chǎn)生外賣需求，尋求供給殃恒。
• 導購投放：外賣平臺面向消費者進行導購植旧、商品曝光等。
• 交易下單：消費者對某一商品產(chǎn)生興趣進行選購离唐、交易病附、支付。
• 商戶備貨：商戶接受訂單亥鬓、開始備貨完沪、出餐。
• 物流履約：騎手到店取餐、送餐覆积。
• 業(yè)務完成：消費者確認收貨听皿。

以上就是業(yè)務價值鏈的業(yè)務環(huán)節(jié),每個業(yè)務環(huán)節(jié)都可以用一個或多個領(lǐng)域去支撐。架構(gòu)大圖的頂層結(jié)構(gòu)我們按照領(lǐng)域來劃分宽档。

1.1.2 元數(shù)據(jù)結(jié)構(gòu)說明

• 分層原則：

  • 任何一層的內(nèi)容都是下層內(nèi)容的總結(jié)尉姨。打個比方，如果下一層是油麥菜吗冤、青菜等又厉，那么上一層就是應該是對他們的總結(jié)—蔬菜，而不是蛋白質(zhì)
  • 同一層的內(nèi)容必須具有相同的特征椎瘟。打個比方覆致，如果上一層的內(nèi)容是蔬菜，那么下一層的內(nèi)容就是油麥菜肺蔚、菠菜等煌妈。不能把香蕉放進來。因為香蕉并不是蔬菜婆排，與菠菜声旺、油麥菜等并不具有相同的蔬菜特征
  • 同一層的內(nèi)容必須按照一定的邏輯排序排列。打個比方：比如說交易領(lǐng)域的模塊段只，你可以按照業(yè)務上的先后順序去定義排列腮猖，或者根據(jù)SLA的等級來排列，排列規(guī)則是可以定義的赞枕。
  • 每一層的元素之間不能有交叉澈缺、也不能有遺漏。比如：我們把性別分為男性和女性炕婶，這個世界上除了男性就是女性姐赡，如果我們將人分為男人和小孩，因此就出現(xiàn)了交叉柠掂。
    （肯定的是：現(xiàn)狀總是那么的不完美）

• 每層定義

  • 領(lǐng)域
    有五個特點：

    • 領(lǐng)域和組織架構(gòu)沒有層的關(guān)系项滑，恰恰相反，組織架構(gòu)盡量來反映領(lǐng)域涯贞。
    • 一個領(lǐng)域可以支撐一個或多這個業(yè)務環(huán)節(jié)枪狂，一個業(yè)務環(huán)節(jié)由一個或多個領(lǐng)域來支撐。
    • 領(lǐng)域的劃分追求業(yè)務環(huán)節(jié)夠用原則宋渔，不追求100%完美定義州疾。（架構(gòu)的變和不變）
    • 每一個領(lǐng)域都有一個核心的問題目標，這個目標將層層拆解到這個領(lǐng)域下面的所有模塊皇拣，比如交易領(lǐng)域严蓖，是來解決買賣雙方商品貨幣交換問題的。
    • 領(lǐng)域和行業(yè)線沒有必然關(guān)系，比如交易領(lǐng)域：他可以支持外賣颗胡、到家毫深、新零售，如果外賣和到家目前是煙囪就是兩個領(lǐng)域杭措。

  • 子領(lǐng)域
    為什么有了領(lǐng)域還要有子領(lǐng)域呢费什？兩個原因：

    • 因為大部分領(lǐng)域還是信息太過龐大，老辦法我們需要繼續(xù)切分手素，比如交易領(lǐng)域分：正向交易、逆向交易瘩蚪、交易分析查詢等子領(lǐng)域泉懦。 營銷領(lǐng)域分：場景營銷、營銷中臺疹瘦、商業(yè)營銷等子領(lǐng)域崩哩。

    • 也就是說一個領(lǐng)域可能會支撐某個業(yè)務環(huán)節(jié)下的多個子場景或者多個業(yè)務環(huán)節(jié)，就可能會拆分到多個子領(lǐng)域言沐。每個業(yè)務環(huán)節(jié)的子場景的目的不同邓嘹，每個業(yè)務環(huán)節(jié)的目的也不同。

      
      

  • 模塊

    • 模塊是用戶能夠完成一系列業(yè)務操作完整功能险胰。比如購物車模塊汹押、下單模塊。在功能模塊設計過程中起便，需要確保用戶能通過一個功能模塊完整的完成一項工作棚贾，而不是半個工作。

      
      

    • 用于體現(xiàn)實際上支撐模塊的appid榆综，一個模塊有一個或者多個服務組成妙痹。

      
      

  • 用例
    和UML 的use case一個意思，一個或者多個用例來解釋模塊鼻疮。因為一個模塊里會有多個操作的.比如購物車模塊就有三個用例：添加購物車怯伊、減少購物車、查詢購物車判沟。
    

  • 調(diào)用鏈路
    某個use case里面的case耿芹，比如說觸發(fā)添加購物車操作，后面接口是一系列調(diào)用鏈路的水评，架構(gòu)圖采用trace的離線計算方式將鏈路關(guān)系沉淀起來猩系，并且把業(yè)務元數(shù)據(jù)和技術(shù)元數(shù)據(jù)給關(guān)聯(lián)起來了。

    鏈路關(guān)系有個特點中燥，就是它經(jīng)常會發(fā)生變化寇甸，需要架構(gòu)大圖系統(tǒng)自動離線去感知 并且提示到領(lǐng)域owner。

    
    

  • 技術(shù)元數(shù)據(jù)
    到了架構(gòu)圖的最底層，將技術(shù)拿霉，鏈路時序圖上的節(jié)點分為：SOA 服務appid吟秩、緩存、消息隊列绽淘、DB等內(nèi)容涵防。
    

1.1.3 元數(shù)據(jù)瀏覽方式

瀏覽方式需要做到像高德地圖那樣的體驗，分為以下三點：

• Zoom in：從業(yè)務環(huán)節(jié)—>到支撐這個業(yè)務環(huán)節(jié)的領(lǐng)域-->子領(lǐng)域-->模塊—>用例->鏈路沪铭。（像高德地圖的zoom in功能）壮池。
• Zoom out：是Zoom in的逆順序。
• Context Search：你可以根據(jù)領(lǐng)域Owner杀怠、SOA服務名Appid椰憋、接口名、用例名赔退、領(lǐng)域名橙依、Redis集群名或者db instance Name 去找到這個元素所在的位置，然后根據(jù)這個元素位置再 做Zoom in 硕旗、Zoom out 操作窗骑。

1.2 變更"可見"

不是指所有的變更記錄可存儲可查詢，因為這些都有了漆枚。而是在"架構(gòu)元數(shù)據(jù)"搭建完的基礎上把運營创译、代碼、中間件等變更都串起來浪读，把變更影響哪些業(yè)務昔榴、業(yè)務環(huán)節(jié)、業(yè)務用例碘橘、業(yè)務主角互订，以及影響到什么程度都可視化出來，否則一個變更窗口出現(xiàn)故障痘拆，那么多變更怎么去縮小影響呢仰禽？goc得拉個故障群問一堆人到底是怎么回事？但這個過程直接影響到1/5/30的指標纺蛆。

1.3 服務級別"可見"

• 業(yè)務影響
  • A級：涉及關(guān)鍵業(yè)務吐葵，如導購、交易桥氏、資金温峭、物流、紅包字支、履約等凤藏。
  • B級：涉及非關(guān)鍵業(yè)務奸忽，如：hr系統(tǒng)、穩(wěn)定性工具平臺等揖庄。
  • C級：業(yè)務量很低將被遷移栗菜，將要下線的系統(tǒng)

由于業(yè)務影響的定義，B蹄梢、C類里面是不需要分級的疙筹，A級對于交易影響進行再分級。

• 交易影響
  • 1級：如系統(tǒng)down了影響交易量比20%以上禁炒。
  • 2級：如系統(tǒng)down了影響交易量比2%～20%而咆。
  • 3級：如系統(tǒng)down了影響交易量比2%一下。

1.4 服務目標齐苛、服務協(xié)議"可見"

有一個大佬說過："如果你無法量化一件事翘盖，你就無法改進它"。Google SRE 里面定義了三個名詞凹蜂，SLO、SLI阁危、SLA玛痊，這里的SL是service level，服務級別狂打，而I擂煞、O 、A分別是indicator趴乡、object與agreement对省。和架構(gòu)大圖關(guān)聯(lián)后可以做到業(yè)務鏈路覆蓋率精準檢查。

• 服務目標（SLO）
  SLI 是服務狀況體現(xiàn)最直觀的數(shù)字晾捏，比如 Request latency蒿涎、Error rate、Cpu rate等惦辛，你不需要收集監(jiān)控面板里所有的metric劳秋，盡可能少但這些SLI能說明服務是否健康。 而服務目標SLO是一組值的范圍胖齐，自然的SLO定義就是玻淑，某SLI再正常情況下需要小于某個值或者處于某個大小值之間。選擇一個SLO不是件容易的事呀伙，當然我們并不需要一開始就設定好這個范圍补履，比如QPS，這個指標取決用戶流量剿另，而我們無法預先做出準確的判斷的箫锤。
• 服務協(xié)議（SLA）
  服務級別的協(xié)議是如果服務時效贬蛙、或者不達到預期的效果，該怎么做麻汰。一般是賠償速客、退款，一般來說五鲫，技術(shù)是不參與SLA的制定溺职，因為SLA更靠近商務層面，比如搜索服務位喂，并沒有暴露給用戶的SLI浪耘，但是卻有和全世界都簽訂的協(xié)議，也就是SLA塑崖。（你注冊賬號時七冲，一大推文字條款。外賣沒有按時送到公司就要賠錢等）规婆。

2澜躺、可控

在可見建設完以后，才有能力去做可控抒蚜【虮桑可控能力分為兩個關(guān)鍵

• 架構(gòu)可控
• 穩(wěn)定性可控

1、架構(gòu)"可控"

架構(gòu)大圖可見以后嗡髓，我們是不是有"自信地"引入架構(gòu)評審機制操漠，為什么是"有自信"呢？ 因為架構(gòu)不可見之前饿这，架構(gòu)師面對評審,時常兩眼一抹黑浊伙。有三個問題：

• 服務定位不清晰：某領(lǐng)域開發(fā)申請一個新appid，架構(gòu)評審后這個appid可能進入大海长捧，有了架構(gòu)大圖后嚣鄙，評審時通過zoom in 、zoom out瀏覽整個架構(gòu)唆姐，就能知道這個appid 在什么模塊拗慨，這個模塊所在的業(yè)務上下文。
• 重復造輪子：在評審的時候奉芦，感覺這個appid做的事情已有appid做了赵抢，但是就是想不起來，對應不上声功，評審會時間又有限烦却，md算了就過了吧。有了架構(gòu)大圖后先巴，你就知道這個appid所在的業(yè)務位置和有無重復其爵。
• 架構(gòu)文檔不集中并且不一致：無論是新增appid冒冬、架構(gòu)變更。評審過的架構(gòu)大圖元素摩渺、分類自動形成了架構(gòu)文檔简烤，能夠使文檔和現(xiàn)實始終保持一致，解決文檔非最新摇幻、散落在各種wiki空間的問題横侦。

2、穩(wěn)定性"可控"

穩(wěn)定性一般都有一套技術(shù)風險體系绰姻，但是大家還是覺得很難做枉侧，兩個關(guān)鍵原因：

• 與業(yè)務易脫節(jié)、跟不上業(yè)務：穩(wěn)定性同學有技術(shù)風險的工具和套路狂芋，但是他們有可能沒有產(chǎn)品研發(fā)那么快跟上業(yè)務榨馁。另外分析鏈路經(jīng)常是沒有沉淀的，要去trace里抓然后在寫到wiki里帜矾，之后又發(fā)現(xiàn)變了翼虫。心好累。最后需要定期和業(yè)務團隊對下關(guān)鍵鏈路監(jiān)控和預案屡萤，因為這兩點的有效性可能會發(fā)生變化蛙讥。
• SLO一桿子打死：只有一套SLO，無法明確到每個領(lǐng)域模塊的SLO（每個業(yè)務是有區(qū)別的）灭衷，目標沒有細分，穩(wěn)定性工作沒有明細支點旁涤，雖然有套路有工具翔曲，但是不知道每個業(yè)務的詳細分級、SLO是什么劈愚，從而無法有針對性的巡檢瞳遍、演練。
• 穩(wěn)定性KPI管理需要人工整合而且有遺漏：原來故障預算指標菌羽、風險覆蓋率指標掠械、過程指標達成情況需要從不同的文檔、系統(tǒng)去整合注祖。還會有遺漏猾蒂，比如說關(guān)鍵路徑覆蓋率100%，那么哪些是關(guān)鍵路徑會有遺漏是晨，有了架構(gòu)大圖之后KPI的目標設定和實際情況（故障管理肚菠、巡檢、演練）都是捆綁在一塊的罩缴，做到了實時跟蹤蚊逢、無遺漏层扶。

為了解決這兩個難做，在實現(xiàn)了架構(gòu)大圖"可見"之后烙荷，來說下如何做到穩(wěn)定性可控镜会，一共有三項：

• SLO風險巡檢
• 預案體系
• 鏈路風險報告

2.1 SLO風險巡檢

• 巡檢的范圍是什么？當然是各自SRE負責的領(lǐng)域-->子領(lǐng)域-->模塊-->use case-->調(diào)用鏈路终抽。
• 健康程度目標是什么戳表？是架構(gòu)大圖"可見"里的服務目標、服務協(xié)議拿诸。有詳細的目標拆解扒袖，才有之后的穩(wěn)定性策略和行動。每個業(yè)務都有自己的目標亩码，就在架構(gòu)大圖的服務目標季率、服務協(xié)議"可見"里。

• 巡檢演練結(jié)果如何和業(yè)務場景掛鉤描沟？SLO飒泻、SLI定好了，就要和監(jiān)控系統(tǒng)項掛鉤吏廉，這樣在巡檢系統(tǒng)掃描后泞遗，能夠比較當前系統(tǒng)的監(jiān)控值是否符合SLO，如果沒有達標的席覆，系統(tǒng)巡檢系統(tǒng)將其變成一個優(yōu)化項報表里進行跟蹤史辙。

  
  
  
  

  在架構(gòu)大圖的基礎上設置目標->計劃->行動->結(jié)果 ，形成一個持續(xù)性的循環(huán)流程：

  
  

2.2 預案體系

故障快速定位和止損的理想處理方式是故障業(yè)務定位（架構(gòu)大圖協(xié)助）和預案執(zhí)行打通佩伤，當發(fā)生故障時聊倔，能夠判斷出故障業(yè)務定位、影響生巡、以及對應的預案耙蔑，并觸發(fā)預案進行執(zhí)行。當然實際的故障處理過程中有很多地方需要考慮孤荣，雖然并不是所有故障都能提前建立響應的預案甸陌，但我們可以根據(jù)歷史故障和一些先驗知識將故障進行歸類，建立相應的預案盐股。另外建立預案時钱豁，要方便預案執(zhí)行和觸發(fā)。如果不方便的話很難短時間內(nèi)處理故障遂庄，最關(guān)鍵的問題是判斷預案觸發(fā)的時機寥院，以及當前是否應該執(zhí)行預案。

線上服務故障大體可以歸類為如下原因：

• 80%的故障是變更引起的故障
• 流量和容量的變化引起的故障
• 依賴故障
• 機房涛目、網(wǎng)絡等硬件和環(huán)境故障
• 其他：比如ID生成益處導致的故障

2.3 鏈路風險報告

在架構(gòu)大圖可見中的元數(shù)據(jù)結(jié)構(gòu)中每個用例的case就對應一個調(diào)用鏈路秸谢，這為鏈路風險分析報告提供了基礎凛澎，讓我們清晰看到哪些業(yè)務場景下面有鏈路風險。

鏈路風險分析就是從鏈路通信的歷史數(shù)據(jù)出發(fā)估蹄，分析出鏈路當前存在的風險塑煎，減少鏈路通信的隱患，提高系統(tǒng)的整體穩(wěn)定性臭蚁。鏈路風險分析可以解決的問題域很多最铁，如超時時間設置是否合理、重試次數(shù)設置是否合理垮兑、服務SLA指標設置是否合理冷尉、服務強弱依賴關(guān)系是否符合預期，服務通訊相關(guān)的一大部分問題是由于鏈路風險導致的系枪，可以通過鏈路風險分析的方式提前發(fā)現(xiàn)和解決雀哨，避免故障發(fā)生。

鏈路風險分析的基礎是鏈路實時trace指標私爷，我們把這些數(shù)據(jù)離線抽取過來做分析雾棺。

下面介紹四種典型鏈路風險項：

• 超時和SLA風險：

  客戶端訪問服務端超時時間的設置，和實際訪問情況不符衬浑。是非常常見的鏈路風險捌浩。上游服務的超時設置太 小，會導致本來以為可以正常返回的請求超時工秩，影響服務的SLA和正常的服務體驗尸饺；超時設置過大，會導致下游服務故障時上游服務超時等待時間太長助币，嚴重時把整個系統(tǒng)拖垮侵佃。因此，超時設置直接關(guān)系到系統(tǒng)的穩(wěn)定性奠支，需要有相應的機制指導服務超時設置。

  超時風險分兩種：一種超時時間和實際不符抚芦。還有一種是上下游的超時時間不匹配倍谜，比如有A、B叉抡、C3個服 務尔崔，服務A訪問服務B，服務B再訪問服務C褥民，但實際業(yè)務當中經(jīng)常會遇到A訪問B的超時比B訪問C的超時要小季春。

上述兩種超時風險均可以通過鏈路風險分析來解決。思路其實很簡單消返，離線收集trace指標數(shù)據(jù)载弄，通過trace數(shù)據(jù)分析當前服務訪問的各分位耗時耘拇，比如99.99分位耗時是50ms，把要求的分位耗時和超時配置進行比較宇攻，如果差異過大惫叛，就存再超時配置風險。實際超時配置修復時逞刷，可以使用上述分析分位耗時作為基數(shù)嘉涌，然后加上一個偏移Buffer】淝常基數(shù)較小時仑最，可以加上固定偏移（如5～50ms），如果基較大時帆喇，可以使用固定倍數(shù)的偏移（如1.1～1.5倍）

• 強弱依賴或重試風險：

  服務之間進行通信警医，如果鏈路通信失敗會導致整個系統(tǒng)失敗，一般將這兩個服務之間的關(guān)系稱為強依賴番枚，反之是弱依賴法严。我們可以基于服務的強弱關(guān)系進行降級、熔斷等操作葫笼。強弱依賴服務風險是指鏈路通信之間的關(guān)系和預期不符深啤，比如，服務A調(diào)用服務B鏈路是弱依賴路星，但是隨著需求迭代業(yè)務邏輯發(fā)生了變化溯街，可能不經(jīng)意間服務A調(diào)用服務B變成強依賴，可是大家還是按照之前的認知洋丐，把他當成弱依賴呈昔，這就是一個很大的風險點。特別是鏈路故障時友绝，基于弱依賴的前提進行了降級堤尾，就可能釀成悲劇～。導致整個系統(tǒng)不可用迁客。因為需要有相應的機制郭宝，定期檢查出當前鏈路關(guān)系的風險點。

  強弱依賴分析可以采用故障注入的思路掷漱，但與直接線上系統(tǒng)進行故障注入和演練不同粘室，為了不影響線上服務的穩(wěn)定性，可以通過線下環(huán)境進行強弱依賴風險檢測卜范。具體思路是通過架構(gòu)大圖元數(shù)據(jù)沉淀的調(diào)用鏈路關(guān)系衔统，針對這個調(diào)用鏈路，通過故障注入的方式讓鏈路調(diào)用返回失敗，構(gòu)造一個測試用例锦爵，在該測試用例基礎上執(zhí)行正常的自動化測試舱殿。如果自動化測試成功，證明鏈路失敗對整個系統(tǒng)沒有影響棉浸，說明該鏈路是弱依賴怀薛，反之是強依賴。通過這種方式迷郑，可以判斷出每個鏈路最新的鏈路關(guān)系枝恋，然后和基礎鏈路關(guān)系進行比較，如果有差異嗡害，說明鏈路關(guān)系發(fā)生了變化焚碌，產(chǎn)生了新的鏈路依賴風險。

  重試風險也可以采用同樣的思路進行分析霸妹，這里不詳細展開十电。

• 鏈路調(diào)用風險：

  架構(gòu)大圖元數(shù)據(jù)結(jié)構(gòu)里的調(diào)用鏈路是一個寶藏，可以從中慢慢挖掘出鏈路調(diào)用層面的很多風險叹螟。比如鹃骂，當前服務調(diào)用超過20個下游服務，扇出過大罢绽，不太符合微服務的設計準則畏线，可以考慮是否進一步的分析。服務化當中良价，單個請求的鏈路特別長時寝殴，會帶來一定的性能問題，因此可以從架構(gòu)大圖元數(shù)據(jù)當中將TOP10的長鏈路明垢，或者深度超過6的鏈路列出來蚣常，反饋給業(yè)務owner，看看有必要進行架構(gòu)層面的調(diào)整痊银。微服務拆分和設計當中抵蚊，建議不要出現(xiàn)兩個服務相互依賴的場景，可以通過調(diào)用鏈路查找當前是否存在有環(huán)的鏈路溯革，如果成環(huán)泌射，說明服務之間產(chǎn)生了相互依賴，可以將類似風險反饋給業(yè)務人員進行整改鬓照。

• 集群或拓撲風險：

  集群或者拓撲風險是鏈路風險的一個主要來源，之前工作當中遇到過不少集群和單元機房風險相關(guān)的案例孤紧。比如豺裆，某線上集群的一批機器因為保修要下線一段時間，但機器修好后遺漏掛載，導致部分機器白白閑置臭猜；服務A調(diào)用服務B本來是同機房調(diào)用躺酒，由于故障或者流量切換演練等原因臨時將調(diào)用關(guān)系切換到其他機房的服務B，但是事后沒有切回來蔑歌，導致服務A調(diào)用服務B一致跨機房調(diào)用羹应，影響用戶體驗和穩(wěn)定性，這種部署風險沒用通用解決思路次屠，需要針對具體的風險增加相應的措施园匹。

  
  

最后總結(jié)下架構(gòu)大圖的能力

可見

• 架構(gòu)元數(shù)據(jù)可見
• 變更可見
• 服務級別可見
• 服務目標、協(xié)議可見

可控

• 架構(gòu)可控

• 穩(wěn)定性可控