雲計算

作為一種架構模式，雲原生架構通過若干原則來對應用架構進行核心控制。這些原則可以幫助技術主管和架構師在進行技術選型時更加高效、準確，下面將展開具體介紹。 服務化原則 ​ 在軟件開發過程中，當代碼數量與開發團隊規模都擴張到一定程度後，就需要重構應用，通過模塊化與組件化的手段分離關注點，降低應用的複雜度，提升軟件的開發效率，降低維護成本。​ 如圖 1，隨著業務的不斷髮展，單體應用能夠承載的容量將逐漸到達上限，即使通過應用改造來突破垂直擴展（Scale Up）的瓶頸，並將其轉化為支撐水平擴展（Scale Out）的能力，在全局併發訪問的情況下，也依然會面臨數據計算複雜度和存儲容量的問題。因此，需要將單體應用進一步拆分，按業務邊界重新劃分成分佈式應用，使應用與應用之間不再直接共享數據，而是通過約定好的契約進行通信，以提高擴展性。​ 圖 1 應用服務化擴展​ 服務化設計原則是指通過服務化架構拆分不同生命週期的業務單元，實現業務單元的獨立迭代，從而加快整體的迭代速度，保證迭代的穩定性。同時，服務化架構採用的是面向接口編程方式，增加了軟件的複用程度，增強了水平擴展的能力。服務化設計原則還強調在架構層面抽象化業務模塊之間的關係，從而幫助業務模塊實現基於服務流量（而非網絡流量）的策略控制和治理，而無須關注這些服務是基於何種編程語言開發的。​ 有關服務化設計原則的實踐在業界已有很多成功案例。其中影響最廣、最為業界稱道的是 Netflix 在生產系統上所進行的大規模微服務化實踐。通過這次實踐，Netflix 在全球不僅承接了多達 1.67 億訂閱用戶以及全球互聯網帶寬容量 15% 以上的流量，而且在開源領域貢獻了 […]

每日精選內容推薦： 阿里雲李飛飛：什麼是雲原生數據庫 雲原生是一種新型技術體系，是雲計算未來的發展方向。雲原生數據庫在海外被稱為「Cloud-Native Database Systems」，前面譯成中文就是「雲原生」，理解雲原生先要理解兩個關鍵詞——「雲」和「原生」。今天，李飛飛帶你瞭解何為雲原生、雲原生如何與分佈式有機結合，以及雲原生技術如何幫助客戶邁入數字原生時代。>>戳我瞭解詳情 李飛飛演講實錄 | 雲原生數據庫2.0：一站式全鏈路數據管理與服務 這是在5月29日阿里雲開發者大會上，阿里巴巴集團副總裁、阿里雲數據庫產品事業部負責人李飛飛演講實錄。李飛飛認為雲原生是未來使用雲的標準方式，雲計算資源無處不在、取之不盡、用之不竭，不用關心雲資源在哪裡、有多少。就像今天我們使用自來水一樣，沒有⼈會費盡心思考慮水從哪裡來。一站式全鏈路數據管理與服務，帶你走進不一樣的雲原生數據庫。>>戳我瞭解詳情 媒體聲音 | 阿里雲一站式在線數據管理平臺，敲開雲原生數據庫 2.0 之門 新一輪科技革命和產業變革正重塑全球發展格局，以雲計算為代表的新一代信息技術相互滲透，成為數字經濟智能和創新發展新引擎。在2021阿里雲開發者大會上，阿里雲數據庫宣佈推出雲原生數據庫2.0——一站式在線數據管理平臺，以及“阿里雲數據庫開源計劃”，共建雲原生數據庫生態。想要了解阿里雲原生數據庫技術密碼嗎？那就從這裡開始！>>戳我瞭解詳情 乾貨｜一文讀懂阿里雲數據庫Autoscaling是如何工作的 阿里雲數據庫實現了其特有的Autosaling能力，該能力由數據庫內核、管控及DAS（數據庫自治服務）團隊共同構建，內核及管控團隊提供了數據庫Autoscaling的基礎能力，DAS則負責性能數據的監測、Scaling決策算法的實現及Scaling結果的呈現。本文將從Autosaling的工作流程和落地等方面，詳細闡述Autosaling相關知識。>>戳我瞭解詳情 阿里雲數據庫近期發展狀況 CCF數據庫專委會與阿里巴巴簽署框架合作協議，形成產業與學術的互促閉環 5月29日，中國計算機學會（CCF）數據庫專業委員會與阿里巴巴簽署框架合作協議，依託雙方在數據庫學術界的前沿探索和工業界的實踐經驗，就數據庫的最新進展和未來的發展方向共同探討，在人才培養、科研合作、技術創新等領域共同前進。CCF數據庫專委會主任李戰懷教授、阿里巴巴數據庫首席架構師黃貴、CCF數據庫專委會副主任崔斌教授、高宏教授、李國良教授、彭智勇教授、CCF數據庫專委會祕書長陳躍國教授以及阿里巴巴數據庫合作經理肖司淼等人出席了簽約儀式。>>戳我瞭解詳情

