雲計算

本期導讀 ：【AI 訓練加速】第十六講 主題：FFluid + JindoFS 對 OSS 上數據進行訓練加速luid + JindoFS 對 OSS 上數據進行訓練加速 講師：揚禮，阿里巴巴計算平臺事業部 開源大數據平臺 開發工程師 內容框架： Fluid 介紹 […]

阿里云云盒更多內容：https://yqh.aliyun.com/live/cloudbox 2020年4月，阿里雲數據庫自治服務DAS 正式發佈，開啟數據庫“自動駕駛”新時代。經過一年的時間，數據庫自治服務DAS的輔助自治模式已經支持阿里雲全網100%的高可用實例，並且已經有超過5000的客戶，運行在DAS的自治模式，即授權DAS進行數據庫的自修復、自優化、自運維和自安全。   讓數據庫發揮最優的效能，依賴很多數據庫專業領域知識，對於大部分企業和應用開發者而言，依然充滿挑戰，如故障診斷，快速定位根因並進行有效的止損；業務快速迭代過程中的數據庫的持續調優、SQL Review等，都是非常耗時耗力且需要7×24小時值守的能力，因此，數據庫走向自治是一個必然趨勢。   如果說，傳統數據庫向雲數據庫的轉變是“汽車換馬車”，那麼DAS就是給“汽車”加上了“自動駕駛”的引擎，擁有了“自動駕駛”的能力。   在今天的發佈會上，針對用戶的核心痛點，DAS新發布了8大核心自治功能，包括7×24小時異常檢測、自動SQL限流、自動SQL優化、自動空間優化、自動彈性伸縮、智能調參、智能壓測、實時審計等，為企業的SQL問題、數據庫負載問題、空間問題、容量評估、安全審計，從異常發現、根因定位、自修復/自優化/自安全，既能實現快速止損，又會持續不斷的對數據庫進行優化，無需人工干預，讓企業像體驗“自動駕駛”一樣使用數據庫，數據庫管理成本降低90％。 SQL問題——以無人值守方式，實現數據庫持續優化 數據庫性能問題70%以上是SQL問題，但是傳統方案下面缺乏有效的止損手段，並且不具備提前預防、持續優化的可能性。 DAS通過異常SQL的定位、異常SQL自動限流、自動SQL優化、結果驗證，覆蓋解決SQL問題的各個環節，實現及時發現、快速止損、持續優化和可驗證。 數據庫負載問題——實現全鏈路自動彈性伸縮，應對業務負載變化 對於絕大多數企業來說，數據庫都是主幹系統，數據庫負載飆升，會對業務造成巨大的損失，但是基於閾值的告警方式，存在異常發現延遲大的問題，往往不能在負載發生變化的時候，快速發現並及時採用止損措施。 DAS的7×24小時異常檢測，可以1分鐘內檢測到數據庫異常，並且支持全鏈路自動彈性伸縮（包括帶寬、Porxy、CPU/內存/IO、節點等等），能夠快速解決數據庫負載問題，保障業務持續可用。 空間問題——數據庫空間問題的自修復、自優化 數據庫空間問題，影響著數據庫的性能和成本，DAS針對數據庫常見的空間問題，提供了完整的“治標”+“治本”的自修復、自優化方案，節省數據庫使用成本的同時，提升數據庫的性能。 DAS全方位自治能力 助力企業用戶發揮數據庫最優效能

