Q1：無線充電有哪些方式?原理是什麼?  

  A：現在劃分的無線充電類型有好些種，比如感應式、共振式、微波傳輸式等等，不過總體來說，它們的基本原理都是一樣的，就是利用交變電磁場的電磁感應，來實現能量的無線傳輸。 　　 感應式的無線電能傳輸算是目前比較成熟的技術，很多手機無線充電、甚至我們常見的電磁爐就是利用的這種原理。由於數碼設備空間小，接收線圈也小，加上充電設備功率小，所以通常充電的距離近(甚至需要與充電座接觸)，不過相對電磁輻射也小。 　　 共振式則是麻省理工目前在開發的一類充電技術，說起來也不複雜，他們利用電磁感應現象，加上共振的原理，能提升無線充電的效率。共振傳輸的距離比普通感應式更遠一些，而麻省理工目前正在進行小型化的研究——對於車長好幾米的電動車來說，這方面的技術壓力倒不是太大。 　　 微波傳輸式此前更多出現在科幻電影或者小說裡面，實際上它也是無線電力傳輸的一個很好的方式，只不過受到發送功率等方面的限制，並未大規模實用化。微波傳輸的最大好處就是傳輸距離遠，甚至可以實現航天器與地面之間的能量傳輸，同時還可以實現定向傳輸(發射天線有方向性)，未來前景值得期待。  

 

Q2：無線充電的好處有哪些?

  A：無線充電的第一個好處就是不需要線，不必為了到處找充電線而費神。第二就是無線充電在硬體方面的標準更容易統一。  
Q3：有待解決的問題有哪些?   A： 一、傳輸效率是所有無線充電都面臨的問題，對於電動車這樣充電功率更大的“電器”來說更是如此——電能首先轉換為無線電波，再由無線電波轉換成電能，這兩次轉換都會損失不少的能量。   二、電磁相容也是無線充電需要解決的技術瓶頸之一。電磁波很容易產生洩漏，當大功率的車用無線充電設備運行時，也會對周圍的生物和電子設備產生影響，甚至會危害人體健康。利用封閉的自動智慧化車庫安裝無線充電設備是解決電磁相容比較好的途徑，不過成本也確實不菲。   三、電氣標準等方面的問題。  
Q4：有哪些典型案例呢？   A：從國外車企來看，特斯拉、沃爾沃、奧迪、寶馬、賓士等傳統汽車都已經開始研發或測試旗下電動車的無線充電系統。全球通訊以及IT界的新貴們也將“觸角”伸向了電動車無線充電的新領域。而在無線充電的規劃和靜態還是動態充電的選擇上，國內外車企則各有不同。  
一、沃爾沃：利用道路進行無線充電  

  在瑞典，沃爾沃集團、瑞典電力公司 Alstom、瑞典能源局正在共同合作測試利用公路給電動汽車充電，通過將兩個電源線鋪設在公路上，電動車經過時便可獲得電力供應。這項技術的核心在於汽車得搭載集電器，集電器與公路上的電纜連線，利用直流電充電。汽車不必走在電纜的中央，但必須時速大於 60 公里。 　　 沃爾沃已在瑞典的 H llered 測試中心建立了一條 1/4 英里長的軌道，用一輛卡車進行測試。未來，當電動汽車需要充電時，必須安裝無線發射器讓道路感知，然後經過加密信號啟動充電功能。由於對速度有要求，沃爾沃的這一充電系統適合在高速路上實行，如果未來成真，人們出遠門的時候就不用擔心電力問題。   利用公路地表進行無線充電很可能是未來的發展方向，相比地面上的設施，它的好處是不需要佔用地面空間，可減少建設、維護成本。汽車不需要停下來進行充電，可持續駕駛。   沃爾沃的這一舉措是為了給電動汽車打造一個良好的充電網路。不過它需要面對很多普及的問題，比如公路建設、設計問題、集電器、電動汽車的支持等。就像無人駕駛一樣，這是一個浩大的工程，短期內還難以實現。  
二、高通：Halo的感應充電系統  

  在2015年4月22日的Formula E電動方程式錦標賽上，高通就展示了自己研發的Halo無線汽車充電技術。只要將車開到充電墊的正上方，當充電線圈對齊之後，電流便會開始輸送到汽車當中。如果汽車和墊子之間存在外來物體，系統還可自動暫停充電。   高通Halo的感應充電系統是個相對直接明瞭的構想：一個由兩個鐵氧體組成的變壓器，兩者的旁邊還各有一個電線線圈。一般來講，這兩個部分是連接在一起的。交流電會在第一個線圈中被轉換成磁場，隨後再被第二個線圈轉換成直流電。而高通Halo卻將兩個鐵氧體分離開來，並讓系統跨越空氣間隔實現最大功率傳輸。 　　 Halo的無線充電器被放置在了車尾的位置，是一個比機上盒稍大一些的金屬盒子，並連接著幾條橙色的電線。至於另一半的充電器，就在汽車的下方。感應充電其實是可以作用於移動中的車輛的。Halo目前已經具備了半動態充電的能力，可在最高30mph的速度下進行電能傳輸。  
三、日產無線充電汽車   日產魔方電動車採用了可在供電線圈和受電線圈之間提供電力的電磁感應方式。即將一個受電線圈裝置安裝在汽車的底盤上，將另一個供電線圈裝置安裝在地面，當電動汽車駛到供電線圈裝置上，受電線圈即可接受到供電線圈的電流，從而對電池進行充電。目前，這套裝置的額定輸出功率為 10kW，一般的電動汽車可在7-8小時內完成充電。 　　 日本無線充電式混合動力巴士：電磁感應式，供電線圈是埋入充電台的混凝土中的。車開上充電台後，當車載線圈對準供電線圈後(重合)，車內的儀錶板上有一個指示燈會亮，司機按一下充電按鈕，就開始充電。 　　
三、中興：無線供電系統   中興通訊的無線供電系統是通過非接觸的電磁感應方式進行電力傳輸。當充電車輛在充電停車位停泊後，就能自動通過無線接入充電場的通信網路，建立起地面系統和車載系統的通信鏈路，並完成車輛鑒權和其他相關資訊交換。   充電位元也可以通過有線或者無線的方式和雲服務中心進行互聯。一旦出現充電和受電的任何隱患，地面充電模組將立即停止充電並報警，確保充電過程安全可靠。最重要的是，無線充電系統在車輛運行時完全不工作，即使車輛在上面駛過，或者在雷雨等惡劣天氣情況下，也能確保安全。  
四、比亞迪：WAVE無線充電墊   比亞迪早在2005年12月就申請了非接觸感應式充電器專利。在2014年7月賣給猶他大學一輛40英尺的純電動巴士，這款巴士就裝配著最新的WAVE無線充電墊。  
五、奧迪：可升降的無線充電系統   奧迪的可升降的無線充電系統最大的特點就是可讓供電線圈更靠近車輛底部的受電線圈，實現了超過90%的電力傳輸效率。這種方式能讓一些高底盤的SUV在充電時保證更好的充電效率。奧迪的無線充電技術僅需要使用者將停車位元元上安置一塊配置線圈和逆變器(AC/AC)充電板，並連接至電網，當車輛停在電板上時，充電過程會自動開啟。   這種充電的原理是充電板內的交變磁場將3.3千瓦的交變電流感應至集成在車內次級線圈的空氣層中，實現電網電流逆向並輸入到車輛的充電系統中。當電池組充滿電時，充電將自動中止。感應式無線充電所需的充電時間與電纜充電所需的充電時間大致相同，且用戶可以隨時中斷充電並使用車輛。   奧迪的無線充電技術效率超過90%，不受譬如雨雪或結冰等天氣因素的影響。同時，交變磁場只有當車輛在充電板上方時才會產生，且不對人體或動物構成傷害。未來利用感應線圈的充電原理，奧迪電動汽車不僅可以在駛入車位後自動開始充電，甚至可以在設有感應線圈的公路上，一邊行駛一邊充電。  
六、特斯拉   在19世紀90年代，尼古拉•特斯拉發明瞭“特斯拉線圈”，能夠通過空氣傳播電力，開啟了無線式電力傳播的時代。在“2011年國際消費電子展”上，美國安利公司旗下子公司富爾頓創新公司展示了無線充電技術，並推出了世界上第一輛無線充電的特斯拉汽車。目前，特斯拉希望能在各個大城市中建立起一張張相互連接的充電網，以解決電動車很容易出現的電力不足問題。   （圖片來源：EEPW）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

目錄

• 1、交互實現
  • 1.1 meta標籤：自動刷新/跳轉
  • 1.2 title標籤：消息提醒
• 2、性能優化
  • 2.1 script標籤：調整加載順序提升渲染速度
  • 2.2 link標籤：通過預處理提升渲染速度
• 3、搜索優化
  • 3.1 meta標籤：提取關鍵信息
  • 3.2 link標籤：減少重複
  • 3.3 延伸內容：OGP(開放圖表協議)
• 總結

提到HTML標籤，我們會非常熟悉，開發中經常使用。但我們往往關注更多的是頁面渲染效果及交互邏輯，也就是對用戶可見可操作的部分，比如表單、菜單欄、列表、圖文等。其實還有一些非常重要卻容易忽視的標籤，這些標籤大多數用在頁面頭部head標籤內，雖然對用戶不可見，但如果在某些場景下，比如交互實現、性能優化、搜索優化，合理利用它們可以讓我們在開發中達到事半功倍的效果。

