資安

本文作者：吳數傑 阿里雲智能 開發工程師 1. 概述 本文主要講解MaxCompute Spark資源調優，目的在於在保證Spark任務正常運行的前提下，指導用戶更好地對Spark作業資源使用進行優化，極大化利用資源，降低成本。 2. Sensor Sensor提供了一種可視化的方式監控運行中的Spark進程，每個worker（Executor）及master（Driver）都具有各自的狀態監控圖，可以通過Logview中找到入口，如下圖所示： 打開Sensor之後，可以看到下圖提供了Driver/Executor在其生命週期內的CPU和內存的使用情況： cpu_plan/mem_plan（藍線）代表了用戶申請的CPU和內存計劃量 用戶可以直觀地從cpu_usage圖中看出任務運行中的CPU利用率 mem_usage代表了任務運行中的內存使用，是mem_rss和page cache兩項之和，詳見下文 Memory Metrics mem_rss 代表了進程所佔用了常駐內存，這部分內存也就是Spark任務運行所使用的實際內存，通常需要用戶關注，如果該內存超過用戶申請的內存量，就可能會發生OOM，導致Driver/Executor進程終止。此外，該曲線也可以用於指導用戶進行內存優化，如果實際使用量遠遠小於用戶申請量，則可以減少內存申請，極大化利用資源，降低成本。 mem_cache（page_cache）用於將磁盤中的數據緩存到內存中，從而減少磁盤I/O操作，通常由系統進行管理，如果物理機內存充足，那麼mem_cache可能會使用很多，用戶可以不必關心該內存的分配和回收。 […]

Pixiu 是什麼 ​ 在回答 Pixiu 是什麼之前，我們簡單解釋一下 Dubbo 是什麼。Dubbo 是一個開源的高性能 RPC 框架，有著豐富的服務治理能力以及優秀的擴展能力。Dubbo 更擴展出 Dubbo-go​，為用戶提供了 Golang 的 Dubbo 解決方案，打通了兩種語言之間的隔閡，使 Dubbo 更加貼近雲原生。 Dubbo-go

1. 前言 最近，筆者有幸對高德打車訂單Push項目進行了重構，與大家分享一下代碼重構相關的工作經驗，希望對大家有所啟發。 ​有時候，我們在做某個功能需求時，需要花掉大量的時間，才能找到和需求有關聯的代碼。或者，我們在閱讀別人寫的代碼、接手別人的項目時，總是“頭皮發麻”，當你面對結構混亂、毫無章法的代碼結構，詞不達意的變量名、方法名時，我相信你根本沒有讀下去的心情。這不是你的問題，而是你手中的代碼需要進行重構了。 2. 何為重構 每個人對重構都有自己的定義，我這裡引用的是“Martin Fowler”的，他從兩個維度對重構進行了定義。 作為名詞：重構是對軟件內部結構的一種調整，目的是在不改變軟件可觀察行為前提下，提高其可理解性，降低其修改成本。  作為動詞：重構是使用一系列重構手法，在不改變軟件可觀察行為的前提下，調整其結構。 我在本文提到的代碼重構，更偏向它作為動詞的定義，而根據重構的規模程度、時間長短，我們可以將代碼重構分為小型重構和大型重構。 小型重構：是對代碼的細節進行重構，主要是針對類、函數、變量等代碼級別的重構。比如常見的規範命名（針對詞不達意的變量再命名），消除超大函數，消除重複代碼等。一般這類重構修改的地方比較集中，相對簡單，影響比較小、時間較短。所以難度相對要低一些，我們完全可以在日常的隨版開發中進行。 大型重構：是對代碼頂層進行重構，包括對系統結構、模塊結構、代碼結構、類關係的重構。一般採取的手段是進行服務分層、業務模塊化、組件化、代碼抽象複用等。這類重構可能需要進行原則再定義、模式再定義甚至業務再定義。涉及到的代碼調整和修改多，所以影響比較大、耗時較長、帶來的風險比較大（項目叫停風險、代碼Bug風險、業務漏洞風險）。這就需要我們具備大型項目重構的經驗，否則很容易犯錯，最後得不償失。 其實大多數人都是不喜歡重構工作的，就像沒有人願意給別人“擦屁股”一樣，主要可能有以下幾個方面的擔憂： 不知道怎麼重構，缺乏重構的經驗和方法論，容易在重構中犯錯。 很難看到短期收益，如果這些利益是長遠的，何必現在就付出這些努力呢？長遠看來，說不定當項目收穫這些利益時，你已經不負責這塊工作了。 重構會破壞現有程序，帶來意想不到的Bug，不想去承受這些意料之外的Bug。 重構需要你付出額外的工作，何況可能需要重構的代碼並不是你編寫的。 3. 為何重構