背景 阿里雲的雲監控服務用於監控阿里雲資源和互聯網應用，包括閾值告警和事件告警兩種模式，支持配置多種告警通知渠道。您可以將日誌服務開放告警配置為其中一個通知渠道，從而由日誌服務告警系統完成告警降噪、通知等處理。 雲監控接入SLS 要將雲監控的告警消息接入SLS，主要分為兩個步驟：在SLS中創建開放告警應用；將SLS開放告警作為Webhook配置到雲監控聯繫人。創建開放告警應用的具體步驟，可以參考文章SLS開放告警簡介。下面介紹下如何將雲監控的告警消息接入到SLS中。 獲取回調地址 在創建開放告警應用之後，通過點擊接口按鈕，打開如下圖所示的回調地址查看窗口。 回調地址由兩部分構成：域名部分和子路徑部分。其中域名部分屬於SLS的接入地址，和地域相關，每個地域都有各自不同的接入地址；子路徑部分包括用於發送消息的Access Key Id和開放告警應用。如下所示為一個完整的SLS回調地址： cn-heyuan-intranet.log.aliyuncs.com/event/webhook/RAMAK_{ACCESS_KEY_ID}/a123_asdad 其中”cn-heyuan-intranet.log.aliyuncs.com”為域名部分，屬於SLS通用的接入地址(endpoint)；event/webhook/RAMAK_{ACCESS_KEY_ID}/a123_asdad 則為子路徑部分。需要注意的是，用戶需要將子路徑部分中的{ACCESS_KEY_ID}替換為具體阿里雲RAM賬戶的Access Key Id，並且將權限策略AliyunLogOpenEventWrite賦予該賬戶；a123_asdad則為該開放告警應用的id，用於唯一區別不同的開放告警應用。 雲監控接入配置 將雲監控的告警消息接入SLS開放告警有兩種方式：在聯繫人中配置webhook回調地址，或者在規則中配置回調地址。 配置雲監控聯繫人 在雲監控聯繫人管理界面，點擊新建聯繫人或者已有聯繫人，修改Webhook（http|https）或釘釘機器人，填入SLS開放告警回調地址，然後單擊確認。 配置雲監控聯繫組 在雲監控聯繫人管理界面，點擊新建聯繫組或者已有聯繫組，將上面配置的告警聯繫人添加到聯繫組中。

夏日限定，阿里雲 Serverless Developer Meetup 來杭州啦！全新單元 Serverless Workshop 首次開張，召集 30 位 “愛動手” 的開發者！   本次沙龍特別邀請來自阿里雲、初創互聯網公司、開源中國 Gitee 的技術專家和獨立開發者，剖析 Serverless 的典型應用場景和案例，分享初創企業落地 Serverless 踩坑經驗和收穫，破解