1、交互實現

在實現一個功能的時候，我們編寫的代碼越多，不僅開發成本越高，而且代碼的健壯性也越差。因此我們在開發中提倡編碼簡約原則：Less code, less bug

1.1 meta標籤：自動刷新/跳轉

meta標籤妙用場景一：假如每隔一分鐘就需要刷新頁面，這個時候就可以用到meta標籤：

<meta http-equiv="Refresh" content="60">

meta標籤妙用場景二：假如想讓某個頁面在對用戶展示一段時間后，然後跳轉到其他頁面去，也可用到meta標籤：

<meta http-equiv="Refresh" content="5; URL=page2.html">

上面這行代碼的意思是當前頁面展示5s之後，跳轉到page2.html頁面去。

1.2 title標籤：消息提醒

B/S架構有很多優點，比如版本更新方便、跨平台、跨終端，但在處理某些場景時，比如即時通信時，會變得有點麻煩。

因為前後端通信深度依賴HTTP協議，而HTTP協議採用“請求-響應”模式，這就決定了服務端也只能被動地發送數據。一種低效的解決方案是客戶端通過輪詢機制獲取最新消息（HTML5下可使用WebSocket協議）。

另外在HTML5標準發布之前，瀏覽器沒有開放圖標閃爍、彈出系統消息之類的接口，因此消息提醒功能實現比較困難。但是我們可以通過修改title標籤來達到類似的效果（HTML5下可使用Web Notifications API彈出系統消息）。

下面這段代碼，通過定時修改title標籤內容，模擬了類似消息提醒的閃爍效果：

let msgNum = 1 // 消息條數
let cnt = 0 // 計數器
const inerval = setInterval(() => {
  cnt = (cnt + 1) % 2
  if(msgNum===0) {
    // 通過DOM修改title
    document.title += `聊天頁面`
    clearInterval(interval)
    return
  }
  const prefix = cnt % 2 ? `新消息(${msgNum})` : ''
  document.title = `${prefix}聊天頁面`
}, 1000)

實現效果如下圖所示，可以看到title標籤名稱上有提示文字在閃爍。

通過模擬消息閃爍，可以讓用戶在瀏覽其他頁面的時候，及時得知服務端返回的消息。

通過定時修改title標籤內容，除了用來實現閃爍效果之外，還可以製作其他動畫效果，比如文字滾動，但需要注意瀏覽器會對title標籤文本進行去空格操作；還可以將一些關鍵信息显示到標籤上（比如下載時的進度、當前操作步驟），從而提升用戶體驗。

2、性能優化

性能優化是前端開發中避不開的問題，性能問題無外乎兩方面原因：渲染速度慢、請求時間長。性能優化雖然涉及很多複雜的原因和解決方案，但其實只要通過合理地使用標籤，就可以在一定程度上提升渲染速度，以及減少請求時間。

2.1 script標籤：調整加載順序提升渲染速度

由於瀏覽器的底層運行機制，一般情況下，渲染引擎在解析HTML時從上往下執行，若遇到script標籤引用文件，則會暫停解析過程，同時通知網絡線程加載引用文件。
文件加載完成后，再切換至JavaScript引擎來執行對應代碼，代碼執行完成之後，再切換至渲染引擎繼續渲染頁面。
即默認情況下，加載HTML的過程主要有四個步驟：

• 從上往下解析HTML;
• 碰到script標籤引用文件，暫停解析，同時通知網絡線程加載引用文件；
• 文件加載完成，切換至JavaScript引擎來執行對應代碼；
• 代碼執行完成后，再切換至渲染頁面，繼續渲染HTML。

從這一過程可以看出，頁面渲染過程包含了請求文件以及執行文件的時間，但頁面的首次渲染可能並不依賴這些文件。這些請求和執行文件的動作反而延長了用戶看到頁面的時間，從而降低了用戶體驗。

為了減少這些時間損耗，可以藉助script標籤的三個屬性來實現：

• async屬性：立即請求文件，但不阻塞渲染引擎，而是文件加載完成后，再阻塞渲染引擎並立即執行文件內容。
• defer屬性：立即請求文件，但不阻塞渲染引擎，等到解析完HTML之後再執行文件內容。
• HTML5標準type屬性，對應值為“module”：讓瀏覽器按照ECMA Script6標準將文件當作模塊進行解析，默認阻塞效果同defer，也可以配合async在請求完成后立即執行。

通過對比，我們看出，設置defer和type=”module”最推薦，都是在HTML渲染完成后才執行script引用的文件代碼。
效果圖比較見下面：

另外注意，當渲染引擎解析HTML遇到script標籤引入文件時，會立即進行一次渲染。

所以這也就是為什麼構建工具會把編譯好的引用JavaScript代碼的script標籤放入到body標籤底部。因為當渲染引擎執行到body底部時，會先將已解析的內容渲染出來，然後再去請求相應的JavaScript文件。

如果是內聯腳本（即不通過src屬性引用外部腳本文件直接在HTML中編寫JavaScript代碼的形式），渲染引擎則不會渲染，先執行腳本代碼再渲染頁面。

我們可以來做個試驗驗證下，第一個測試：在HTML頁面中間引用外部js文件

<!DOCTYPE html>
<html lang="en">
    <head><meta charset="UTF-8"><title>引用js腳本</title></head>
    <body>
        <br/><br/><br/><br/><br/>
        <h3>古人學問無遺力，少壯工夫老始成；</h3>
        <script type="text/javascript" src="./test.js"></script>
        <h3>紙上得來終覺淺，絕知此事要躬行。</h3>
    </body>
</html>

引用外部js腳本test.js：alert('男兒何不帶吳鈎，收取關山五十州');
效果圖：

第二個測試：在HTML頁面中間內聯js腳本

<!DOCTYPE html>
<html lang="en">
    <head><meta charset="UTF-8"><title>內聯js腳本</title></head>
    <body>
        <br/><br/><br/><br/><br/>
        <h3>古人學問無遺力，少壯工夫老始成；</h3>
        <script type="text/javascript">
            alert('男兒何不帶吳鈎，收取關山五十州');
        </script>
        <h3>紙上得來終覺淺，絕知此事要躬行。</h3>
    </body>
</html>

效果圖：

2.2 link標籤：通過預處理提升渲染速度

在大型單頁應用進行性能優化時，也許會用到按需賴加載的方式來加載對應的模塊。但是如果能合理利用link標籤的rel屬性值來進行預加載，就能進一步提升渲染速度。

• dns-prefetch：當link標籤的rel屬性值為“dns-prefetch”時，瀏覽器會對某個域名預先進行dsn解析並緩存。這樣，當瀏覽器在請求同域名資源的時候，能省去從域名查詢IP的過程，從而減少時間損耗。下圖是淘寶網設置的dns預解析。
• preconnect：讓瀏覽器在一個HTTP請求正式發給服務器前預先執行一些操作，這包括dns解析、TLS協商、TCP握手，通過消除往返延遲來為用戶節省時間。
• prefetch/preload：兩個值都是讓瀏覽器預先下載並緩存某個資源，但不同的是，prefetch可能會在瀏覽器忙時被忽略，而preload則是一定會被預先下載。
• prerender：瀏覽器不僅會加載資源，還會解析執行頁面，進行預渲染。

這幾個屬性值恰好反映了瀏覽器獲取文件的過程，它們獲取文件的流程：

1. 設置dns-prefetch, 然後判斷是否有對dns進行預解析。沒有則進行dns解析，有則執行下一步preconnect；
2. 執行preconnect, 對ddns、TLS、TCP進行預連接，然後判斷是否已經TCP連接。沒有則進行TCP連接，有則執行下一步prefetch/preload；
3. 執行prefetch/preload，加載資源文件。然後判斷資源文件是否已經預加載。沒有則進行http進行資源請求下載，有則進行下一步prerender；
4. 執行prerender, 預渲染頁面。然後判斷預渲染是否成功。沒有預渲染成功則進行渲染，預渲染成功則呈現給用戶看。

流程圖如下：

3、搜索優化

我們寫的前端代碼，除了要讓瀏覽器更好的執行，有時候也要考慮更方便其他程序（如搜索引擎）理解。合理地使用meta標籤和link標籤，恰好能讓搜索引擎更好的理解和收錄我們的頁面。

3.1 meta標籤：提取關鍵信息

通過meta標籤可以設置頁面的描述信息，從而讓搜索引擎更好的展示搜索結果。
比如在百度中搜索“拉勾”，就會發現網站的描述，這些描述信息就是通過meta標籤專門為搜索引擎設置的，目的是方便用戶預覽搜索到的結果。
為了讓搜索引擎更好的識別頁面，除了描述信息之外還可以使用關鍵字，這樣即使頁面其他地方沒有包含搜索內容，也可以被搜索到（當然搜索引擎有自己的權重和算法，如果濫用關鍵字是會被降權的，比如Google引擎會對堆砌大量相同關鍵詞的網頁進行懲罰，降低它被搜索的權重）。

當我們搜索關鍵字“垂直互聯網招聘”的時候搜索結果會显示拉勾網的信息，雖然显示的搜索內容上並沒有看到“垂直互聯網招聘”字樣，實際上因為拉勾網頁面中設置了這個關鍵字。
對應代碼如下：