正式官宣：我們有名字啦！雲起體驗實驗室。阿里雲體驗實驗室是面向開發者打造的雲上實踐平臺，是開發者上雲第一站。今天體驗實驗室正式升級為「雲起體驗實驗室」，全新的沉浸式交互設計框架，系統化的學習主題，淺色深色兩種模式選擇，讓你學的輕鬆，玩的盡興！ 4大產品亮點，80+體驗場景 亮點1：遠程桌面環境，邊學邊做兩不誤簡介：實驗室提供遠程桌面環境，在同一窗口邊看手冊邊實踐，沉浸式玩轉雲產品。還可以邀請或分享給好友遠程協助。 亮點2：全新的 Web Terminal 模式簡介：Web Terminal 模式助力更便捷地操作ECS服務器，幫助學習如何通過運行雲命令行連接、操作、管理阿里雲資源。 亮點3：雲端編程IDE環境在線進行多種語言的開發、調試、編譯運行，一鍵預覽代碼上線效果，寫代碼更輕鬆。 亮點4：更豐富的體驗內容及玩法簡介：覆蓋25+雲產品，場景分類更直觀，基礎場景更全面。還有豐富多彩的運營活動，歡迎長期關注。 現在參與活動即可領取定製T恤https://developer.aliyun.com/adc/series/activity/allnew

容器服務 ACK 【地域開服】 GA：ACK Pro 版開服本地雲南京、政務雲-北京，已開服地域文檔。 【容器安全】 Feature：集群工作節點支持 CIS 安全加固，進一步提升 ACK 集群節點的操作系統安全性，查看幫助文檔。 Feature: 本月新增安全運營，新創建集群已默認開啟安全加固，已有集群請按照以下文檔操作升級： CVE-2021-30465：攻擊者可以通過創建惡意 Pod，利用符號鏈接以及條件競爭漏洞將宿主機目錄掛載至容器中，最終導致容器逃逸問題。具體漏洞的影響及已有集群防範措施，查看幫助文檔。 CVE-2020-8562：攻擊者可以通過某種方式繞過API Server 對內網 Proxy

隨著雲原生理念與雲原生技術的不斷完善和發展，越來越多的行業開始落地實踐雲原生技術，這對不同崗位的技術從業者產生了不同程度的影響。不管是對 IT 主管還是對一線開發人員和運維人員來說，從業務邏輯到技術選型，整個技術棧都發生了天翻地覆的變化。為了更好地迎接雲原生時代的到來，大家有必要深入瞭解雲原生落地實踐對不同崗位的影響。​ CXO 和 IT 主管 ​ 很多企業對技術類 CXO（包括 CTO、CIO、CISO、CDO等，本文均稱為 CXO）和技術主管這些技術領導者的能力要求是全面而嚴苛的，技術領導者不僅要能夠兼顧技術管理的各個方面，還要以維持公司業務為核心職責。因此，CXO 和 IT 技術主管既要擁有寬廣的技術視野、出色的技術判斷力甚至高層架構設計能力，還要具備良好的產品意識，以應對不斷變化的內外部環境。​ 外部環境 ​ 作為企業的 CXO 和

客戶關鍵詞 國內TOP5財險公司 業務範圍覆蓋國內31個省（自治區、直轄市） 營業網點超過2600個 連續四年入選“中國企業500強” 員工和設備接入龐雜 近50000名員工、大量外包人員與合作伙伴 多條保險產品線，延伸眾多互聯網化業務形態 保險業首個混合雲核心系統 3年內分階段完成新一代核心系統建設 保單為中心轉向客戶為中心 產品、險種驅動轉型科技、創新驅動 保險業是一個大數據行業，雲計算、人工智能技術的發展加速了保險業態變革。保險機構在產品、營銷、核保、理賠、客戶服務等領域的業務價值正在被“社群化+智能化+一體化”趨勢重塑： 社群化 疫情催化下，“直播+社群+數字化導流”崛起，短視頻、直播等模式傳播速率高，互動性強，險企的“產品推廣-諮詢-核保-售賣-簽約-出險-理賠”業務流程全面線上化； 智能化 險企通過新技術與互聯網平臺數據優勢，優化在線核保、智能核保模型，空中契調、自主上傳的便捷投保成為趨勢； 一體化 居民保障需求快速增長變化，車險、意外險、財產險、人身險……多樣化險種線上線下統一管理、統一理賠需求提升。 為了快速響應市場、靈活應對客戶需求並提升險企的核心競爭力，該財險公司啟動了以客戶為中心的“新一代核心系統”的再造。

