雲計算

由多賬號上雲模式說起 多賬號上雲模式的產生 我們的企業客戶上雲，一般都是從嘗試部署少量業務開始，然後逐步將更多業務採用雲上架構。隨著企業上雲的進一步深入，越來越多的企業業務被放在了雲端，這使得企業採購的雲資源迅速增多，資源、項目、人員、權限的管理變得極其複雜，僅僅使用一個賬號，使得問題被放大，很難得到有效解決。單賬號負載過重已無力支撐，許多企業開始創建更多賬號以分散業務壓力。於是，許多企業選擇使用了更多賬號，對應其不同的業務。因此，從賬號的使用方面看，企業使用的賬號數量逐步增多，多賬號上雲模式逐漸成為多業務上雲的重要選項。 多賬號模式的優勢 諸多企業選擇採用多賬號模式上雲，也是由於多賬號相對單賬號而言，有著不可替代的優勢。 使用多賬號的邏輯強隔離，實現企業不同業務應用間的相互獨立 賬號與賬號之間默認是隔離的。這將避免不同業務間發生依賴項衝突或資源爭用，甚至可以支持為每個業務設置明確的資源限制。 利用多賬號分散風險，最大程度提升資源安全邊界，儘可能將危害降到最低 消除安全“核按鈕”。當非法用戶竊取到一個高權限時，“爆炸半徑”被限定到單個賬號內，而不影響企業所有業務。 輕鬆應對大型企業多分公司關係，支持多種法律實體、多種結算模式共存 每個賬號都可對應唯一一個法律主體，多賬號環境天然支持集團企業的多分公司主體、以及不同業務的不同結算模式。 多賬號易於結構化管理，業務的拆分和融合變得簡單 業務過多導致“臃腫”不利於管理，業務間也非扁平形態，存在業務關聯的“組織性”要求，單個賬號很難解決，多賬號卻易於實現；同時，藉助賬號的獨立性，它們可輕鬆地拆分或融合於不同的管控域，與企業業務適配聯動。 多賬號架構的挑戰 多賬號的採用，如果不去有序的管理它，也會有很多麻煩。 比如，賬號散落沒有集中、沒有結構化，就無法做到組織化管理。再比如，上層管理者如何能夠一眼全局、如何能夠集中管控，都是影響企業業務效率的問題，需要解決。 無序管理的多賬號一盤散沙，有序管理是企業多賬號模式促進生產效率的第一要務。 從多賬號組織化問題看，阿里雲的資源目錄產品，可以很好地解決多賬號有序管理問題。這是資源目錄的基礎能力之一。 資源目錄是阿里雲面向企業客戶，提供的基於多賬號的管理與治理服務。詳細瞭解資源目錄 大家可以看到，上圖中，利用資源目錄的組織能力，企業可以很快的構建屬於自己的業務架構，將企業多賬號按照業務關係聚合，形成結構化易管理的形態，並提供閉環的企業雲資源管理服務，以此來適配業務的管理需要。 […]

2021 年 6 月 4 日，由中國信息通信研究院（以下簡稱“中國信通院”）主辦的 “2021 雲邊協同大會”在北京舉行。本次會議以“開啟分佈式雲新時代”為主題，旨在搭建數字經濟與 5G 時代下雲服務與邊緣計算融合發展的橋樑，並面向行業發佈多項雲邊協同發展階段性成果。其中，阿里雲邊緣容器服務 ACK@Edge 獲得“2021 雲邊協同能力”標準認證，在邊緣容器技術能力要求的 33 項測評中全部通過；基於 ACK@Edge 實現的申通快遞 IoT 雲邊端架構，入選“2021 分佈式雲與雲邊協同十佳實踐案例”。