<meta content="拉勾,拉勾網,拉勾招聘,拉鈎, 拉鈎網 ,互聯網招聘,拉勾互聯網招聘, 移動互聯網招聘, 垂直互聯網招聘, 微信招聘, 微博招聘, 拉勾官網, 拉勾百科,跳槽, 高薪職位, 互聯網圈子, IT招聘, 職場招聘, 獵頭招聘,O2O招聘, LBS招聘, 社交招聘, 校園招聘, 校招,社會招聘,社招" name="keywords">

3.2 link標籤：減少重複

有時候為了用戶訪問方便或者出於歷史原因，對於同一個頁面會有多個網址，又或者在某些重定向頁面，比如：https://xx.com/a.html、 https://xx.com/detail?id=abcd，那麼在這些頁面中可以設置：<link href="https://xx.com/a.html" rel="canonical">這樣可以讓搜索引擎避免花費時間抓取重複網頁。不過需要注意的是，它還有個限制條件，那就是指向的網站不允許跨域。
當然，要合併網址還有其他的方式，比如使用站點地圖，或者在http請求響應頭部添加rel=”canonical”。

3.3 延伸內容：OGP(開放圖表協議)

前面說的是HTML5標準的一些標籤和屬性，下面再延伸說一說基於meta標籤擴展屬性值實現的第三方協議—OGP(open graph protocal, 開放圖表協議)。

OGP是Facebook公司在2010年提出的，目的是通過增加文檔信息來提升社交網頁在被分享時的預覽效果。你只需要在一些分享頁面中添加一些meta標籤及屬性，支持OGP協議的社交網站就會在解析頁面時生成豐富的預覽信息，比如站點名稱、網頁作者、預覽圖片。具體預覽效果會因各個網站而有所變化。

下面是微信文章支持OGP協議的代碼，可以看到通過meta標籤屬性值聲明了：標題、網址、預覽圖片、描述信息、站點名稱、網頁類型和作者信息。

總結

本篇從交互實現、性能優化、搜索優化場景觸發，分別講解了meta標籤、title標籤、link標籤，一級script標籤在這些場景中的重要作用，希望這些內容你都能應用到工作場景中，不再只是了解，而是能夠熟練運用。
最後在思考一下：你還知道哪些“看不見”的標籤及用法？

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

特斯拉已通知部分員工，要求 4 月 29 日重返工作崗位，雖然加州超級工廠所在地的公共衛生部門還沒有公告解除和放鬆居家隔離。特斯拉要求員工提前復工是為了 5 月 3 日前準備好恢復生產。

特斯拉加州超級工廠所在地 Fremont 的公共衛生部門仍然沒有解除居家隔離，超級工廠屬於非必要生產製造工廠，僅可維持最基本營運，生產線處於停產狀態。特斯拉計劃在 5 月 4 日恢復生產，但在正式復工前主管已通知部分員工，要求 4 月 29 日到工廠報到，主要是沖壓、油漆業務員工。特斯拉沒有透露提前復工的員工數量。

Fremont 所屬 Alameda 郡新聞發言人 Ray Kelly 表示，目前居家隔離沒有任何調整，預期 5 月 3 日前公共衛生部門會說明，可能延長、放鬆或完全解除。

特斯拉加州工廠在 3 月 19 日接到政府部門通知，必須停止生產，特斯拉沒有第一時間配合政府部門調整生產線，繼續生產了 5 天，法務團隊也持續與政府部門溝通，特斯拉認為電動車生產屬於必要業務，不能因居家隔離停產，同時為員工提供必要的健康保障措施。停產前特斯拉會測量進入工廠的員工體溫，並向部分員工發放口罩。

政府部門強制要求停工後，特斯拉通知所有員工，除必要工作外，所有員工在家上班，部分無法在家工作的員工列為休假，降低員工薪水，並停止與外部承包商臨時性員工合作。

儘管員工對復工非常期待，但工廠環境和作業方式將使降低傳染變得困難。截至 4 月 26 日，Alameda 郡共報告 1,468 例武漢肺炎病例，52 例死亡，特斯拉工廠大部分員工都住在這區。

選擇在 4 月 29 日部分員工提前復工，對特斯拉意義不僅是工廠恢復營運，也是 4 月 29 日發表第一季財報的日子，投資者會很樂見工廠恢復生產。加州超級工廠生產 Model Y、Model 3、Model X、Model S 電動車，據 Credit Suisse 的分析師估計，關閉後特斯拉每週至少虧損 3 億美元。

關於汽車製造公司何時恢復營運、保障員工安全仍有許多爭議，豐田、Volkswagen、Hyundai 等汽車廠商都計劃 5 月初恢復生產，但汽車工人聯合會代表認為，過早恢復生產對員工非常危險。

（合作媒體：。首圖來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

先前消息傳出，電動車大廠特斯拉（Tesla）要求員工於 29 日返回工作崗位，以便讓加州佛利蒙（Fremont）組裝廠恢復生產。但隨著該廠所在的舊金山灣區六郡宣佈延長居家禁令，特斯拉政策急轉彎，已通知員工無需提前復工。

CNBC 報導，根據特斯拉的內部信件，24 日和週末，特斯拉管理層要求數十名員工於 29 日重返工作崗位，讓佛利蒙廠產線重啟運作。不過，由於舊金山灣區六郡（舊金山、聖克拉拉、聖馬刁、馬林、康特拉哥斯，以及佛利蒙廠所在的阿拉米達郡）27 日宣佈，將「就地避難」（shelter-in-place）令的期限由 5 月 4 日延長至 5 月底，特斯拉隨後也取消本週的復工計畫。

特斯拉人力資源部週一發送內部訊息向員工表示：「按照執行領導團隊的指示，我們將不會在 4 月 29 日星期三恢復工作。請忽略關於本週復工的所有訊息和指示。」

報導指出，特斯拉佛利蒙廠生產 Model S 和 Model X 車型，以及較新的 Model 3 和 Model Y 車型，銷往北美和歐洲市場。位於中國上海的組裝廠，先前也因疫情短暫關閉約兩週，但在當地政府的協助下迅速恢復運作，目前每週營運 6 天。

在佛利蒙廠有望提前復工的利多消息帶動下，27 日特斯拉股價大漲 10.15% 收 798.75 美元，但取消復工的消息公佈後，盤後股價挫跌 2.10% 至 782.00 美元。今年以來，特斯拉股價累計飆漲 90.98%。

《華爾街日報》先前報導，根據特斯拉 4 月 2 日資料，2020 年第一季交車數達 88,400 輛，較去年同期成長 40%，雖然疫情導致整體車市市況不振，但特斯拉仍維持原先銷售目標。

今年初，特斯拉執行長馬斯克（Elon Musk）預估，特斯拉今年電動車銷量將維持強勁成長，比去年至少成長 36%，全球總交車數可望「輕鬆突破」（comfortably exceed）50 萬輛。

特斯拉預計 29 日發表 2020 年第一季財報。

（本文內文由  授權使用；首圖來源： CC BY 2.0）

延伸閱讀：

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

※別再煩惱如何寫文案,掌握八大原則!

一、前言

從 18 年開始接觸 .NET Core 開始，在私底下、工作中也開始慢慢從傳統的 mvc 前後端一把梭，開始轉向 web api + vue，之前自己有個半成品的 asp.net core 2.2 的項目模板，最近幾個月的時間，私下除了學習 Angular 也在對這個模板基於 asp.net core 3.1 進行慢慢補齊功能

因為涉及到底層框架大版本升級，由於某些 breaking changes 必定會造成之前的某些寫法沒辦法繼續使用，趁着端午節假期，在改造模板時，發現沒辦法通過構造函數注入的形式在 Startup 文件中注入某些我需要的服務了，因此本篇文章主要介紹如何在 asp.net core 3.x 的 startup 文件中獲取注入的服務

二、Step by Step

2.1、問題案例

這個問題的發現源於我需要改造模型驗證失敗時返回的錯誤信息，如果你有嘗試的話，在 3.x 版本中你會發現在 Startup 類中，我們沒辦法通過構造函數注入的方式再注入任何其它的服務了，這裏僅以我的代碼中需要解決的這個問題作為案例

在定義接口時，為了降低後期調整的複雜度，在接收參數時，一般會將參數包裝成一個 dto 對象（data transfer object – 數據傳輸對象），不管是提交數據，還是查詢數據，對於這個 dto 中的某些屬性，都會存在一定的卡控，例如 xxx 字段不能為空了，xxx 字段的長度不能超過 30

而在 asp.net core 中，因為會自動進行模型驗證，當不符合 dto 中的屬性要求時，接口會自動返回錯誤信息，默認的返回信息如下圖所示

可以看到，因為這裏其實是按照 rfc7231這個 RFC 協議返回的錯誤信息，這個並不符合我的要求，因此這裏我需要改寫這個返回的錯誤信息

自定義 asp.net core 的模型驗證錯誤信息方法有很多種，我的實現方法如下，因為我需要記錄請求的標識 Id 和錯誤日誌，所以這裏我需要將 ILogger 和 IHttpContextAccessor 注入到 Startup 類中