作者 | 麓行來源 | 阿里技術公眾號 前言 為什麼要自己寫一個RPC框架，我覺得從個人成長上說，如果一個程序員能清楚的瞭解RPC框架所具備的要素，掌握RPC框架中涉及的服務註冊發現、負載均衡、序列化協議、RPC通信協議、Socket通信、異步調用、熔斷降級等技術，可以全方位的提升基本素質。雖然也有相關源碼，但是隻看源碼容易眼高手低，動手寫一個才是自己真正掌握這門技術的最優路徑。 一 什麼是RPC RPC（Remote Procedure Call）遠程過程調用，簡言之就是像調用本地方法一樣調用遠程服務。目前外界使用較多的有gRPC、Dubbo、Spring Cloud等。相信大家對RPC的概念都已經很熟悉了，這裡不做過多介紹。 二 分佈式RPC框架要素 一款分佈式RPC框架離不開三個基本要素： 服務提供方 Serivce Provider 服務消費方

雖然阿里雲各促銷活動中推出了1核2G、2核4G、2核8G、4核8G、4核16G等眾多爆款雲服務器，而且價格都很低，但是同配置的雲服務器，可選擇的實例規格也有很多，而且不同實例規格的價格差別很大，例如一個企業新用戶購買一款2核4G配置的雲服務器，共享型s6實例的活動價格目前只要282.60元/年，而計算型c6a實例要640.08元/年起。那麼在阿里雲活動中選購雲服務器時，我們應該如何選擇實例規格？ 首先我們說下選對實例規格為什麼很重要？ 1、最大化利用雲服務器資源不管是個人還是企業，在選購阿里雲服務器時，不僅要根據業務考慮雲服務器配置大小，而且要根據業務應用場景選擇對應的雲服務器規格，這樣才能儘量使雲服務器性能發揮的淋漓盡致，保證業務穩定運行，不照成雲服務器資源的浪費，例如我們只是一個每天幾十個人訪問的個人或普通企業官網，通常選擇阿里雲服務器活動中的突發性能型t6、共享型s6實例就可以，但是如果我們需要雲服務器處理大量數據，要求雲服務器cpu有超穩定計算能力，就至少要選擇計算型實例。2、儘量節約我們在雲服務器成本上的開支由於阿里雲活動中的雲服務器大多僅限新用戶或產品新用戶購買，這就要求我們儘量在買的時候就一次買對，避免出現買了又退然後從新再買的情況出現，因為退了又買，很多時候我們就無法再享受活動價格了。比如我們是一個企業官網或者簡單APP運行的項目，通常來說選擇計算型c5、c6實例即可，如果你選擇突發性t6可能滿足不了項目穩定運行的需求，選擇性能更高的實例規格又會照成成本開支的增加。 其次，我們應該如何選擇實例規格？ 第一，我們應當瞭解阿里雲活動中各個實例規格的具體特點和適用場景，包括支持的雲盤種類、網絡PPS收發包能力、處理器等基本信息，如果你有時間，不妨詳細參考以下官方資料：雲服務器ECS>實例>實例規格族介紹本人在開發者社區發佈過一篇“阿里雲服務器實例規格選擇新方法：場景化選型助你選對實例規格”，裡面也介紹了一些雲服務器實例規格選擇的方法，感興趣的可以瞭解一下。 第二，阿里雲目前各促銷活動中的實例規格主要為突發性能型 t6、共享型 s6、通用型g6、內存型r6、計算型c6a、通用型 g6a、內存型r6a、內存型r5、計算型 c5、高主頻計算型hfg7等，下表是這些實例規格的主要特點或適用場景介紹： 實例規格 主要特點或適用場景 突發性能型 t6 輕量低負載場景，20%CPU性能輕鬆覆蓋 共享型 s6 100%性能基線，性能強勁，超高性價比，廣泛適用於建站等輕量應用 計算型c6 銷量之王！CPU與內存配比1：2