企業邊緣應用面臨的挑戰 CDN是通過在全球範圍內分佈式地部署邊緣服務器將各類互聯網內容緩存到靠近用戶的邊緣服務器上，從而降低用戶訪問時延並大幅減少穿越互聯網核心網的流量。互聯網業務使用CDN已經成為一種必然的選擇。傳統網站防護基本上都是保護源站，客戶購買防火牆、WAF等產品就可以保護自己核心業務的內容不被惡意竊取。但傳統防護方式並不能完全滿足業務流量通過CDN分發的場景： 部署位置在源站前，主要為了保護源站。在CDN架構中，頁面基本都緩存在CDN上，爬蟲可以直接從CDN上直接爬走用戶敏感業務數據。 識別手段主要依靠在用戶頁面中嵌入JS，這種方式本質上修改了用戶的頁面，有很強的侵入性，並且只能適配web業務，針對api業務不生效。 處置手段一般通過頻次控制，對高頻的IP等特徵進行限制，這種方式容易被繞過，現在爬蟲基本都會採用IP代理池的方式，隨機修改請求的header字端，這樣很難找到特徵進行頻次控制。 CDN當前承接了主站大量業務，也必然要保證業務瀏覽和交易體驗，防止內容不被惡意竊取。越來越多的業務數據緩存在CDN的邊緣服務器上，邊緣安全的權重越來越高。而基於邊緣雲的機器流量管理應運而生，應對CDN邊緣安全隱患，實現用戶應用數據安全保護。 邊緣雲的機器流量管理的實現及優勢 基於CDN邊緣節點的機器流量管理分析及處理流程如下圖所示： 互聯網訪問一般分為用戶正常，商業搜索引擎訪問，惡意爬蟲訪問等，機器流量管理通過在邊緣提取請求報文特徵，基於報文特徵識別請求類型，在邊緣阻斷惡意爬蟲訪問，保護CDN上緩存資源不被惡意爬取。 機器流量管理的優勢如下： 基於CDN邊緣網絡架構實現機器流量管理能力，通過請求報文特徵識別域名的請求類型，區分是正常的請求還是惡意的機器請求，幫助用戶管理自己的請求，阻斷惡意請求。 通過識別域名的請求類型，實時標記出請求的報文類型，非常直觀的展示出當前的業務請求中的報文類型，客戶可以直觀的感知到自己的網站的訪問類型分佈情況，針對異常的報文類型進行處置。 通過處置報文類型而不是處置IP，只要惡意請求的報文類型不變，攻擊者隨機頭部字段或者使用秒撥代理IP池都無法繞過。 機器流量管理實際結果驗證 在雙11業務場景，機器流量管理針對訪問主站詳情頁的全部流量做識別，並對 Bot 流量進行細化分類。核心策略是放行搜索引擎等正規商業爬蟲，限制或攔截惡意爬蟲。 通過分析詳情頁的流量以及請求的行為特徵，分析出近40%的請求都是惡意訪問。在雙11前，通過開啟了處置策略，成功幫助主站某業務攔截了超過70%的爬蟲流量。下圖為開啟處置前後的流量對比情況，藍線為未開啟處置策略是的流量趨勢，綠線為開啟處置策略後的流量趨勢，攔截效果非常明顯，並且不影響實際業務運行。 雙11當日，基本上請求的訪問特徵沒有變化，最終攔截數億次惡意請求、上百萬惡意IP及數千萬惡意爬取商品ID。 CDN機器流量管理承擔更多主站業務的防護，並且發現部分爬取主站內容的請求可以透過防護策略，即爬取的請求行為發生了變化。通過對線上突增qps分析，定位出變異爬蟲主要使用的是IE的瀏覽器引擎，源IP大量使用秒撥代理IP，具有明顯的商業爬蟲特徵。經上報，快速形成了應急預案，快速對異常類型進行處置。