/// <summary>
/// 修改模型驗證錯誤返回信息
/// </summary>
/// <param name="services">服務容器集合</param>
/// <param name="logger">日誌記錄實例</param>
/// <param name="httpContextAccessor"></param>
/// <returns></returns>
public static IServiceCollection AddCustomInvalidModelState(this IServiceCollection services,
    ILogger<Startup> logger, IHttpContextAccessor httpContextAccessor)
{
    services.Configure<ApiBehaviorOptions>(options =>
    {
        options.InvalidModelStateResponseFactory = actionContext =>
        {
            // 獲取驗證不通過的字段信息
            //
            var errors = actionContext.ModelState.Where(e => e.Value.Errors.Count > 0)
                .Select(e => new ApiErrorDto
                {
                    Title = "請求參數不符合字段格式要求",
                    Message = e.Value.Errors.FirstOrDefault()?.ErrorMessage
                }).ToList();

            var result = new ApiReturnDto<object>
            {
                TraceId = httpContextAccessor.HttpContext.TraceIdentifier,
                Status = false,
                Error = errors
            };

            logger.LogError($"接口請求參數格式錯誤: {JsonConvert.SerializeObject(result)}");

            return new BadRequestObjectResult(result);
        };
    });

    return services;
}

在 asp.net core 2.x 版本中，你完全可以像在別的類中採用構造函數注入的方式一樣直接注入使用

public class Startup
{
    /// <summary>
    /// 日誌記錄實例
    /// </summary>
    private readonly ILogger<Startup> _logger;

    /// <summary>
    /// Http 請求實例
    /// </summary>
    private readonly IHttpContextAccessor _httpContextAccessor;

    /// <summary>
    /// ctor
    /// </summary>
    /// <param name="configuration"></param>
    /// <param name="logger"></param>
    /// <param name="httpContextAccessor"></param>
    public Startup(IConfiguration configuration, ILogger<Startup> logger, IHttpContextAccessor httpContextAccessor)
    {
        Configuration = configuration ?? throw new ArgumentNullException(nameof(configuration));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
        _httpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
    }

    /// <summary>
    /// 配置實例
    /// </summary>
    public IConfiguration Configuration { get; }

    /// <summary>
    /// This method gets called by the runtime. Use this method to add services to the container.
    /// </summary>
    public void ConfigureServices(IServiceCollection services)
    {
        //注入的其它服務

        // 返回自定義的模型驗證錯誤信息
        services.AddCustomInvalidModelState(_logger, _httpContextAccessor);
    }
}

但是當你直接遷移到 asp.net core 3.x 版本后，你會發現程序會報如下的錯誤，很常見的一個依賴注入的錯誤，源頭直指我們通過構造函數注入的 ILogger、IHttpContextAccessor 接口

2.2、解決方法

根本原因

通過查閱 stackoverflow 發現了這樣的一個問題：How do I write logs from within Startup.cs，在最高贊的回答中提到了在泛型主機（GenericHostBuilder）中，沒辦法注入除 IConfiguration 之外的任何服務到 Startup類中，而泛型主機則是在 asp.net core 3.0 中添加的功能

查了下升級日誌，從中可以看到，在泛型主機中， Startup 類的構造函數注入只支持 IHostEnvironment、 IWebHostEnvironment、IConfiguration ，嗯，不好好看別人文檔的鍋

為什麼使用 WebHostBuilder可以，換成 GenericHostBuilder 就不行了呢

按照正常的邏輯來說，對於一個 asp.net core 應用，原則上來說只有有一個根級（root）的依賴注入容器，但是因為我們在 Startup 類中通過構造函數注入的形式注入服務時，告訴程序了我需要這個服務的實例，從而導致在構建 WebHost 時存在了一個單獨的容器，並且這個容器只包含了我們需要使用到的服務信息，之後，因為會創建了一個包含完整服務的依賴注入容器，這裏就會存在一個服務哪怕是單例的也可能會存在註冊兩次的問題，這無疑有些不太合乎規範

在推行泛型主機之後，嚴格控制了只會存在一個依賴注入容器，而所有的服務都是在 Startup.ConfigureServices 方法執行完成后才會註冊到依賴注入容器中，因此沒辦法像之前一樣在根容器註冊完成之前通過構造函數注入的形式使用

解決方案

如果你需要在 Startup.Configure 方法中使用自定義的服務，因為這裏已經完成了各種服務的註冊，和之前一樣，我們直接在方法簽名中包含需要使用到的服務即可

public void Configure(IApplicationBuilder app, IHostEnvironment env, ILogger<Startup> logger)
{
    logger.LogInformation("在 Configure 中使用自定義的服務");
}

如果你需要在 Startup.ConfigureServices 中使用的話，則需要換一種方法

最簡單的方法，直接替換泛型主機為原來的 WebHostBuilder，這樣就可以直接在 Startup 類中注入各種服務接口了，不過，考慮到這一改動其實是在開倒車，所以這裏不推薦採用這種方法

既然沒辦法正向通過依賴注入容器來自動創建我們需要的服務實例，是不是可以通過服務容器，手動去獲取我們需要的服務，也就是被稱為服務定位（Service Locator）的方式來獲取實例

當然，這似乎與依賴注入的思想相左，對於依賴注入來說，我們將所有需要使用的服務定義好，在應用啟動前完成註冊，之後在使用時由依賴注入容器提供服務的實例即可，而服務定位則是我們已經知道存在這個服務了，從容器中獲取出來然後由自己手動的創建實例

雖然服務定位是一種反模式，但是在某些情況下，我們又不得不採用

這裏對於本篇文章開篇中需要解決的問題，我也是採用服務定位的方式，通過構建一個 ServiceProvider 之後，手動的從容器中獲取需要使用的服務實例，調整后的代碼如下

/// <summary>
/// 添加自定義模型驗證失敗時返回的錯誤信息
/// </summary>
/// <param name="services">服務容器集合</param>
/// <returns></returns>
public static IServiceCollection AddCustomInvalidModelState(this IServiceCollection services)
{
    // 構建一個服務的提供程序
    var provider = services.BuildServiceProvider();

    // 獲取需要使用的服務實例
    //
    var logger = provider.GetRequiredService<ILogger<Startup>>();
    var httpContextAccessor = provider.GetRequiredService<IHttpContextAccessor>();

    services.Configure<ApiBehaviorOptions>(options =>
    {
        options.InvalidModelStateResponseFactory = actionContext =>
        {
            // 獲取失敗信息
            //
            var errors = actionContext.ModelState.Where(e => e.Value.Errors.Count > 0)
                .Select(e => new ApiErrorMessageDto
                {
                    Title = "Request parameters do not meet the field requirements",
                    Message = e.Value.Errors.FirstOrDefault()?.ErrorMessage
                }).ToList();

            var result = new ApiResponseDto<object>
            {
                TraceId = httpContextAccessor.HttpContext.TraceIdentifier,
                Status = false,
                Error = errors
            };

            logger.LogError($"接口請求參數格式錯誤: {JsonSerializer.Serialize(result)}");

            return new BadRequestObjectResult(result);
        };
    });

    return services;
}

對於配置一些需要基於某些服務的服務，這裏也可以通過委託的形式獲取到需要使用的服務實例，示例代碼如下

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IMyService>((container) =>
    {
        var logger = container.GetRequiredService<ILogger<MyService>>();
        return new MyService
        {
            Logger = logger
        };
    });
}

三、參考資料

• ASP.NET Core 3.0 的新增功能

• Generic Host restricts Startup constructor injection

• 依賴注入模式

• Avoiding Startup service injection in ASP.NET Core 3

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

在分佈式系統中，負載均衡是必不可少的一個模塊，dubbo 中提供了五種負載均衡的實現，在閱讀這塊源碼之前，建議先學習負載均衡的基礎知識。把看源碼當做一個印證自己心中所想的過程，這樣會得到事半功倍的效果

以下源碼分析基於 dubbo 2.77 版本

類結構

先來看一下這一塊的類結構圖

大部分算法都是在權重比的基礎上進行負載均衡，RandomLoadBalance 是默認的算法

類型	描述	是否默認	是否加權
RandomLoadBalance	隨機	是	是，默認權重相同
RoundRobinLoadBalance	輪訓	否	是，默認權重相同
LeastActiveLoadBalance	最少活躍數調用	否	不完全是，默認權重相同，僅在活躍數相同時按照權重比隨機
ConsistentHashLoadBalance	一致性hash	否	否
ShortestResponseLoadBalance	最短時間調用	否	不完全是，默認權重相同，僅在預估調用相同時按照權重比隨機

AbstractLoadBalance

AbstractLoadBalance 對一些通用的操作做了處理，是一個典型的模板方法模式的實現

select 方法只做一些簡單的範圍校驗，具體的實現有子類通過 doSelect 方法去實現

    @Override
    public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        if (CollectionUtils.isEmpty(invokers)) {
            return null;
        }
        if (invokers.size() == 1) {
            return invokers.get(0);
        }
        return doSelect(invokers, url, invocation);
    }

getWeight方法封裝了獲取一個調用者的權重值的方法，並加入了預熱處理

    int getWeight(Invoker<?> invoker, Invocation invocation) {
        int weight;
        URL url = invoker.getUrl();
        // Multiple registry scenario, load balance among multiple registries.
        // 註冊中心不需要預熱
        if (REGISTRY_SERVICE_REFERENCE_PATH.equals(url.getServiceInterface())) {
            weight = url.getParameter(REGISTRY_KEY + "." + WEIGHT_KEY, DEFAULT_WEIGHT);
        } else {
            // 獲取配置的權重值
            weight = url.getMethodParameter(invocation.getMethodName(), WEIGHT_KEY, DEFAULT_WEIGHT);
            if (weight > 0) {
                // 獲取服務提供者啟動時的時間戳
                long timestamp = invoker.getUrl().getParameter(TIMESTAMP_KEY, 0L);
                if (timestamp > 0L) {
                    //  獲取啟動時長
                    long uptime = System.currentTimeMillis() - timestamp;
                    // 當前時間小於服務提供者啟動時間，直接給一個最小權重1
                    if (uptime < 0) {
                        return 1;
                    }
                    // 獲取預熱時間
                    int warmup = invoker.getUrl().getParameter(WARMUP_KEY, DEFAULT_WARMUP);
                    // 如果小於預熱時間，計算權重
                    if (uptime > 0 && uptime < warmup) {
                        weight = calculateWarmupWeight((int)uptime, warmup, weight);
                    }
                }
            }
        }
        // 取與零比較的最大值，保證不會出現負值權重
        return Math.max(weight, 0);
    }