來源 阿里語音AI 公眾號 TTS（Text-To-Speech 語音合成） 是AI領域一顆小而美的“珍珠”，有了它，才讓智能應用和智能硬件長出“嘴巴”活起來。作為語音解決方案的發聲環節，它既可以像你現實中常見到的——主持人播報新聞、教師授課、明星導航。也可以定製特色人聲，用或奇趣、或軟萌、或激越的聲音來讀小說，朗誦詩歌，解說視頻等等。本文將為大家介紹基於阿里最新 KAN-TTS語音合成技術的精品人聲定製產品。 什麼是語音合成？語音合成就是將文字轉換成一段自然流暢語音的技術。目前，語音合成技術在泛娛樂、教育及涉及人機交互業務領域有比較廣泛的應用。常見於語音導航、語音助手、電話客服；影視、遊戲的配音、有聲閱讀等等。不同的應用場景期望呈現的人聲各不相同，人聲模型定製產品應運而生。所謂人聲模型定製，就是通過語音合成技術，定製不同性別、年齡、風格、情緒的人聲模型以滿足不同業務和場景的需要。 從2010年deep learning技術引入到語音識別領域後，對推動語音技術發展起到了重要作用。但在TTS方向一直應用比較緩慢。直到2016年、2017年，隨著Google的WaveNet、Tacotron和MILA的Char2Wav的提出，才將deep learning的強大能力賦予整個TTS方向。從音質、表現力和建模難度幾個方面都取得顯著超越。最近兩年，學術界開始將第一流的成果帶入到實際產品中，隨之而來的，就是TTS商業化應用的飛速發展。例如Google Cloud在2018年上線了基於TPU的WaveNet產品方案，Microsoft Azure在2018年上線了基於GPU的全Neural產品方案。阿里雲也在2018年上線了全Neural產品方案，並且考慮到實際客戶和業務的擴展需求，歷經大量的優化後，該方案是目前業內唯一的完全基於CPU的全Neural產品化方案。 更新更好的技術上線，同為阿里旗下的阿里巴巴集團客服和螞蟻客服理所當然成為首批客戶，兩家客戶無論業務量還是技術要求均遠高於業界平均水平，這也從另外一個側面證明阿里最新KAN-TTS技術框架的實際應用水平。2019年，天貓精靈上線的個性化語音訂製服務也出自KAN-TTS，它可以讓父母用手機錄10分鐘語音數據定製自己的聲音，合成故事給孩子聽。 除了阿里集團內部採購應用，阿里雲在2019年對外推出了基於KAN-TTS的快速低成本的新一代人聲模型定製服務，成功進駐第一財經移動端，根據用戶提供的少量財經新聞主播數據，定製了一款高表現力合成聲音，從而可以在第一財經APP上為用戶提供高體驗的新聞朗讀效果。 隨著技術水平的進步和商業化應用的推進，阿里基於KAN-TTS技術框架的人聲模型定製服務優勢進一步凸顯。通常來說，市場對產品的通用要求，一是價廉，一是質優，KAN-TTS下的人聲模型定製產品優勢恰在於此。 1.更低的成本。在傳統人聲模型定製的時候，由於受限於技術框架，整個定製需要的數據量是2萬句話（20小時）左右。按照人聲數據錄製的高標準要求，2萬句話往往對應著半年以上的錄音週期，需要發音人連續不斷的進行高質量高可靠性的錄音工作。這中間需要持續支付錄音人、錄音棚、錄音師、數據處理等各項費用。而且因為錄音週期過長，會增加定製項目的風險。比如發音人因感冒發燒等狀況會直接影響嗓子的發揮，比如錄音棚因故裝修等等。基於KAN-TTS強大的模型結構以及成百上千個發音人的數據，使得我們可以利用更少量的數據構建效果更好的TTS聲音。同時，我們開發了一套語料選取工具，可以做到用盡量少的數據覆蓋儘量全的場景，進一步降低了錄音數據量。 上圖顯示了基於KAN-TTS框架下，不同數據量所帶來的定製效果。可以看出，即便是在2小時（2000句）以下的數據量時，基於KAN-TTS定製也可以取得不錯的定製效果，和10小時差距不大，明顯超過95%和真人錄音接近程度。相對於傳統定製而言，基於KAN-TTS的定製可以將數據量縮小到之前的十分之一，同時，定製週期也會從之前的半年以上縮短到一個月左右。 2. 更高的表現力。傳統人聲模型定製語音表現比較生硬單一，很難調試出適應不同場景、需求、有個性、有特色的語音產品。而基於KAN-TTS技術的人聲模型定製產品恰恰在這一方面表現突出。它能夠根據需求風格靈活定製更適合場景需求的產品。比如新聞產品要求發音準確、飽滿、正規；客服則要親切自然，注重交流，有時帶點口音更有親切感。KAN-TTS技術能夠更好的掌握每個人語音中的獨有特質，合成獨屬於你的特色語音，滿足個性化需求。