往期精選合集包（戳我前往） 囊括了：AI、架構師、 Serverless 、AIoT、DevOps、容器化、機器學習、雲計算、K8s、微服務、雲原生、視覺AI、大數據、小程序、物聯網等各種主題直播合集。 面向人工智能“新基建”的知識圖譜底座 – 阿里雲圖數據庫GDB >>戳我去觀看 直播簡介 包含DBA職業發展、 雲數據庫技術趨勢、 最佳實踐等，教您如何使用圖數據庫構建知識圖譜，如何深度融合行業多元異構數據，如何幫助企業智能分析、科學決策等 講師介紹 楊哲超阿里雲圖數據庫產品負責人工信部人工智能揭榜掛帥評委專家 阿里雲數據庫雙11項目負責人智盛專訪 >>戳我去觀看 直播簡介 今年的雙11智盛繼續帶領數據庫團隊攻堅克難，想知道他今年雙11他經歷了什麼，有哪些體驗嗎？想知道今年雙11阿里雲數據庫是如何扛住峰值壓力的嗎？想知道數據庫+大數據帶來了哪些變化嗎？想知道智盛對年輕開發者的建議是什麼嗎？ 快快鎖定雙11技術播報特別篇，看主播莫孤如何挖掘雙11數據庫團隊背後的故事！ 講師介紹

大家好，我是冰河~~ 最近小夥伴最近都在問我，在系統中引入緩存後，當向數據庫中寫入數據時，是先寫數據庫還是先寫緩存呢？先寫數據庫和先寫緩存有什麼區別嗎？今天，我們就一起來聊聊這個話題。 從本質上講，無論是先寫數據庫還是先寫緩存，都是為了保證數據庫和緩存的數據一致，也就是我們常說的數據一致性。 隨著互聯網的高速發展，當今時代已然從IT時代進入到DT時代。互聯網系統架構也已經由最初的單體架構轉變為分佈式、微服務架構模式。從數據體量上來看，各系統存儲的數據量越來越大，數據的查詢性能越來越低。此時，就需要我們不斷的進行優化，一種常用的優化手段就是引入緩存。而引入緩存後，我們在向數據庫插入數據時，到底是先更新數據庫還是先更新緩存呢？ 緩存的一般使用 緩存，從本質上講，是為了更好的協調兩個速度差異比較大的組件而引入的一種中間緩存層。例如，如果需要將數據讀入CPU進行計算處理，由於CPU的運算速度是非常快的，而磁盤的IO處理相比於CPU來說，慢了很多數量級，每次從磁盤讀取數據，勢會造成CPU長時間並且頻繁等待磁盤IO。此時，我們就可以通過內存來緩和CPU和磁盤之間的速度差異。 從緩存的使用上來說，一般是按照如下的流程來使用緩存。 我們也可以表示成如下的序列圖。 在上面的使用示例中，我們只是簡單的將數據放入了緩存，最多為緩存設置一個過期時間，到期後，緩存自然就會被清除，後續的請求由於在緩存中獲取不到數據，又會從數據庫中獲取數據，將數據寫入緩存。 但是在後續更新數據的操作中，是更新完數據庫，接下來更新緩存還是刪除緩存？又或者是先刪除緩存，再更新數據庫？ 緩存更新策略 從理論上來說，給緩存設置過期時間，其實是一中最終一致性的表現。這種方案下，可以對存入緩存的數據設置過期時間，所有的寫操作以數據庫為準，對緩存操作只是盡最大努力即可。也就是說如果數據庫寫成功，緩存更新失敗，那麼只要到達過期時間，則後面的讀請求自然會從數據庫中讀取新值然後回填緩存。這也是一般情況下，使用的最多的一種方式。 先更新數據庫再更新緩存 其實，這種方案很多有經驗的小夥伴是很反對的，為啥，我們來分析下。 首先，這種方案會有線程安全的問題。 例如，同時有線程A和線程B對數據進行更新操作，可能會出現下面的執行順序。 (1) 線程A更新了數據庫(2) 線程B更新了數據庫(3) 線程B更新了緩存(4)

作者：宋順 來源：金融級分佈式架構公眾號雲原生的理念正如火如荼，然而真正大規模落地的公司依然屈指可數，螞蟻作為國內比較早進行嘗試的公司，經過了 2 年多的探索，沉澱出了一套切實可行的方案並最終通過了雙十一的考驗。 本文主要分享我們在 Service Mesh 大規模落地過程中的一些經驗、社區好消息以及對未來的思考，希望能給大家帶來一些啟發。 一、為什麼需要 Service Mesh? 我們為什麼需要Service Mesh，它對業務的價值在哪裡，我們總結了三點： 微服務治理與業務邏輯解耦。 異構系統的統一治理。 金融級的網絡安全。 下面分別進行闡述。 1. 微服務治理與業務邏輯解耦 在