作者：李唯來源： 金融級分佈式架構公眾號 1. 引言 2019 年 Service Mesh 在螞蟻大規模落地並完美支撐雙十一核心鏈路，對於落地過程在去年已經有系列文章解讀。而在此之後的一年多時間，Service Mesh 在螞蟻又在如何演進呢。本文介紹螞蟻 Service Mesh 在雙十一落地之後所做的探索和思考。 2. 能力建設 得益於 Service Mesh 將業務和基礎設施解耦，在過去一年中我們的基礎設施能力得到了飛快的發展。大量能力大規模落地螞蟻，例如鏈路加密、可信身份認證、服務鑑權、自適應限流、集群限流、精細化引流、服務自愈等。這裡先對四個能力進行解讀，其它能力後續再有文章講述。

01 / 什麼是代碼加密？ 雲端加密代碼服務是雲效團隊的自研產品，是目前國內率先支持代碼加密的託管服務，也是目前世界範圍內率先基於原生Git實現加密方案的代碼託管服務。 通過在雲端對託管在雲效Codeup的代碼庫進行落盤加密，可以有效避免數據擁有者之外的人接觸到用戶的明文數據，避免數據在雲端發生洩露。同時，代碼加密過程對用戶完全透明，用戶可以使用任意官方Git端（包括但不限於Git、JGit、libgit2等）來訪問Codeup上的代碼倉庫。 02 / Linux社區重大安全性事件回顧 2011年8月底，用於維護和分發Linux操作系統的多臺服務器感染了惡意軟件，這些惡意軟件非常厲害，可以獲取root的訪問權限，修改其上的系統軟件以及登錄密碼。但社區的維護者稱，維護linux的源代碼，是未受到漏洞影響的。 這是為什麼呢？因為他們使用了Git進行代碼維護，對於linux內核代碼將近40000個文件來說，每個文件都做了hash來確保唯一性，因此很難在不引起注意情況下，更改舊的版本。 雖然Git可以解決開源社區關心的源碼篡改問題，卻解決不了企業擔心的數據洩露問題。而對於企業級代碼託管來說，今天所面臨的問題不但有數據安全、還有可靠性及成本問題。 當企業規模較小時，對可靠性要求也不高，一個自建的代碼託管服務似乎就能滿足需求。但隨著規模不斷擴大，代碼量不斷增加，可能需要更好的服務器配置，才能滿足多人協作的需求，甚至還需要投入專人維護來保證可靠性，這時就不得不思考成本的問題。 而云代碼託管服務，有著比自建代碼託管服務更高的可靠性及更低的成本，但相比自建代碼託管服務而言，由於其並不開放底層存儲的直接訪問，間接造成了用戶不可控的安全心理。 而代碼加密技術，正是通過將底層存儲的不可控變為近完全可控，解決用戶代碼上雲的顧慮。 03 / 自建真的比上雲更安全麼？ 在回答這個問題之前，讓我們一起來了解一些背景知識——Git的存儲結構。 當我們使用Git進行代碼提交時，最先接觸到的便是提交記錄及分支。分支或者標籤，可以統稱為引用。它們存儲在以路徑名作為引用名，以及對應版本hash作為內容的單個文件中。由於分支名通常與業務無關，所以可以認為，其中不包含敏感數據的。 除了提交記錄commit之外，我們的代碼文件被存儲到blob對象，文件名及目錄等信息，存儲到tree對象，帶有額外的信息的標籤被存儲到tag對象。 對象是Git中存儲數據的基本單元。通常情況下，對象存儲在以內容hash值命名的單個文件中，我們稱之為鬆散對象。而通過執行gc（也就是垃圾回收）之後，這些對象就會被打包到一起，生成一個打包文件packfile。代碼內容及文件名，都存儲在blob及tree對象當中，所以可以認為，對象中是包含用戶的代碼內容數據，也就是包含敏感數據的。 Git中的對象存儲，為了降低磁盤佔用，會通過zlib進行一次數據的壓縮。換句話說，只需通過解壓縮就可以獲取到數據內容，所以可以認為是明文存儲。也就是說，任意可以接觸到存儲的人，都可以查看存儲上的代碼數據。 明文存儲引發的信任問題