calculateWarmupWeight 方法用來計算權重，保證隨着預熱時間的增加，權重逐漸達到設置的權重

    static int calculateWarmupWeight(int uptime, int warmup, int weight) {
        // 運行時間/(預熱時間/權重)
        int ww = (int) ( uptime / ((float) warmup / weight));
        // 保證計算的權重最小值是1，並且不能超過設置的權重
        return ww < 1 ? 1 : (Math.min(ww, weight));
    }

RandomLoadBalance

隨機調用是負載均衡算法中最常用的算法之一，也是 dubbo 的默認負載均衡算法，實現起來也較為簡單
隨機調用的缺點是在調用量比較少的情況下，有可能出現不均勻的情況

	@Override
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        // Number of invokers
        int length = invokers.size();
        // Every invoker has the same weight?
        boolean sameWeight = true;
        // the weight of every invokers
        int[] weights = new int[length];
        // the first invoker's weight
        int firstWeight = getWeight(invokers.get(0), invocation);
        weights[0] = firstWeight;
        // The sum of weights
        int totalWeight = firstWeight;
        for (int i = 1; i < length; i++) {
            int weight = getWeight(invokers.get(i), invocation);
            // save for later use
            // 依次把權重放到數組對應的位置
            weights[i] = weight;
            // Sum
            // 累加權重
            totalWeight += weight;
            // 如果出現權重不一樣的，sameWeight 設為false
            if (sameWeight && weight != firstWeight) {
                sameWeight = false;
            }
        }
        if (totalWeight > 0 && !sameWeight) {
            // If (not every invoker has the same weight & at least one invoker's weight>0), select randomly based on totalWeight.
            // 在總權重裏面隨機選擇一個偏移量
            int offset = ThreadLocalRandom.current().nextInt(totalWeight);
            // Return a invoker based on the random value.
            for (int i = 0; i < length; i++) {
                offset -= weights[i];
                // 依次用偏移量減去當前權重，小於0說明選中
                if (offset < 0) {
                    return invokers.get(i);
                }
            }
        }
        // If all invokers have the same weight value or totalWeight=0, return evenly.
        // 如果所有的調用者有同樣的權重或者總權重為0，則隨機選擇一個
        return invokers.get(ThreadLocalRandom.current().nextInt(length));
    }

RoundRobinLoadBalance

輪訓算法避免了隨機算法在小數據量產生的不均勻問題，我個人認為，輪訓算法可以理解為隨機算法的一種特例，在大量請求的情況下，從調用次數看，和隨機並無區別，主要區別在於短時間內的調用分配上

加權輪訓算法給人的直觀感受，實現起來並不複雜，算出一權重總量，依次調用即可
例如A，B，C 三個節點的權重比依次 1，200，1000，如果依次輪訓調用，就會出現先調用A 10 次，再調用B 200次，最後調用 C 1000次，不斷重複前面的過程
但這樣有一個問題，我們可以發現C 被練習調用1000次，會對C瞬間造成很大的壓力

dubbo的新版本採用的是平滑加權輪詢算法，輪訓的過程中節點之間穿插調用，可以避免了上面說的問題，因此這塊源碼看起來會稍有難度

輪訓算法 在dubbo 在升級的過程中，做過多次優化，有興趣的可以去了解下該算法的優化過程，也是件很有意思的事情

public class RoundRobinLoadBalance extends AbstractLoadBalance {
    public static final String NAME = "roundrobin";

    private static final int RECYCLE_PERIOD = 60000;

    protected static class WeightedRoundRobin {
        // 權重值
        private int weight;
        // 當前權重值
        private AtomicLong current = new AtomicLong(0);
        // 最後一次使用該對象時間
        private long lastUpdate;

        public int getWeight() {
            return weight;
        }

        public void setWeight(int weight) {
            this.weight = weight;
            current.set(0);
        }

        // 獲取自增權重基數的當前權重值
        public long increaseCurrent() {
            return current.addAndGet(weight);
        }

        public void sel(int total) {
            current.addAndGet(-1 * total);
        }

        public long getLastUpdate() {
            return lastUpdate;
        }

        // 設置最後一次更新時間戳
        public void setLastUpdate(long lastUpdate) {
            this.lastUpdate = lastUpdate;
        }
    }

    private ConcurrentMap<String, ConcurrentMap<String, WeightedRoundRobin>> methodWeightMap = new ConcurrentHashMap<String, ConcurrentMap<String, WeightedRoundRobin>>();

    /**
     * get invoker addr list cached for specified invocation
     * <p>
     * <b>for unit test only</b>
     *
     * @param invokers
     * @param invocation
     * @return
     */
    protected <T> Collection<String> getInvokerAddrList(List<Invoker<T>> invokers, Invocation invocation) {
        String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
        Map<String, WeightedRoundRobin> map = methodWeightMap.get(key);
        if (map != null) {
            return map.keySet();
        }
        return null;
    }

    @Override
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        // {group}/{interfaceName}:{version} + methoName 獲取當前消費者的唯一標示
        String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
        // 獲取對應的 WeightedRoundRobin map,如果不存在，new 一個map放進去
        ConcurrentMap<String, WeightedRoundRobin> map = methodWeightMap.computeIfAbsent(key, k -> new ConcurrentHashMap<>());
        int totalWeight = 0;
        long maxCurrent = Long.MIN_VALUE;
        long now = System.currentTimeMillis();
        Invoker<T> selectedInvoker = null;
        WeightedRoundRobin selectedWRR = null;
        for (Invoker<T> invoker : invokers) {
            // 服務提供者在的唯一標識
            String identifyString = invoker.getUrl().toIdentityString();
            int weight = getWeight(invoker, invocation);
            WeightedRoundRobin weightedRoundRobin = map.computeIfAbsent(identifyString, k -> {
                WeightedRoundRobin wrr = new WeightedRoundRobin();
                wrr.setWeight(weight);
                return wrr;
            });
            // 如果權重改變了，更新 weightedRoundRobin 裏面權重的值
            if (weight != weightedRoundRobin.getWeight()) {
                //weight changed
                weightedRoundRobin.setWeight(weight);
            }
            // 當前權重自增自身權重
            long cur = weightedRoundRobin.increaseCurrent();
            // 設置最後一次更新時間戳
            weightedRoundRobin.setLastUpdate(now);
            // 如果當前權重大於最大當前權重
            if (cur > maxCurrent) {
                // 重置最大當前權重的值
                maxCurrent = cur;
                // 把當前提供者設為選中的提供者
                selectedInvoker = invoker;
                // 把當前輪訓權重實例設為選中
                selectedWRR = weightedRoundRobin;
            }
            // 累計總權重
            totalWeight += weight;
        }
        // 提供者有變化
        if (invokers.size() != map.size()) {
            // 超過60s沒有使用，刪除掉
            map.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > RECYCLE_PERIOD);
        }
        if (selectedInvoker != null) {
            // 減去總權重
            // 關於這個地方為什麼要減去總權重，是一個很容易造成迷惑的地方
            // 我的理解：每一次調用循環 每個提供者的 當前權重 都會自增自己的權重
            // 因此在選中后（只有一個被選中），再減去總權重，正好保證了所有 WeightedRoundRobin 中當前權重之和永遠等於0
            selectedWRR.sel(totalWeight);
            return selectedInvoker;
        }
        // 理論上不會走到這個地方
        // should not happen here
        return invokers.get(0);
    }

}

LeastActiveLoadBalance

最少活躍數調用算法是指在調用時判斷此時每個服務提供者此時正在處理的請求個數，選取最小的調用

dubbo 在實現該算法時的具體邏輯如下