往期技術一號位方法論系列文章： 「技術人生」第1篇：什麼是技術一號位？ 「技術人生」第2篇：學會分析事物的本質 「技術人生」第3篇：解決問題的規律總結 本期文章篇幅較長，建議收藏閱讀。 背景 本期文章將接上期《「技術人生」第3篇：解決問題的規律總結》繼續探討技術、業務、組織的一般規律及應對策略。需要注意的是，以下內容為個人實踐結果的總結和分析，受限於個人能力和經驗有限，在描述規律的過程中，可能會存在維度的缺失；或者當前描述的規律所涉及的維度並不是某些讀者認知中的重點，因為事物不同的維度在不同角色和級別的人的認知中重要程度不同，即：PD和研發對於同一件事情的側重點不同；P6到P11對於同一件事情，很大概率看重的側重點不同，我們特別歡迎不同層次的同學分享你眼中的規律出來指引其他人實踐。 而對於今天本文接下來要討論的內容，需要大家辯證地去看待，並且在討論初始需要重新對齊當前事物的討論範圍：當前對組織、業務和技術的規律的探討，限定在“技術團隊leader帶領研發團隊負責某個業務或負責某個業務的一部分”的情況下，“技術”一詞指代研發人員使用的信息化技術；“業務”一詞指代研發人員使用信息化技術解決的問題域的統稱，“組織”一詞指代技術團隊 Leader 帶領的團隊（可能是跨團隊的組織）。 同時仍然需要注意的是： 上述範圍中提到的組織、技術、業務沒有加上“規模”相關的限制，可以理解為，任何規模都符合下面探討的規律，即我們探討的是一般規律。同時，不同規模，即團隊規模、業務規模、技術深度本質上都是特殊條件，特殊條件的存在可能會觸發特殊的規律，但是還是那句話，特殊規律存在並不影響對一般規律的討論。並且受限於本人當前實際的實踐情況，不同規模所觸發的特殊規律並沒有全部都直觀感受過（實踐缺失），也沒有看過類似的書籍（理論輸入缺失），所以不在本文內進行相關特殊規律的探討。不排除未來有了更多的實踐會來完善，同時更歡迎有實踐經驗的人整理總結成規律分享出來。 上述範圍中提到的分析問題的主體是技術 leader，所以對於其他角色類型的同學而言，探討之後形成的結論需要辯證地去理解，可能有很大部分都是相通的（注意不是相同，而是相通，意味可以相互借鑑），但是同時也有一部分是不適用的，是和探討的主體本身的特殊性相關的。而這種特殊性對於其他類型的角色並非沒有意義，恰恰相反，這可能是比較宏觀地、直接地瞭解另外一種角色的非常有效的途徑。即運營一號位或產品一號位或業務一號位可以看到技術一號位所負責的事情中的一般規律和特殊規律，而一般規律大概率相通，而瞭解特殊規律是理解彼此差異性的在宏觀層面的認知。 業務的發展規律及應對策略 業務的發展規律 業務的生命週期如下圖所示： 看圖時，需要注意以下內容： 圖中的曲線僅用於定性分析，非定量分析的精確圖表，因此生命週期中各階段的長度、和業務規模、利潤規模的比例關係也都是示意型的，而非精確的比例關係。不同的業務，生命週期長短可能不同，各階段持續的時間也不同，業務方期望各階段持續時間長短也不同，需要具體問題具體分析。不同的業務，利潤出現的時間和業務生命週期的階段對應關係不同，利潤規模和生命週期各階段對應關係也不同，需要具體問題具體分析。 在此基礎上，我們簡單用語言講清楚業務發展過程是怎樣的：

Dubbo Dubbo介紹 Dubbo是輕量級，高性能的RPC框架，並不是一個微服務的全面解決方案，由Java語言開發。 RPC的介紹 RPC: 遠程過程調用 在早期單機時代：IPC:單機裡各個進程間的相互通信到了網絡時代：把IPC擴展到網絡上，就叫做了RPC。也就是通過socket、IO通信和傳輸 調用其他機器上的程序和調用本地程序一樣方便 常見的RPC框架：Dubbo、Montan（新浪，輕量級）、Thrift（Facebook，可以跨語言） HTTP和RPC對比： HTTP和RPC都是用來通信的。但是HTTP有許多規定：請求頭組成、傳輸的要求等，效率較低。RPC效率較高，減少資源消耗。 傳輸效率: RPC方式可以自己進行定製，HTTP包含了許多無用的信息，導致效率低 性能消耗，主要是在於序列化和反序列化的耗時。 RPC採用二進制高效的傳輸，HTTP多采用JSON的格式進行傳輸，JSON轉為具體的對象比較耗時。 負載均衡：Dubbo在調用時發現如果有多個服務方可以進行負載均衡，採用隨機 、輪詢等方式HTTP可能會藉助外部的組件。如nginx進行負載均衡，自身對這個能力比較欠缺。 Dubbo工作原理 角色 Provider：服務的服務提供者