人體的免疫系統 無時無刻不在守護著我們的健康 雖然毫無感知 但組成免疫系統的各種器官、細胞幾乎每天都在聯合戰鬥 讓我們在充斥各種有害細菌和病毒的 世界安然無恙 如今 阿里雲也在努力構建雲的原生免疫系統 將安全基因植入每個產品和組件 實現基礎設施即安全 為解決單點問題而生的碎片化安全能力 因雲天然的一體優勢得以有機組合 無論是對抗外來風險還是防禦內部威脅 都能給用戶帶來無感的極致安全防護  如同人的免疫力從小到大在不斷變強一樣 雲的原生免疫力也是一個不斷生長的過程 如今，它長成了什麼狀態？ 可以有機組合解決什麼安全問題？ 提供哪些方面的安全守護？ 答案就在7月16日

本文整理自 Dell 科技集團高級軟件研發經理孫偉在 4 月 17 日 上海站 Flink Meetup 分享的《Iceberg 和對象存儲構建數據湖方案》，文章內容為： 數據湖和 Iceberg 簡介 對象存儲支撐 Iceberg 數據湖 演示方案 存儲優化的一些思考

隨著雲計算技術的不斷演進，產業互聯網的持續升級，政企從全面上雲進入雲上創新的數字化新基建的時代。旨在更全面的為雲化各階段政企服務，7月14日，阿里雲混合雲產品總監謝寧正式宣佈 Apsara Stack 重磅升級：企業版能力全面升級、敏捷版場景化新品發佈，為政企搭建上雲高速。 企業版能力全面升級 1） 一雲多芯 + 一雲多Region：阿里雲混合雲可以用同一套雲架構，支持不同種類的芯片和硬件服務器，用軟件能力屏蔽掉硬件的差異，使應用能夠無感知的快速上雲，滿足客戶多樣化的硬件平臺選型需求，同時支持多種芯片的服務器在一朵雲內進行混合部署。針對大型客戶多數據中心分散在不同物理區域但是需要統一管理的業務場景，一雲多Region通過部署位置物理分散，資源管理統一集中的模式，兼顧了區域化部署和全局管控的業務需求。 2） 安全合規能力：阿里雲混合雲成為國內首家通過商用密碼應用安全性評估的雲平臺。通過緊跟國家安全標準的要求，結合強大的自研能力，阿里雲混合雲可以為客戶提供一個安全無憂的企業級雲環境。 3） 全場景災備能力：阿里雲混合雲將兩地三中心的容災模式再升級，針對金融級客戶的極致災備要求，推出了同城三機房的容災能力，通過實現數據庫的三機房的工程化部署，實現了容災場景下RPO=0和自動切換的能力，最終保證了單機房出現機房級故障的額情況下，實現關鍵業務完全無損。這個能力已成功應用到國內某銀行客戶，並通過了實戰演練。 敏捷版場景化新品發佈 全新發布的敏捷版，聚焦典型場景：數據庫/雲原生PaaS/大數據；輕量化輸出：支持3臺服務器起步，小時級交付；靈活兼容：支持虛擬化部署和客戶網絡，更易被集成。 發佈會上，阿里雲數據庫高級產品專家陳招尚、阿里云云原生資深產品專家唐睿分別對敏捷版數據庫場景（DBStack）和敏捷版雲原生PaaS場景（CNStack），就行業趨勢、產品優勢、典型場景和最佳實踐等維度進行了深度解讀。 敏捷版數據庫場景（DBStack）產品矩陣 敏捷版雲原生PaaS場景（CNStack）產品矩陣 歷經10多年的快速發展，雲計算已然從一項新興技術逐步演變為數字經濟重要基礎設施。穩定安全、開放智能的混合雲是政企客戶數字化轉型的必由之路。 阿里雲混合雲（Apsara