1. 選取所有活躍數最少的提供者
2. 如果只有一個，直接返回
3. 如果權重不同，加權隨機選擇一個
4. 如果權重相同，隨機選擇一個

    @Override
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        // Number of invokers
        int length = invokers.size();
        // The least active value of all invokers
        // 最少活躍數量
        int leastActive = -1;
        // The number of invokers having the same least active value (leastActive)
        // 有同樣活躍值的提供者數量
        int leastCount = 0;
        // The index of invokers having the same least active value (leastActive)
        int[] leastIndexes = new int[length];
        // the weight of every invokers
        // 每一個提供者的權重
        int[] weights = new int[length];
        // The sum of the warmup weights of all the least active invokers
        // 最少活躍提供者的總權重
        int totalWeight = 0;
        // The weight of the first least active invoker
        int firstWeight = 0;
        // Every least active invoker has the same weight value?
        // 所有的最少活躍提供者是否擁有同樣的權重值
        boolean sameWeight = true;


        // Filter out all the least active invokers
        for (int i = 0; i < length; i++) {
            Invoker<T> invoker = invokers.get(i);
            // Get the active number of the invoker
            // 活躍數量
            int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
            // Get the weight of the invoker's configuration. The default value is 100.
            // 獲取權重值
            int afterWarmup = getWeight(invoker, invocation);
            // save for later use
            // 保存權重留着後面用
            weights[i] = afterWarmup;
            // If it is the first invoker or the active number of the invoker is less than the current least active number
            // 如果是第一個提供者，或者當前活躍數量比最少的少
            if (leastActive == -1 || active < leastActive) {
                // Reset the active number of the current invoker to the least active number
                // 重置最少活躍數量
                leastActive = active;
                // Reset the number of least active invokers
                // 重置最少活躍提供者的數量
                leastCount = 1;
                // Put the first least active invoker first in leastIndexes
                // 把最少活躍提供者的索引保存起來
                leastIndexes[0] = i;
                // Reset totalWeight
                // 重置總權重
                totalWeight = afterWarmup;
                // Record the weight the first least active invoker
                // 記錄第一個最少活躍提供者的權重
                firstWeight = afterWarmup;
                // Each invoke has the same weight (only one invoker here)
                // 每個最少活躍提供者是否有同樣的權重？？？
                sameWeight = true;
                // If current invoker's active value equals with leaseActive, then accumulating.
                // 如果當前活躍數量等於最少活躍數量
            } else if (active == leastActive) {
                // Record the index of the least active invoker in leastIndexes order
                // 最少活躍提供者的索引依次放入 leastIndexes
                leastIndexes[leastCount++] = i;
                // Accumulate the total weight of the least active invoker
                // 累計最少活躍提供者的總權重
                totalWeight += afterWarmup;
                // If every invoker has the same weight?
                // 如果當前權重和第一個最少活躍的權重不同，sameWeight 設為false
                if (sameWeight && afterWarmup != firstWeight) {
                    sameWeight = false;
                }
            }
        }
        // Choose an invoker from all the least active invokers
        // 最少活躍提供者只有一個，直接返回
        if (leastCount == 1) {
            // If we got exactly one invoker having the least active value, return this invoker directly.
            return invokers.get(leastIndexes[0]);
        }
        // 如擁有不同的權重，在權重的基礎上隨機選取一個，可以參考 RandomLoadBalance，有同樣的寫法
        if (!sameWeight && totalWeight > 0) {
            // If (not every invoker has the same weight & at least one invoker's weight>0), select randomly based on 
            // totalWeight.
            int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
            // Return a invoker based on the random value.
            for (int i = 0; i < leastCount; i++) {
                int leastIndex = leastIndexes[i];
                offsetWeight -= weights[leastIndex];
                if (offsetWeight < 0) {
                    return invokers.get(leastIndex);
                }
            }
        }
        // 權重相同，隨機選取一個
        // If all invokers have the same weight value or totalWeight=0, return evenly.
        return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
    }

ShortestResponseLoadBalance

最短時間調用調用算法是指預估出來每個處理完請求的提供者所需時間，然後又選擇最少最短時間的提供者進行調用，整體處理邏輯和最少活躍數算法基本相似

dubbo 在實現該算法時的具體邏輯如下

1. 選取所有預估處理時間最短的提供者
2. 如果只有一個，直接返回
3. 如果權重不同，加權隨機選擇一個
4. 如果權重相同，隨機選擇一個

    @Override
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        // Number of invokers
        int length = invokers.size();
        // Estimated shortest response time of all invokers
        // 最少響應時間
        long shortestResponse = Long.MAX_VALUE;
        // The number of invokers having the same estimated shortest response time
        // 最少響應時間的提供者數量
        int shortestCount = 0;
        // The index of invokers having the same estimated shortest response time
        int[] shortestIndexes = new int[length];
        // the weight of every invokers
        int[] weights = new int[length];
        // The sum of the warmup weights of all the shortest response  invokers
        // 最少響應時間的提供者的總權重
        int totalWeight = 0;
        // The weight of the first shortest response invokers
        // 第一個最少響應時間的權重
        int firstWeight = 0;
        // Every shortest response invoker has the same weight value?
        // 所有的最少響應時間提供者是否擁有同樣的權重值
        boolean sameWeight = true;

        // Filter out all the shortest response invokers
        for (int i = 0; i < length; i++) {
            Invoker<T> invoker = invokers.get(i);
            RpcStatus rpcStatus = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
            // Calculate the estimated response time from the product of active connections and succeeded average elapsed time.
            //  平均響應成功時間
            long succeededAverageElapsed = rpcStatus.getSucceededAverageElapsed();
            // 活躍的連接連接數量
            int active = rpcStatus.getActive();
            // 預估響應時間
            long estimateResponse = succeededAverageElapsed * active;
            // 獲取權重值
            int afterWarmup = getWeight(invoker, invocation);
            // 保存權重留着後面用
            weights[i] = afterWarmup;
            // Same as LeastActiveLoadBalance
            // 如果預估時間小於最少的響應時間
            if (estimateResponse < shortestResponse) {
                // 重置最少響應時間
                shortestResponse = estimateResponse;
                // 最少響應時間的提供者數量設為1
                shortestCount = 1;
                // 保存提供者下標
                shortestIndexes[0] = i;
                // 重置最少響應時間的提供者的總權重
                totalWeight = afterWarmup;
                // 重置第一個最少響應時間的權重
                firstWeight = afterWarmup;
                sameWeight = true;
                // 如果當前最少響應時間等於最少響應時間
            } else if (estimateResponse == shortestResponse) {
                // 最少最少響應時間的下標依次放入 shortestIndexes
                shortestIndexes[shortestCount++] = i;
                // 累計最少響應時間的總權重
                totalWeight += afterWarmup;
                // 如果當前權重和第一個最少響應時間的權重不同，sameWeight 設為false
                if (sameWeight && i > 0
                        && afterWarmup != firstWeight) {
                    sameWeight = false;
                }
            }
        }
        // 最少最少響應時間只有一個，直接返回
        if (shortestCount == 1) {
            return invokers.get(shortestIndexes[0]);
        }
        // 如擁有不同的權重，在權重的基礎上隨機選取一個，可以參考 RandomLoadBalance，有同樣的寫法
        if (!sameWeight && totalWeight > 0) {
            int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
            for (int i = 0; i < shortestCount; i++) {
                int shortestIndex = shortestIndexes[i];
                offsetWeight -= weights[shortestIndex];
                if (offsetWeight < 0) {
                    return invokers.get(shortestIndex);
                }
            }
        }
        // 權重相同，隨機選取一個
        return invokers.get(shortestIndexes[ThreadLocalRandom.current().nextInt(shortestCount)]);
    }

ConsistentHashLoadBalance

一致性hash算法是一種廣泛應用與分佈式緩存中的算法，該算法的優勢在於新增和刪除節點后，只有少量請求發生變動，大部分請求仍舊映射到原來的節點
為了防止節點過少，造成節點分佈不均勻，一般採用虛擬節點的方式，dubbo默認的是160個虛擬節點

網上關於一致性hash算法的文章有很多，這裏就不再多贅述，以下是dubbo中的實現，需要說明的是， 一致性hash算法中權重配置不起作用

    @Override
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        String methodName = RpcUtils.getMethodName(invocation);
        // {group}/{interfaceName}:{version} + methoName 獲取當前消費者的唯一標示
        String key = invokers.get(0).getUrl().getServiceKey() + "." + methodName;
        // using the hashcode of list to compute the hash only pay attention to the elements in the list
        int invokersHashCode = invokers.hashCode();
        // 獲取當前消費者的一致性hash選擇器
        ConsistentHashSelector<T> selector = (ConsistentHashSelector<T>) selectors.get(key);
        // 如果 selector 還沒初始化，或者 invokers 已經變化，重新初始化 selector
        if (selector == null || selector.identityHashCode != invokersHashCode) {
            selectors.put(key, new ConsistentHashSelector<T>(invokers, methodName, invokersHashCode));
            selector = (ConsistentHashSelector<T>) selectors.get(key);
        }
        return selector.select(invocation);
    }
    // 一致性hash選擇器
    private static final class ConsistentHashSelector<T> {

        // 存儲hash環的數據結構 節點 -> 提供者
        private final TreeMap<Long, Invoker<T>> virtualInvokers;

        // 虛擬節點數量
        private final int replicaNumber;

        // 用來標示所有提供者是唯一標示
        private final int identityHashCode;
        // 用來存儲計算hash值參數下標的數組，例如計算第一個和第三個參數 該數組為[0,2]
        private final int[] argumentIndex;

        ConsistentHashSelector(List<Invoker<T>> invokers, String methodName, int identityHashCode) {
            this.virtualInvokers = new TreeMap<Long, Invoker<T>>();
            this.identityHashCode = identityHashCode;
            URL url = invokers.get(0).getUrl();
            // 虛擬節點數量，默認 160
            this.replicaNumber = url.getMethodParameter(methodName, HASH_NODES, 160);
            // 默認只對第一個參數進行hash
            String[] index = COMMA_SPLIT_PATTERN.split(url.getMethodParameter(methodName, HASH_ARGUMENTS, "0"));
            argumentIndex = new int[index.length];
            for (int i = 0; i < index.length; i++) {
                argumentIndex[i] = Integer.parseInt(index[i]);
            }
            for (Invoker<T> invoker : invokers) {
                String address = invoker.getUrl().getAddress();
                // 關於這個地方為什麼要除以4，我理解的是md5後為16字節的數組，計算hash值只需要用到四個字節，所以可以用四次
                // 因此除以4，算是一個性能優化點
                for (int i = 0; i < replicaNumber / 4; i++) {
                    // md5, 獲得一個長度為16的字節數組
                    byte[] digest = md5(address + i);
                    for (int h = 0; h < 4; h++) {
                        // 如果h=0，則用第0,1,2,3四個字節進行位運算，得出一個0-2^32-1的值
                        // 如果h=1，則用第4,5,6,7四個字節進行位運算，得出一個0-2^32-1的值
                        // 如果h=2，則用第8,9,10,11四個字節進行位運算，得出一個0-2^32-1的值
                        // 如果h=3，則用第12,13,14,15四個字節進行位運算，得出一個0-2^32-1的值
                        long m = hash(digest, h);
                        virtualInvokers.put(m, invoker);
                    }
                }
            }
        }

        public Invoker<T> select(Invocation invocation) {
            String key = toKey(invocation.getArguments());
            byte[] digest = md5(key);
            return selectForKey(hash(digest, 0));
        }
        // 根據配置生成計算hash值的key
        private String toKey(Object[] args) {
            StringBuilder buf = new StringBuilder();
            for (int i : argumentIndex) {
                if (i >= 0 && i < args.length) {
                    buf.append(args[i]);
                }
            }
            return buf.toString();
        }

        private Invoker<T> selectForKey(long hash) {
            // 找到hash值在hash環上的位置
            // ceilingEntry 方法返回大於或者等於當前key的鍵值對
            Map.Entry<Long, Invoker<T>> entry = virtualInvokers.ceilingEntry(hash);
            // 如果返回為空，說明落在了hash環中2的32次方-1的最後，直接返回第一個
            if (entry == null) {
                entry = virtualInvokers.firstEntry();
            }
            return entry.getValue();
        }
        // 得出一個0-2^32-1的值， 四個字節組成一個長度為32位的二進制数字並轉化為long值
        private long hash(byte[] digest, int number) {
            return (((long) (digest[3 + number * 4] & 0xFF) << 24)
                    | ((long) (digest[2 + number * 4] & 0xFF) << 16)
                    | ((long) (digest[1 + number * 4] & 0xFF) << 8)
                    | (digest[number * 4] & 0xFF))
                    & 0xFFFFFFFFL;
        }

        private byte[] md5(String value) {
            MessageDigest md5;
            try {
                md5 = MessageDigest.getInstance("MD5");
            } catch (NoSuchAlgorithmException e) {
                throw new IllegalStateException(e.getMessage(), e);
            }
            md5.reset();
            byte[] bytes = value.getBytes(StandardCharsets.UTF_8);
            md5.update(bytes);
            return md5.digest();
        }

    }

