1. 首頁 > 生活百科 > >

微服務架構體系的深度治理 什么是架構體系？( 七 )

小知識架構體系


進一步匯總個人的質量綜合評估報告 ， 可以獲得針對團隊的開發質量綜合評估報告 ， 這兩個報告本質上就是個人及團隊的研發質量“畫像” ， 完全可以作為個人及團隊KPI考核的重要參考 。 在此基礎之上 ， 還可以通過這兩個報告的變化趨勢（時間縱比） ， 來不斷促使開發人員和開發團隊不斷進行開發質量的改進和開發技能的提升 。
【微服務架構下的測試治理】微服務架構下的測試治理的兩大核心訴求 ， 一個是提高測試的覆蓋度 ， 具體說就是提高需求覆蓋度、代碼覆蓋度、頁面覆蓋度；另外一個則是降低測試用例的維護成本 。
先討論測試覆蓋度 。
首先看一下需求覆蓋度 ， 可以通過服務這個維度來對需求及測試用例進行關聯 ， 找出每個需求下所對應的單元測試用例、自動化測試用例、手工測試用例 ， 在此基礎上 ， 可以把多個開發迭代周期的這些指標進行時間維度的縱比 ， 以得出需求覆蓋度的變化趨勢 。
代碼覆蓋度有很多的工具幫我們來做 ， 比如contest或者JaCoCo這類的工具 ， 這里不再贅述 。
頁面覆蓋度 ， 可以將每次集成測試中調用的頁面以日志的形式記錄下來 ， 再通過日志的聚合分析 ， 結合工程源碼的掃描 ， 兩廂一比較 ， 就可以統計出哪些頁面是沒有被覆蓋到的 。
測試用例的維護成本分兩塊 ， 一塊是新增用例的維護成本 ， 這個比較好度量；比較麻煩的是存量測試用例的變更度度量 ， 我們采用相似度匹配算法 ， 先算出存量測試用例前后兩個版本代碼的相似度 ， 再換算成變更度 。
通過對測試的這兩大類指標的不斷度量和治理 ， 可以實現測試工作的整體“降本增效” 。
【調測能力構建】在服務化的過程中 ， 研發最大的痛點 ， 一定是調試 。 原來單體應用中的服務被拆分到不同團隊 ， 并部署在不同的服務器上 ， 而本地只有一個服務接口 。 這時候要做調試 ， 要么做P2P直連 ， 這需要搭建不同開發版本的集群 ， 成本較高 。 要么做MOCK ， 采用傳統的MOCk手段 ， 要寫一堆的MOCK語句 ， 比如你用mockito ， 你要寫一堆的when…..thenReturn….的語句 ， 耦合度非常的高 。
我們利用分布式服務框架提供的過濾器機制 ， 開發了一個Mock過濾器 ， 通過Mock數據文件來詳細定義要被mock的服務的名稱、入參及出參 。 這樣 ， 當請求過來的時候 ， 將服務名及入參和mock數據中的定義進行比對 ， 結果吻合 ， 就直接將mock數據文件中的出參反序列化后作為服務的調用結果直接返回 ， 同時遠程調用的所有后續操作被終止 。 這樣 ， 通過mock數據模擬了一個真實的遠程服務 。 通過這種方式來構建服務的mock能力 ， 我們就不需要寫一堆的mock代碼了 ， 而且整個過程對業務邏輯來說毫無感知 ， 完全把mock能力下沉到底層的服務框架 。
另外 ， 為了有效降低制作mock文件的成本 ， 我們還基于服務框架的過濾器機制開發了“在線數據抓取過濾器” ， 它可以將指定的服務請求的入參和返回結果都抓取下來 ， 直接寫成mock數據文件 。 通過抓取方式獲得的mock數據文件 ， 往往有更好的數據質量 ， 畢竟反映的是更加真實的業務場景 。 不過 ， 這里還有一個合規性的問題 ， 對線上數據的抓取是種敏感行為 ， 大部分公司這么干都會很謹慎 ， 一般都要做好數據脫敏的處理工作 。 對于我們 ， 目前只在測試環境中進行數據抓取操作 。
通過以上的策略 ， 可以有效改善服務化架構下團隊的開發效率 ， 而且團隊規模越大 ， 效果越明顯 。
【微服務架構下團隊協同】微服務架構下 ， 服務被分散到不同的團隊 ， 經常一個業務會涉及多個團隊之間的協同配合 ， 如何讓團隊內部、團隊之間的協作更高效？
我在前面說了 ， 根據康威定律 ， 組織協作的模式必須是和架構相匹配的 ， 這方面我們也做了不同的嘗試 ， 從綜合效果來說 ， 敏捷模式會更適合微服務架構下團隊之間的協同 。 我們目前采用兩周一迭代、固定發版的模式 ， 同時每個迭代之內 ， 采用“火車發布模式” ， 實行班車制 ， 準點發車 ， 這樣的話 ， 其它協作部門在很早之前就能大概知道我們的一個發布計劃 ， 產品方面也大概知道要把需求放入哪個迭代之中 。 這樣 ， 能夠有效減輕部門間的溝通成本 。 在每期工作量評估的時候 ， 我們一般會預留一些工作量buffer ， 以應對一些臨時性需求 ， 這類需求不受版本約束 ， 按需發布 。 如果這個迭代周期內沒有這類緊急需求的話 ， 我們會從backlog中撈一些架構優化的需求來填補這些buffer 。

推薦閱讀