文章來源：雷鋒網 作者：楊麗 原標題：《獨家解讀：阿里雲原生應用的佈局與策略》 原文鏈接：https://www.leiphone.com/category/industrycloud/nBx5G5lhmwof2RtY.html 受訪人 | 丁宇 出品 | 雷鋒網產業組 進化到這一階段，雲原生使得客戶的數字化轉型路徑不斷縮短。如果說雲原生時代一切是以客戶視角為出發點，那麼進一步拆解就是圍繞客戶的業務場景、系統架構，而不再是過去堆人、費力的方式。如何正確引導客戶共同享受到雲原生的技術紅利？丁宇，花名叔同，阿里巴巴研究員、阿里雲智能雲原生應用平臺負責人，他所看到且給出的，也許不是客戶數字化轉型的唯一方案，但卻是經過阿里雲多年實踐得出的對某類問題的最優解。 回顧過去十五年，阿里巴巴的雲原生實踐伴隨著集團業務規模和支撐場景複雜度的與日俱增。對內，阿里淘寶作為全球最大的電商交易平臺，每年雙11電商業務帶來的都是極大的技術挑戰；對外，阿里雲支撐了全球300萬的企業客戶數，幫助客戶解決問題的同時也會關注其業務的發展。實際上，每一階段不同問題的出現，也是阿里自身產品技術突破的創新引擎。 如果對這十五年的阿里雲原生實踐變遷做個拆解，那麼一定離不開這個邏輯：自研-自用-上雲開放。 第一階段：2006年-2011年，淘寶商城從集中式架構切換到微服務分佈式架構，核心解決高可用性和穩定性的問題。 第二階段：2011年-2015年，開始投入做容器，以解決成本和運維效率的問題。 第三階段：2015年-2019年，推進產品技術的全面商業化，全面擁抱雲原生的標準。 第四階段：2019年-至今，從支撐雙11核心系統全面上雲，到支撐核心系統全面雲原生化。 可以說，阿里巴巴趕上了兩個紅利，一是互聯網規模經濟的紅利；二是雲計算的紅利。通過不斷解決在這些紅利中遇到的問題，才有可能讓阿里巴巴打造這些產品，並有機會全面升級下一代雲原生技術，不斷反哺給客戶。 然而，並非所有的企業都有機會和時間（窗口期）來接觸和塑造自身業務的雲原生能力。 “沒有云原生之前，只有能力極強的企業可以解決這個問題，但隨著雲原生的出現，每家企業都可以實現對雲和極致彈性能力的調取，這是一個普適性紅利的釋放。”丁宇說道。 目前，阿里雲有300+款雲原生產品，上千個解決方案，為企業數字創新提供全方位能力支撐。 以容器技術為代表，因與雲的結合，能夠向下屏蔽基礎設施的差異性，成為雲服務調用的新界面，向上又可以支撐各類產品。