總結

以上就是dubbo負載均衡源碼的全部解析，如果還是不明白，可以看下官方文檔的解析  
http://dubbo.apache.org/zh-cn/docs/source_code_guide/loadbalance.html

dubbo的負載均衡算法總體來說並不複雜，代碼寫的也很優雅，簡潔，看起來很舒服，而且有很多細節的處理值得稱讚，例如預熱處理，輪訓算法的平滑處理等。

我們平時使用時，可以根據自己的業務場景，選擇適合自己的算法，當然，一般情況下，默認的的隨機算法就能滿足我們的日常需求，而且隨機算法的性能足夠好。

如果覺得dubbo提供的五種算法都不能滿足自己的需求，還可以通過dubbo的SPI機制很方便的擴展自己的負載均衡算法。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

摘要：本文針對“數據牽引改進，工具固化規範”這一思路在業務團隊落地過程中的動作流程進行詳細闡述，並明確了支撐整個流程的關鍵角色定義和組織運作形式。

目的

為實現雲服務開發的過程可信，需要基於數據對各個服務產品部的可信變革動作進行數據採集、進展可視、目標牽引、能力評估，最終用數據反映目標達成。與傳統的“基於數據晾曬驅動業務團隊改進，6+1指標度量”的運作方式有本質的區別，我們是基於統一的作業工具上產生的客觀數據呈現，識別研發過程中基本的流程斷裂點和質量缺失動作，和業務團隊達成一致的目標后，把大部分改進動作固話到作業工具中自動化承載，我們稱這個思路為“數據牽引改進，工具固化規範”，也就是我們不僅告訴業務團隊哪裡有問題，同時也要基於我們的作業工具，輔助業務團隊一起改進完善。

本文針對“數據牽引改進，工具固化規範”這一思路在業務團隊落地過程中的動作流程進行詳細闡述，並明確了支撐整個流程的關鍵角色定義和組織運作形式。

數據牽引改進，是指關注軟件交付過程中各種度量數據的收集、統計、分析和反饋，通過可視化的數據客觀反映整個研發過程的狀態，以全局視角分析系統約束點，並和業務團隊達成共識，提煉出客觀有效的改進目標；工具固化規範，針對識別出來的Gap點和重點問題進行分析，制定出可以在作業工具承載的模板規範，以及需要工程師行為做出改變的能力要求，並在作業工具上對這些規範要求的落地效果進行檢查，用數據度量改進效果。最後，對改進項目進行總結分享，打造學習型組織，不斷驅動持續改進和價值交付，牽引研發團隊模式和文化的轉變。

2020年的研發過程可信圍繞CleanCode、構建、開源、E2E追溯四個領域開展，這也是公司要求的可信變革中最基本、最重要、投入產出比最大的四個點。

整體流程說明

整個運作流程，圍繞數據，按照“定義軟件工程規範->定義數據分析模型->工具實現數據度量和分析->數據運營發現實際軟件工程活動和規範的偏差->工具輔助團隊改進->工具固化軟件工程規範”這個流程進行實施，並對最終效果進行階段性總結。隨着業務團隊能力的提升以及軟件工程規範性、開發模式的改變，對最初定義的軟件工程規範，會階段性的進行完善，循環往複、持續優化，最終讓業務團隊在遵守公司要求的研發過程可信規範的前提下，實現業務成功。

1) 定義軟件工程規範：圍繞公司可信變革的目標，BU對各個服務產品部的研發模式規範和能力要求，COE制定適合BU現狀的軟件工程規範；

2) 定義數據模型：COE針對制定的軟件工程規範，提煉出核心的、有針對性、可用工具度量的數據模型，並且和各個服務產品部達成一致；

3) 工具實現數據度量和分析：根據這幾個數據模型，數據分析工具自動從數據源進行採集、匯總、計算，並把結果呈現在數據看板上；業務團隊可以打開匯總數據，根據明細數據進行動作規範自檢和改進；

4) 數據運營發現實際軟件工程活動和規範的偏差：數據治理小組在實際運營過程中，分析度量指標的數據，識別業務團隊實際的軟件工程活動和要求規範不一致的Gap點和關鍵問題；

5) 工具輔助業務團隊改進：COE針對分析出來的Gap點和關鍵問題，制定相應的改進措施，作業工具承載流程規範模板化整改，並針對業務團隊的不規範行為，制定適合各個服務產品部的公約要求，促使業務團隊人員能力提升；

6) 工具固化軟件工程規範：針對業務團隊的公約要求，在作業工具上進行check，最終作業工具承載了整個軟件工程規範要求，以及融入到作業流程中的規範要求事前檢查。

三層數據分析模型

我們採用了三層數據分析模型，由作業工具自動採集用戶研發過程行為明細數據，數據分析工具進行准實時匯總計算呈現總體目標，三層數據系統性的輔助業務團隊系統性的識別研發過程中的不規範點和能力短板，讓業務團隊“知其然，知其所以然”。這三層數據模型是層層深入，迭代完善，下層支撐上層的關係。

第一層：目標、進展、結果數據分析；和公司可信變革目標牽引對齊，結合BU實際情況，形成BU的整體可信要求，並在數據分析看板上呈現各個服務產品部要達成的過程可信目標、每日的改進進展和最終完成情況；例如，對各個服務產品部要求達成CleanCode的目標。

第二層：詞法/語法分析數據；COE針對第一層的目標牽引，分解出來的具體實施環節的度量指標，只有這些分解的指標都完成，第一層的目標才達成。這一層數據的目的主要是圍繞幫助業務團隊分析自己的能力短板在哪裡，進行有針對性的改進指；通過打開匯總數據的層層下鑽，用明細數據來分析業務團隊在DevSecOps軟件工程規範流程中關鍵動作執行的缺失點，並針對性的制定改進規範要求，牽引作業工具或者業務團隊補齊該部分缺失動作；例如，CleanCode的過程可信目標達成，可以分解成：靜態檢查配置合規率、Committer合入保障率、代碼倉Clean三個目標，只有這三個目標達成，就可以認為CleanCode總體目標達成。

第三層：語義分析數據：COE打開第二層數據，不僅要看這些關鍵動過做沒做，還要看做的效果怎麼樣，最終效果體現在業務團隊的DevSecOps軟件工程規範提升；這一層的數據分析聚焦在防止為了指標而做第二層的數據，而是看業務團隊是否在真正參考BU制定的規範牽引的目標，提升業務交付過程中的效能、可信、質量能力，以及最終產生實際的業務效果。通過打開各個團隊的明細數據分析審視業務團隊執行的關鍵動作是否符合規範，是否在合適的階段點執行，執行效果是否有效；並階段性的總結和提煉經驗，形成知識資產固化到作業工具。例如，針對第二層的靜態檢查配置合規率，可以分解為：靜態檢查配置有效性和靜態檢查執行有效性。靜態檢查配置有效性，包括：檢查靜態檢查工具配置的數量、是否符合BU的配置規範，以及是否在代碼合入主幹master時進行了配置；靜態檢查執行有效性，主要看是否每一次MR提交時都執行靜態檢查、是否發現問題在研發活動的最早階段，攔截的問題的效果怎麼樣。只有第三層的動作度量都達成后，才可以說第二層的目標是達成的。