作者：樓磊磊 來源：金融級分佈式架構公眾號本文將介紹 SOFAGW 互通網關，首先切入在跨站點通信時碰到的核心痛點，引入 SOFAGW 互通網關的解決方案，會重點說明如何解決在安全、互通、接入成本、高效等幾方面問題，介紹 SOFAGW 網關的內部實現架構，展示 SOFAGW 網關達成的業務成果。 業務痛點 隨著業務發展越來越多元化，部分業務域相對比較獨立，或因其業務屬性，會建立成獨立的站點（租戶），比如：國際業務和螞蟻保等。這些站點之間網絡是隔離的，但實際業務上會存在一些通信的需求，所以我們碰到的核心問題是：網絡互相隔離的多個站點之間怎麼做高效可信的通信？對此我們有兩種針對站點間互通的解決思路： 思路1：為每個業務創建跨域 VIP 為每個業務創建跨域 VIP，站點的業務通過 VIP 來做通信。這種方式，運維管理員要在兩個網絡間開很多 VIP，加訪問白名單，最終網絡拓撲會變成如下；將面臨網絡口子多、運維成本高、業務接入成本高、安全閾值低等問題。 這個方案有以下幾個問題：

作者：黃家琦 來源：金融級分佈式架構公眾號本文主要是介紹 MOSN 在無人值守變更上的實踐以及過程中的一些思考。主要分為 3 個部分：-介紹 MOSN 在規模化運維中遇到的挑戰-無人值守上的實踐-MOSN 與技術風險方面的思考 MOSN 規模化後的運維挑戰 MOSN 早期在內部推進的時候，變更方面的支持是比較傳統的。早期的變更工具只有基礎的 pod 粒度的 MOSN 升級的能力。變更過程中的問題，最初依賴於上層業務系統的監控和反饋，稍後我們又在 MOSN 內建設了錯誤碼。發佈控制上，將版本區分為穩定版和灰度版本，升級的灰度過程和大範圍的覆蓋過程都由人工控制。這些方式在小範圍、大量人力投入的情況下，保證了 MOSN

簡介 memory-bound函數可以稱為內存受限函數，它是指完成給定計算問題的時間主要取決於保存工作數據所需的內存量。和之相對應的就是計算受限compute-bound的函數，在計算受限的函數中，計算所需要的計算步驟是其決定因素。 本文將會介紹一下內存受限函數和它跟內存函數的關係。 內存函數 內存函數和內存受限函數看名字好像很類似，其實他們的作用是不同的，我們先來看下內存函數。 在學習算法中，有一個非常簡單好用的算法叫做遞歸算法，熟悉遞歸算法的朋友可能都知道，遞歸算法雖然好用，但是有個缺點就是會重複計算遞歸過程中的函數，比如說遞歸中最經典的斐波拉赫數列： Recursive_Fibonacci (n) { if (n == 0) return 0 if (n == 1) return

​ 人體的免疫系統，無時無刻不在守護著我們的健康。雖然毫無感知，但組成免疫系統的各種器官、細胞幾乎每天都在聯合戰鬥，讓我們在充斥各種有害細菌和病毒的世界，安然無恙。 如今，我們也在努力構建雲的原生免疫系統，將安全基因植入每個產品和組件，實現基礎設施即安全。作為雲原生架構基礎設施的核心組成部分，容器安全一直是企業關注的核心問題之一，並且在新時代面臨著新挑戰。越來越高的容器應用部署密度、越來越多的攻擊面都在向企業和雲服務商發出警報——體系化的容器安全能力建設迫在眉睫。 為解決單點問題而生的碎片化安全能力，因雲天然的一體優勢得以有機組合。無論是對抗外來風險還是防禦內部威脅，都能給用戶帶來無感的極致安全防護。對於提供容器服務的雲服務商來說，就需要依託於雲平臺自身的安全能力，構建安全穩定的容器基礎設施平臺，並且面向容器應用從構建、部署到運行時刻的全生命週期構建對應的安全防護手段。比如阿里雲容器服務 ACK 和阿里雲容器鏡像服務 ACR 就得益於阿里雲強大的平臺安全能力，針對容器應用在供應鏈和運行時刻階段攜手提供了豐富的安全治理能力，幫助企業構建完整的雲原生安全體系。 如同人的免疫力從小到大在不斷變強一樣，雲的原生免疫力也是一個不斷生長的過程。如今，它長成了什麼狀態？可以有機組合解決什麼安全問題？於 Forrester IaaS 安全能力評測中與谷歌並列滿分的阿里雲容器服務，在與安全體系不同環節的通力協作下，又將為企業提供哪些方面的安全守護？ 答案就在 7 月 16 日。掃碼預約！帶你一起探祕雲的原生免疫系統新模式！ 點擊https://yqh.aliyun.com/live/native_security，直達直播間