2021年6月9日，亞太內容分發大會暨CDN峰會在北京舉行，阿里雲智能邊緣雲技術專家李松林受邀參加互動直播論壇，分享基於阿里雲邊緣雲節點打造的全球實時傳輸網絡GRTN的設計思路、技術原理、特質與應用實踐，以及面向直播應用客戶提供穩定可靠的業務體驗。 當前，主流的直播技術應用架構主要有兩種：直推和回源拉流 ，產生這兩種架構的原因也比較簡單：一是業務場景需要連麥，需要低延遲雲合流；二是基於UDP的私有協議推流。為保障主播在弱網情況下能有較好的推流效果，而最重要的原因是目前主流雲廠商還沒有通用成熟的低延遲互動場景大規模應用的服務，這就導致了他們需要自建源站。只使用雲廠商通用的分發能力。支持 HTTPFLV 、RTMP 、HLS 大規模分發。 視頻直播服務自建面臨的挑戰 隨著直播場景和內容越來越豐富和專業，互動的需求也越來越多，交互的延遲要求也越來越高。原有的這套架構就很難滿足需求了。由於無法滿足自己的業務需求，許多企業客戶紛紛開始嘗試自建源站，做協議優化， 但是由於直播技術門檻相對較高，不僅需要投入資源，還需要專業的研發能力，同時後續還要長期持續運維和管理。 阿里雲GRTN的定位 為了能夠降低直播的端到端延時，阿里雲從直播、短延時直播、RTC等應用場景出發，構建了GRTN（Global Realtime Transport Network）全球實時傳輸網。李松林介紹，阿里雲GRTN的定位是基於公共雲中心Region和邊緣雲節點，構建超低延時、全分佈式下沉的通信級流媒體傳輸網絡。GRTN目前融合了互聯網直播和RTC等多種業務場景的音視頻流傳輸和交換。基於GRTN的短延時直播RTS可以支持標準H5 WebRTC推播，在千萬級併發情況下延時可以控制在1s以內；RTC端到端延時可以控制在250ms左右。GRTN可提供三大原子能力：流的發佈、訂閱、切換，用戶可以基於這些能力構建通話場景、直播場景、連麥場景等等。 阿里雲GRTN的架構 阿里雲GRTN 的整體架構是由原來的直播體系進化而來。該架構具有控制和數據分離、混合組網、多路徑傳輸、自學習Qos等技術特點，對外可以支持多種接入協議(rtc /rtmp

2021年6月9日，亞太內容分發大會暨CDN峰會在北京舉行，阿里雲智能邊緣雲高級技術專家李忠仁受邀參加邊緣加速論壇，分享了阿里雲基於邊緣雲節點打造新一代CDN產品能力、技術架構及創新實踐，助力企業提升效率、優化經營，推動更多新興行業場景的創新發展。 李忠仁介紹，阿里雲CDN起源於淘寶CDN，自2009年開始便伴隨雙11逐步成長，為流量巨大的電商網站提供加速支持，在全球建立了上百個優質節點和帶寬資源，起初在電商領域得到了很多的應用和實踐。2011年，CDN作為互聯網流量分發基礎設施，逐步從服務淘寶電商，擴展到全面服務阿里集團生態，在應用場景上外延。2014年，阿里雲CDN正式宣佈對外商業化，將服務能力開放給全球企業及創業者使用。2015年，阿里雲CDN與電商攜手邁進全站HTTPS時代，並不斷進行自研調度系統的迭代升級以應對指數增長的流量衝擊。伴隨著每年雙十一以及移動互聯網、視頻的普及，CDN的流量呈現指數級增長。2017年，阿里雲CDN開啟全球化戰略，並陸續發佈SDCN、DCDN等產品，產品矩陣全面升級。2018年初，由Gartner發佈的全球CDN服務市場指南《Market Guide for CDN Services》中，阿里雲憑藉全球服務能力和產品技術優勢定為Global（全球級）服務商。近幾年，阿里雲CDN圍繞“智能化”和“可計算”不斷進行產品技術深耕，在邊緣Serverless、多維Workload負載均衡、科學決策、各類邊緣應用場景服務上持續打磨。與此同時，阿里雲CDN憑藉更高效率的產品服務與優質的服務體驗贏得客戶信賴，在CDN領域體量不斷擴大，發展迅猛，CDN的峰值流量規模屢創新高。截止目前，阿里雲CDN在全球有2800+邊緣節點，150+T帶寬儲備，服務全球數十萬企業客戶，為超百萬域名提供加速服務。阿里雲CDN打造的一張連接全球終端用戶的邊緣生態網絡，在晚高峰期間每秒處理上億QPS的用戶連接請求，每天將客戶數十億次配置管理指令下發到全網所有節點。 CDN行業發展與演變 CDN的發展主要經歷了三個大的階段：第一個階段是以圖文內容消費為主的階段， 大家上網主要使用PC， 訪問的主要是門戶網站等含有大量圖文的內容； 第二個階段是圖文+視頻內容消費為主的階段， 直播、短視頻、長視頻的普及， 帶領CDN進入了快速增長期， 帶寬每年成倍的增長。但第二個階段爆發式增長期已經過去， 帶寬的增長已經放緩， 第二個階段即將結束。 第三個階段現在正處於醞釀期， 隨著5G、IoT的發展， 物聯網設備大範圍普及， 越來越多的設備會接入網絡，

近日，北京奧星貝斯科技有限公司（以下稱 “OceanBase”）與神州數碼舉行了合作簽約儀式。OceanBase CEO 楊冰先生、神州數碼 EBG 總裁吳昊先生帶領雙方團隊出席簽約儀式。 ​   近年來，國產數據庫的發展和崛起有目共睹。OceanBase 作為一款螞蟻集團自研的原生分佈式數據庫，曾在數據庫領域權威測試 TPC-C 中獲得世界第一，具有數據強一致、高可用、高性能、在線擴展、高度兼容 SQL 標準和主流關係數據庫、低成本等特點。2020 年 6 月 1 日，螞蟻集團正式成立北京奧星貝斯科技有限公司，邁出 OceanBase

近日，在數據庫OceanBase3.0峰會上，螞蟻集團自主研發的分佈式數據庫OceanBase首次從技術、商業和生態三個維度對未來發展戰略進行了系統性闡述。同時，OceanBase宣佈正式開源，併成立OceanBase開源社區，社區官網同步上線，300萬行核心代碼向社區開放。 未來三年專注核心分佈式改造 CEO楊冰表示，OceanBase將持續堅持自研開放之路，在未來3年內，專注企業核心分佈式改造。同時，宣佈釋放科技紅利，7月啟動全新價格體系，公共雲版本將推出價格更低的存算分離版本。 此次推出的最新3.0版本產品，讓OceanBase同時具備了在事務處理和數據分析兩類任務的高性能能力，升級為一款支持 HTAP 混合負載的企業級分佈式數據庫。和過去相比，事務處理性能提升50%，數據分析性能提升10倍。未來，用戶業務無論是事務型還是分析型，只要一套系統就可以應對數字化轉型過程中“海量、實時、在線”的業務需求。 Gartner 認為， HTAP （Hybrid Transactional/Analytical Processing，即混合事務 / 分析處理）數據庫將成為數據庫領域的重要發展趨勢，一個集成的數據平臺將會加速數字化轉型。 在各個領域深化數字化轉型過程中， 核心系統的分佈式改造是非常關鍵的一環。過去一年的合作案例顯示，隨著自主研發分佈式技術的逐步成熟，不斷應用、優化和完善，OceanBase幫助客戶進行核心系統數字化改造時，在可靠性、可擴展性等方面的優勢越來越明顯。 楊冰透露，“在當前規模和技術紅利基礎上，我們希望以更低的價格與門檻，給予客戶更強的數據庫能力進行核心系統的分佈式改造。核心系統改造不僅能讓企業實現整體系統完全自主掌控。更能在業務穩定性、連續性不降低的前提下，支撐業務敏捷，最後達到每單筆交易/每個賬戶成本下降的目標”。 開源300萬行核心代碼 大會現場，CEO楊冰還宣佈自研數據庫OceanBase正式開源，併成立OceanBase開源社區，社區官網同步上線。 據瞭解，開源已經上升為OceanBase重要的技術戰略。OceanBase數據庫創始人陽振坤錶示，螞蟻自研數據庫OceanBase致力於打造企業級開源數據庫，同時與合作伙伴一起緊密合作，快速發行商業版本，滿足行業客戶對數據庫高性能、高可靠、融合處理的業務訴求。

一口氣了解阿里雲現場的重磅宣佈 飛天再進化：一雲多芯、本地 Region、計算巢 在主會場的演講中，阿里雲基礎產品負責人蔣江偉公佈了飛天操作系統最新的進化方向：一雲多芯、本地 region、計算巢。蔣江偉表示，飛天是中國唯一的自研雲操作系統，阿里雲將堅持 “做深基礎” 的技術戰略，從飛天雲操作系統向下延伸定義硬件。 在能力提升的同時，飛天提供了豐富的部署形態。首先，阿里雲推出本地 region 服務，讓公共雲從中心 region 延伸到本地 region，增加覆蓋密度，滿足客戶對於低延時、區域網絡覆蓋的訴求。本地 region 將部署在南京等十餘個地域，提供計算、存儲、數據庫等 40 多種雲產品。同時，本地 Region 的本質仍是公共雲，擁有一致的操作體驗，開發人員無需擔心延遲和性能之間折中的限制。 其次，阿里雲推出邊緣雲節點，不僅可用於內容分發、視頻點播，更適合視頻直播、在線教育、雲遊戲等對時延要求極高的場景。在原有