數據治理過程流程圖

為了實現“數據牽引改進，工具固化規範”這個目標，準確、一致、准實時的數據是核心關鍵，但因為數據採集不完整、業務團隊不規範、數據呈現維度不一致等原因，數據的準確性有一個不斷提升的過程，因此需要對各個層級展示的數據進行治理。整個數據治理過程中，由“業務團隊/作業工具/治理小組/數據分析工具（阿基米德）/COE”五個角色緊密配合，而且以年/半年為目標，不斷總結經驗，循環往複、持續優化的過程。

a) COE：和公司可信變革目標牽引對齊，結合BU能力現狀，形成BU的整體可信要求；

b) COE：針對BU的業務現狀，定義出適合BU現狀的軟件工程規範要求；業務團隊：和BU發布的各個領域的軟件工程規範牽引目標達成一致；

c) COE：針對規範分解出核心的度量指標，並制定度量數據模型；

d) 研發用戶：在使用作業工具進行研發活動；作業工具：承載了BU各個服務產品部在使用過程中沉澱的行為數據；

e) 數據分析（阿基米德）：准實時接入作業工具的數據，展示各個服務產品部當前的研發能力現狀；

f) COE：和各個服務產品部達成一致，制定各個服務產品部的年度牽引目標；

g) 數據分析（阿基米德）：用數據呈現各個服務產品部的牽引目標和能力現狀，統一數據口徑；呈現月/周/天的明細數據，以及支撐Gap分析和重點問題的數據視圖；

h) COE：根據牽引目標和能力現狀，分析Gap原因和關鍵問題；治理小組：在數據運營過程中，根據數據分析團隊當前的能力現狀是否和數據呈現一致；

i) 研發用戶：可以實時登錄數據工具（阿基米德）進行查看各個層級的明細數據；

j) 治理小組：根據准實時進展數據，分析當前團隊研發過程中的實際問題，並匯總給COE；

k) COE：結合細粒度的分析數據、以及治理小組匯總出來的各個服務產品部的實際問題，制定規範和改進措施，包括作業工具的規範和研發用戶的動作行為公約；

l) 作業工具：承載作業工具上落地的規範要求；治理小組：作為接口人，承接研發工程師的行為規範公約，結合各個服務產品部實際情況來負責落地；

m) 研發用戶：按照規範要求和針對數據的自檢進行研發過程行為規範化；

n) 研發工具：對研發用戶的行為規範是否滿足要求進行自動化檢查；最終目標是讓整個軟件工程規範都固化在工具中進行承載；

o) 數據分析（阿基米德）：呈現按照規範改進后的明細數據和匯總目標；研發用戶：自助查看整改后的明細數據；

p) COE：根據數據改進的效果，以及過程中暴露的問題進行總結后形成經驗資產，並持續改進；

數據流圖

過程可信的數據在各個工具系統中採集、流轉、匯聚、分析、呈現，整個數據流圖如下：

其中，識別出6個重要的全量數據源：

a) 代碼庫數據：該數據由伏羲的服務信息樹上配置的代碼庫數據，加上阿基米德上人工配置的代碼庫，構成各個雲服務發布到生產倉的代碼全集；

b) Workitem信息流數據：當前識別vision上的需求、問題、task，加上Gitlab/Codeclub上的issue，構成可識別的Workitem數據全集；

c) SRE現網包數據：包括普羅部署、CCE、CPS、CDK各種類型部署的包數據，構成全量現網包數據；

d) 開源二進制包數據：開源中心倉數據（java、python、go、nodejs四種）語言，加上公司c/c++的數據構成全量開源二進制包數據；

e) 研發過程配置數據：阿基米德上配置的committer數據是全量的committer數據；阿基米德上識別出來的主分支是全量的主分支（邏輯“master”）數據；

f) 伏羲研發過程數據：伏羲三個庫，MongoDB的靜態檢查、門禁數據；MySQL中的測試、發布數據；MySQL中包和多個流水線的對應關係數據；一起構成了以“包”為維度的全量伏羲研發過程數據；

運作組織

數據治理運營團隊

按照過程可信在BU的落地策略，在CleanCode、構建、開源、E2E追溯四個領域設置數據治理運營團隊，由 “數據分析工具（阿基米德）—COE—各個服務產品部接口人組成的治理小組”三個角色組成，以“指標度量為牽引，數據的客觀呈現為落地方式，業務的價值反饋為最終目的”的原則來落地數據治理工作。

COE的職責：

1） 和公司可信變革目標牽引對齊，結合BU能力現狀，形成BU的整體可信要求；定義出適合BU現狀的軟件工程規範要求；針對規範分解出核心的度量指標，並制定度量數據模型；

2） 利用作業工具已經產生的數據，和治理小組一起分析識別數據質量的問題，按照三層數據分析模型，層層打開，識別業務團隊能力Gap點。

3） 分析典型問題，識別作業流的斷裂點進行補齊，和業務團隊的不規範動作，制定規範和公約要求，逐步改善數據質量。

4） 事後歸納總結，識別出流程缺失，組織缺失，責任缺失等機制行問題，並固化到作業工具中。

治理小組：

1） 結合各個服務產品部的實際情況，承接COE的數據治理規範在各個服務產品部的落地；

2） 識別數據治理動作在各個服務產品部落地過程中的實際問題，和COE一起分析，提出系統性的解決思路，最終固化到作業工具中。

3） 跟蹤過程可信在業務團隊落地的過程中的進展，為業務團隊最終達成可信變革目標負責，為改進過程產生實際的業務價值負責；

數據分析工具（阿基米德）：

1） 確保接入的數據準確、實時、一致，用數據實時反映BU各個服務產品部的能力現狀，為COE和治理小組的數據運營提供數據支撐；

2） 系統性的落地COE的方案設計，實現整個BU統一標準的數據看板，能夠清晰的通過數據識別出來業務團隊的能力Gap，牽引業務團隊達成整體改進目標；

3） 按照三層數據模型進行數據展示，層層下鑽，讓業務團隊“知其然，知其所以然”，牽引業務團隊中的每一個人都能自己進行改進；

4） 通過數據分析，識別DevSecOps軟件工程規範在BU的業務團隊落地過程中的重點問題，以及該問題背後的流程、制度缺失，促使最終規範固化在作業工具中。

例會設置

“數據驅動DevSecOps能力提升例會”為研發領域數據治理相關問題的求助和裁決例會。

會議分為三個階段：

1） 第一階段，例行議題，形式類似於“體檢報告”，用數據反映業務團隊的現狀和問題；

2） 第二階段，申報議題，形式類似於“專家會診”，討論某一個具體數據治理過程中的問題和Top困難求助；

3） 第三階段，靈活安排議題，形式類似於“問題總結”，針對某一類的具體問題，進行集中討論和歸納總結定義，形成BU的規範流程和章程總結。

主數據承載系統

主數據是指具有高業務價值的、可以在企業內跨越多個業務部門被重複使用的數據，是單一、準確、權威的數據來源。和業務型數據、分析型數據相比，主數據主要有以下幾個特徵：

1） 特徵一致性：也就是能否保證主數據的關鍵特徵在不同應用、不同系統中的高度一致，直接關係了數據治理成敗；

2） 識別唯一性：在一個系統、一個平台，甚至一個企業範圍內，同一主數據實體要求具有唯一的數據標識，即數據編碼；

3） 長期有效性：貫穿該業務對象的整個生命周期甚至更長，當該主數據失去其效果時，系統採取的措施通常為軟刪除，而不是物理刪除；

4） 業務穩定性：在業務過程中其識別信息和關鍵特徵會被業務過程中產生的數據繼承、引用和複製。除非該主數據本身的特徵發生變化，否則該主數據不會隨着業務的過程中被其他系統修改。

主數據源識別原則：

a) 如果有多個數據源構成同類型數據的主數據，兩種處理策略：

1）選取一個源系統逐步收編其他源系統的數據，變成唯一主數據源

2）如果1）不能實現，由阿基米德系統進行封裝后屏蔽多個數據源系統，該類型數據的唯一數據源變成阿基米德，待後續1）實現后，阿基米德該類型主數據源失效。

3）當數據在多個作業系統中進行流轉時，判斷是否作為主數據源的標準是：數據在該系統有實際的業務動作產生，而不是只承載數據的流轉。

b) 如果確定為唯一數據源，其他消費該類型數據的系統不能和數據源產生衝突。

所有數據僅能在數據源產生，其它系統只能讀取不能修改。下游發現的數據源質量問題，應當在數據源頭進行修正。

c) 主數據使用方不得改變原始數據，但可以進行擴展。

數據消費方不得對獲取的數據進行增、刪、改，但可以在數據的基礎上進行屬性擴展。

d) 在滿足信息安全的前提下充分共享，不得拒絕合理的數據共享需求。

數據如果不流轉，不僅不會產生業務價值，還增加存儲成本；只有不斷流轉，對業務團隊產生實際價值時，還能得到使用效果的反饋，促進數據價值的進一步提升。

原則為：核心資產安全優先，非關鍵資產效率優先。

一類主數據源

二類主數據源

 

點擊關注，第一時間了解華為雲新鮮技術~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

※別再煩惱如何寫文案,掌握八大原則!