作者 | 祥光（嚴祥光）來源 | 阿里技術公眾號 引言 EPaxos（Egalitarian Paxos）作為工業界備受矚目的下一代分佈式一致性算法，具有廣闊的應用前景。但縱觀業內，至今仍未出現一個EPaxos的工程實現，甚至都沒看到一篇能把EPaxos講得通俗一點的文章。EPaxos算法理論雖好，但由於其實在晦澀難懂，工程實現上也有很多挑戰，實際應用落地尚未成熟。 本文旨在通俗易懂地介紹EPaxos算法，由淺入深、一步一步的讓只有Paxos或Raft等分佈式一致性算法基礎的同學都能輕易看懂EPaxos，真正將晦澀難懂的EPaxos，變的平易近人，帶入千萬家。 在《一文了解分佈式一致性算法EPaxos》中，從Paxos的問題引出EPaxos，介紹了EPaxos的基本概念與直觀理解，相信讀者已經對EPaxos有了整體的印象。 本文將從Paxos與EPaxos對比的角度，介紹EPaxos核心協議流程。上一篇文章最後留下的思考題，相信在閱讀完本文後，都能找到答案。閱讀本文需要一些Paxos或Raft等分佈式一致性算法背景。 一 EPaxos基本思想 EPaxos是一個Leaderless的一致性算法，無需選舉Leader，任意副本均可發起提議。 Leaderless也可以看作每個副本都是Leader，從Multi-Paxos或Raft的角度看，如果使用多Group，將每個Leader劃分到不同的Group，每個副本擔任一個Group的Leader，同時擔任其它所有Group的Follower，好像也可以做到類似Leaderless的效果。 使用多Group實現的Leaderless，每個Group獨立的對一系列Instance達成一致，每個Group產生一條Instance序列，不同Group產生的Instance彼此獨立，不能確定先後順序。因此跨Group的一致性是一大問題，在一致性層面無法解決，往往需要在上層使用分佈式事務來解決。 EPaxos解決了這個問題，實現了真正的Leaderless。EPaxos通過跟蹤Instance之間的依賴關係，確定不同Group產生的Instance的相對順序，然後通過排序將多Group產生的多條Instance序列合併成一條全局的Instance序列，實現了跨Group的一致性，也即實現了真正的Leaderless。 EPaxos先運行共識協議，使各副本對Instance的值和Instance依賴的相對順序達成一致，隨後運行排序算法，基於前面已經達成共識的Instance的相對順序，對Instance進行全局排序，最終得到一致的全局Instance序列。 以上是站在Multi-Paxos或Raft使用多Group實現Leaderless的角度引出EPaxos的基本思想，實際Group是一致性算法之外的概念，這裡引入Group只是為了方便介紹，實際EPaxos中並沒有Group的概念，但與Paxos或Raft類似，可以在EPaxos之上實現多Group。 二