資安

簡介 Blowfish是由Bruce Schneier在1993年發明的對稱密鑰分組加密算法，類似的DES和AES都是分組加密算法，Blowfish是用來替代DES算法出現的，並且Blowfish是沒有商用限制的，任何人都可以自由使用。 對比而言，雖然AES也是一種密碼強度很高的對稱密碼算法，但是如果需要商用的話要向NIST支付授權費用。 blowfish詳解 blowfish和DES一樣，使用的是feistel密碼來進行分組加密。blowfish的分組塊大小是64bits,可變密鑰長度可以從32bits到448bits不等。 blowfish需要進行16輪的feistel加密操作，我們先從下圖大致感受一下blowfish算法的加密流程： 大概的流程就是將P(原始數據)分成左右兩部分，先拿左邊的部分和Kr 做異或操作，得出的結果調用F函數，最後將F函數的輸出結果和右半部分進行異或操作。 調換左右部分的位置，繼續進行這樣的操作，總共進行16輪就得到了最終的加密結果。 大家可以看到整個加密過程中最重要的兩個變量就是Kr 和 F函數。 接下來我們會詳細進行講解。 密鑰數組和S-box 密鑰數組 從圖上我們可以看到，Kr 的範圍是從K1 到 K18 […]

前言 SLS是一站式的雲原生可觀測分析平臺，用戶可以將Log, Metric, Trace數據接入到SLS；根據業務的需要，用戶可能將數據存儲在不同的賬戶、地域、Project下，在對數據進行監控分析時，如果只能對特定Project或者特定區域進行監控，往往會有一定的侷限性，SLS智能告警可以提供跨Project，甚至跨地域，跨賬號的監控，然後對告警進行統一降噪管理，通知管理等；實現對SLS資源的全局監控。 本文將介紹如何使用SLS智能告警來進行全局監控，介紹全局監控需要的查詢的三種授權方式，並通過一個跨賬號監控的例子來介紹如果進行全局監控。 全局監控概述 在SLS中可以將不同雲產品的日誌存儲在SLS中，在不同的主賬號下都可以有這些雲產品的日誌，除了雲產品的日誌，每個主賬號下也會有個字的系統，中間件，服務的日誌；對於一個企業來說，可能會因為業務的需要，使用不同的主賬號來管理企業在阿里雲的日誌資源。SLS智能告警提供了一種對不同主賬號下日誌資源的全局監控機制，允許對不同賬號，不同區域下的Project進行統一監控，不需要將數據同步到某一個特定的賬號或者區域下面。 舉例來說，比如某企業有主賬號A和主賬號B分別接入了各類雲產品日誌和業務日誌，對這些日誌的監控告警運維是專門的運維團隊進行負責，比如有一個主賬號C，每天監測被審計賬號A、B的每日訪問日誌量正常，這時候就需要用到了跨賬號、跨Project的查詢；對查詢的數據統一建立告警規則，統一進行告警的降噪管理，通知管理和事務管理。 使用SLS智能告警進行全局監控，會涉及到對不同賬號不同區域的資源的授權，比如上述例子中的主賬號C需要有賬號A、B的授權才可以對其資源進行監控查詢，以下將對告警權限和授權方式進行介紹。 告警規則權限 SLS智能告警的權限包括兩部分 告警規則的管理權限 監控目標的查詢權限 在SLS智能告警-訪問控制與授權一文中，我們主要介紹了創建告警規則的管理權限，對於監控目標的查詢權限直接使用了創建告警規則實體（RAM用戶或者主賬戶）本身被賦予的權限。監控規則實體的權限在使用上會有一定的限制，只能對當前Project下的不同Logstore進行查詢。如果需要進行跨Project，跨賬號的查詢需要使用告警查詢的授權方式。 告警查詢授權方式 告警查詢的授權方式主要包括三類： 默認：是指訪問控制與授權文中使用的默認查詢權限，只能查看當前告警規則所在Project下的資源。 內置角色：使用SLS內置的角色AliyunSLSAlertMonitorRole進行查詢，可以進行跨Project的查詢，只有點擊授權即可，操作簡單。 自定義角色：對於查詢可以使用更精細的控制，支持跨賬號，跨區域，跨Project的查詢。 在介紹三種授權方式之前，先來看下阿里雲RAM角色，RAM角色（RAM

作者｜ 修冶 背 景 ​微服務在最近幾年大行其道，很多公司的研發人員都在考慮微服務架構，同時，隨著 Docker 容器技術和自動化運維等相關技術發展，微服務變得更容易管理，這給了微服務架構良好的發展機會。​在做微服務的路上，拆分服務是個很熱的話題。我們應該按照什麼原則將現有的業務進行拆分？是否拆分得越細就越好？接下來一起談談服務拆分的策略和堅持的原則。​ 拆分目的是什麼？ ​在介紹如何拆分之前，我們需要了解下拆分的目的是什麼，這樣才不會在後續的拆分過程中忘了最初的目的。​拆分的本質是為了將複雜的問題簡單化，那麼我們在單體架構階段遇到了哪些複雜性問題呢？首先來回想下當初為什麼選用了單體架構，在電商項目剛啟動的時候，我們只希望能儘快地將項目搭建起來，方便將產品更早的投放市場進行快速驗證。在開發初期，這種架構確實給開發和運維帶來了很大的便捷，主要體現在：​ 開發簡單直接，代碼和項目集中式管理。 排查問題時只需要排查這個應用就可以了，更有針對性。 只需要維護一個工程，節省維護系統運行的人力成本。 但是隨著功能越來越多，開發團隊的規模越來越大，單體架構的缺陷慢慢體現出來，主要有以下幾個方面：​在技術層面，數據庫的連接數成為應用服務器擴容的瓶頸，因為連接 MySQL 的客戶端數量是有限制的。​除此之外，單體架構增加了研發的成本抑制了研發效率的提升。比如公司的垂直電商系統團隊會被按業務線拆分為不同的組。當如此多的小團隊共同維護一套代碼和一個系統時，在配合的過程中就會出現問題。不同的團隊之間溝通少，假如一個團隊需要一個發送短信的功能，那麼有的研發同學會認為最快的方式不是詢問其他團隊是否有現成的，而是自己寫一套，但是這種想法是不合適的，會造成功能服務的重複開發。由於代碼部署在一起，每個人都向同一個代碼庫提交代碼，代碼衝突無法避免；同時功能之間耦合嚴重，可能你只是更改了很小的邏輯卻導致其它功能不可用，從而在測試時需要對整體功能迴歸，延長了交付時間。模塊之間互相依賴，一個小團隊中的成員犯了一個錯誤，就可能會影響到其它團隊維護的服務，對於整體系統穩定性影響很大。​最後，單體架構對於系統的運維也會有很大的影響。想象一下，在項目初期你的代碼可能只有幾千行，構建一次只需要一分鐘，那麼你可以很敏捷靈活地頻繁上線變更修復問題。但是當你的系統擴充到幾十萬行甚至上百萬行代碼的時候，一次構建的過程包括編譯、單元測試、打包和上傳到正式環境，花費的時間可能達到十幾分鍾，並且任何小的修改，都需要構建整個項目，上線變更的過程非常不靈活。​而這些問題都可以通過微服務化拆分來解決。​為了方便你更好的理解這塊，在此附上一份表格（內容來源：《持續演進的 Cloud Native：雲原生架構下微服務最佳》一書），可以更直觀地幫助你認識拆分的目的。​ 拆分時機應該如何決策？ ​產品初期，應該以單體架構優先。因為面對一個新的領域，對業務的理解很難在開始階段就比較清晰，往往是經過一段時間之後，才能逐步穩定，如果拆分過早，導致邊界拆分不合理或者拆的過細，反而會影響生產力。很多時候，從一個已有的單體架構中逐步劃分服務，要比一開始就構建微服務簡單得多。同時公司的產品並沒有被市場驗證過，有可能會失敗，所以這個投入的風險也會比較高。​另外，在資源受限的情況下，採用微服務架構很多優勢無法體現，性能上的劣勢反而會比較明顯。如下圖所示。當業務複雜度達到一定程度後，微服務架構消耗的成本才會體現優勢，並不是所有的場景都適合採用微服務架構，服務的劃分應逐步進行，持續演進。產品初期，業務複雜度不高的時候，應該儘量採用單體架構。​ 隨著公司的商業模式逐漸得到驗證，且產品獲得了市場的認可，為了能加快產品的迭代效率快速佔領市場，公司開始引進更多的開發同學，這時系統的複雜度會變得越來越高，就出現單體應用和團隊規模之間出現矛盾，研發效率不升反降。上圖中的交叉點表明，業務已經達到了一定的複雜度，單體應用已經無法滿足業務增長的需求，研發效率開始下降，而這時就是需要考慮進行服務拆分的時機點。這個點需要架構師去權衡。筆者所在的公司，是當團隊規模達到百人的時候，才考慮進行服務化。​當我們清楚了什麼時候進行拆分，就可以直接落地了嗎？不是的，微服務拆分的落地還要提前準備好配套的基礎設施，如服務描述、註冊中心、服務框架、服務監控、服務追蹤、服務治理等幾大基本組件，以上每個組件缺一不可，每個組件展開又包括很多技術門檻，比如，容器技術、持續部署、DevOps

路由合併概述 SLS的告警策略包含三種子策略： 路由合併 抑制 靜默 其中最重要的就是路由合併策略。簡而言之，路由合併的作用就是：告警經過一定的規則，合併成不同的合併集合，統一進行通知的發送。它的最大的優點就是可以進行告警的降噪，由於是合併後統一發送，因此可以有效避免告警風暴的產生。 可以參考如下的簡單示例： 一共產生了四個告警，它們經過路由合併之後，變成了三個合併集合，其中Alert-1和Alert-3在一起，會被一起發送通知。當然這只是一個非常簡單的示意，可以簡單理解為這裡根據的是不同的顏色進行了合併。在實際的使用場景中，可以根據告警自身的多種屬性進行策略的配置，例如把相同嚴重度的告警合併在一起，或者把同一個Project產生的告警放在一起，等等。在瞭解了路由合併的基本作用之後，接下來我們來看路由合併的一些詳細使用。 告警指紋 在對路由合併進行深入的瞭解之前，我們需要先來認識一下告警的指紋。簡單來說，每個告警都需要有一個唯一的身份證號，需要我們來識別它。 例如 08:00 產生了一條告警，說的是 192.168.1.100 這臺機器 CPU 使用率過高，達到了 90%；然後再 08:05 繼續產生了一條告警，說

簡介 生日攻擊其實是一個概率論的問題，也就是說一個看起來很難發生的事情，事實上它發生的概率卻很大。這種主觀上和事實上的概率差距，讓隨機攻擊成功的機率變的更高，這樣的攻擊就叫做生日攻擊。 生日問題的由來 生日問題也叫做生日悖論，它是這樣這樣描述的。 假如隨機選擇n個人，那麼這個n個人中有兩個人的生日相同的概率是多少。如果要想概率是100%，那麼只需要選擇367個人就夠了。因為只有366個生日日期（包括2月29日）。 如果想要概率達到99.9% ，那麼只需要70個人就夠了。50%的概率只需要23個人。 對於現在的幼兒園小朋友來說，一個班上差不多有30人，那麼將會有大於50%的機率，班上有兩個人的生日是一樣的。 聽起來是不是很神奇？跟我們第一映像中的基數是不是要少很多。 我們看一張概率圖： 在實際應用中，可以應用生日問題中的概率模型，從而減少碰撞攻擊的複雜度，或者來評估一個hash函數中可能出現碰撞攻擊的機率。 怎麼計算呢？ 假如P(A) 是生日相同的概率，那麼P(A) = 1 – P(A’) ，其中P(A’)是生日不同的概率。 一個人生日不同的概率是365/365,兩個人生日不同的概率就是365/365

簡介 feistel cipher也叫做Luby–Rackoff分組密碼，是用來構建分組加密算法的對稱結構。它是由德籍密碼學家Horst Feistel在IBM工作的時候發明的。feistel cipher也被稱為Feistel網絡。 很多分組加密算法都是在feistel cipher的基礎上發展起來的，比如非常有名的DES算法。 在feistel cipher中，加密和解密的操作非常相似，通常需要進行多輪加密和解密操作。 Feistel網絡的原理 Feistel網絡中會用到一個round function也叫做輪函數，這個函數接收兩個輸入參數，分別是分組數據（原始數據的一半）和子key，然後生成和分組數據同樣長度的數據。 然後使用上一輪生成的數據和原始數據的另一半進行XOR異或操作，作為下一輪輪函數的輸入。 就這樣一輪一輪進行下去最後生成加密過後的數據。 解密的流程和加密的流程是類似的，只不過把加密的操作反過來。 Feistel網絡的輪數可以任意增加。不論多少輪都可以正常解密。 解密與輪函數f無關，輪函數f也不需要有逆函數。輪函數可以設計得足夠複製。 加密和解密可以使用完全相同的結構來實現。從上面我們講到的可以看到，加密和解密其實是沒有什麼區別的。 Feistel網絡的例子 我們用一個圖的方式來介紹一下Feistel的工作流程：

想要了解人工智能的發展，或者瞭解人工智能的基本應用，就需要先了解一些基本概念，首當其衝的就是對人工智能的理解。 一、人工智能的發展首先要明白人工智能並不是這幾年才出現的一個新概念，人工智能最早誕生於1956年美國的達特茅斯會議上，它的發展也經過了多次起起伏伏。只是這幾年人工智能的落地應用比較廣泛，所以才會出現在普通民眾眼前。按照人工智能的字面意思是人創造的智能，人工固然好理解，那麼什麼才算是智能？眾說紛紜。 二、人工智能的分類按照人工智能的廣義概念分析，最早的計算機也是是人工智能的一種，只是計算機剛被髮明出來的時候是被用來存儲和計算數據的，所以那個時代的智能被稱為運算智能。隨著後期技術的發展，來到了感知智能時代，也就是我們目前所處的時期，感知智能的特點是對外界所看的事物能夠自我感知，並且給出反饋。但是這還遠遠達不到真正的智能，因為真正的智能是需要自我思考，擁有一定的推理認知能力的，所以接下來的時代被稱為認知智能時代，之所以稱之為認知智能，就是要計算機程序擁有一定的認知能力，這個時候的計算機不但能夠對外界的事物進行感知，而且還具有一定的推理決策能力，可以根據當前感知到的圖像、語音、語言等信息進行綜合考慮，選擇接下來要執行的行為。當然這依然不是人工智能的最終形態，人工智能的最終形態被稱為創建智能，顧名思義，這個時候的人工智能擁有一切人類所擁有和沒有的智能，它不但本身是一個超級智能體，而且還能創造出數個智慧等同於自己的智能體。不同階段的智能在行業中的薪資待遇也是大不一樣。 當然人工智能的分類從智慧等級上還可以分為弱人工智能、強人工智能、超人工智能。既然有弱有強又有超強，參照對象是什麼？不然怎麼能夠得出強弱的結果呢？既然叫做人工智能，就是人造出的智能，那麼參考對象也就是人類了。一般來說整體能力比人類弱的被稱為弱人工智能，整體能力和人類一樣的被稱為強人工智能，整體能力超過人類的被稱為超人工智能。注意這裡說的是整體能力，而非單項能力，2016年由谷歌（Google）旗下DeepMind公司戴密斯·哈薩比斯領銜的團隊開發的阿爾法圍棋（AlphaGo），在下圍棋這個單項技能上已經遠超人類，但是它依然算不上是強人工智能，因為在其他方面，它依然比不過人類。 可能有人會說，我可以讓它再學習畫畫、寫字等等，反正等它學會了人類所有的技能不就能超越人類了，理想確實是豐滿的，但現實往往很骨感。由深度學習主導的深度神經網絡雖然非常強大，強大到在一些領域已經超越人類，但是由於龐大的矩陣參數是通過學習而慢慢調整固定下來的，而這個固定的目標就是給它指定的結果。一旦這個指定的結果發生了變化，模型就要重新學習，參數也會發生變化，所以最終的結果就是你給它學習畫畫，它確實學會了畫畫，但是由於參數發生了變化，它現在只會畫畫了，之前學到的下棋技能已經不復存在了，也就是說它學會了畫畫，遺忘了下棋，這種現象在業內被稱為災難性遺忘，目前還沒有哪一家公司或者研究機構能夠解決這個問題，因為這個問題一旦被解決了，人類也就跨向強人工智能時代了，所以現在我們還處於弱人工智能時代，對於整個人工智能發展階段而言，我們所處的階段正處於人工智能的嬰幼兒時期。 至於超人工智能，有人說，到那時人類所設的規則對於AI來說都是有漏洞的，最終人類將會被AI所奴役，就像機器人三定律一樣，對於認知遠超人類的AI來說，推翻整個定律是很輕鬆的。當然目前我們面臨的問題是怎麼進入到強人工智能時代。這就像一個人還處於少年時期就思考老年時怎麼生活一樣，那不是我們目前該考慮的問題。 三、人工智能的實現方法實現人工智能方法目前可以大概分為兩類，有基於傳統統計學的統計學模型（也稱傳統機器學習方法），基於仿生學神經網絡的深度學習模型，前者曾在上世紀九十年代大放異彩，但是隨著21世紀以來，硬件的加速迭代和海量數據的增加，給了深度學習發展的機會，2006年由Hinton等人研究出的一些新的模型應用正式揭開了人工智能時代發展的新篇章，由深度學習為代表的一眾算法模型在效果和效率上都首次超過了傳統的統計學模型，而且深度學習在落地應用上更是大放異彩，不像以前的統計學模型，大多隻能拿來做一些實驗，一旦使用到具體的落地應用上，效果往往就不太理想。這主要是由於傳統的統計學更看重專家對於數據特徵的設定，而深度學習採用的是讓計算機自己去學習數據的特徵，少了人為因素的干預，計算機學習到的數據特徵更加豐富完整。效果自然也更好，唯一的缺點就是對數據量要求更大，對硬件算力要求也更高。這也是為什麼深度學習在直到現在才真正走向臺前的原因之一。 四、人工智能的行業應用目前對於人工智能的行業應用基本可以分為四大類：分別是圖像視覺處理方向、語音信號處理方向、自然語言處理方向、自動化處理方向。圖像視覺處理方向有圖像檢測、圖像識別、圖像生成、圖像分割等分支方向；語音信號處理方向有語音喚醒、語音命令、聲紋識別、語音識別、語音合成等分支方向；自然語言處理方向有文本分類、文章摘要、閱讀理解、智能對話、機器翻譯、文章生成等分支方向；自動化處理方向有遊戲娛樂、家居生活、自動駕駛、生命科學、工業多設備應用、金融投資等分支方向。 當然了，人工智能行業的發展是日新月異的，想要了解更多的人工智能行業知識，是需要主動關注行業發展的。如果沒有太多的時間關注人工智能的發展，可以關注本公眾號，我們會長期更新人工智能行業的新技術和應用發展。 本文轉載自51CTO，本文一切觀點和機器智能技術圈子無關。原文鏈接在線免費體驗百種AI能力：【點此跳轉】

5月28日-29日，2021阿里雲峰會在北京國家會議中心隆重召開，從“全面上雲”到“雲上創新”，標誌著阿里雲在2021年的全新重磅升級！阿里雲 2021 年將加碼投入三個方面，做好服務、雲釘一體、數據智能，並在“做深基礎、做厚中臺、做強生態”戰略基礎上，新增“做好服務”方向，打造中國最大最好的數字化服務團隊。 本次峰會，阿里雲視頻雲聯合達摩院、釘釘推出了優化音視頻業務客戶體驗分論壇、低代碼開發分論壇、視覺AI開放平臺及行業應用分論壇。針對音視頻全場景，阿里雲視頻雲推出的互動課堂、互動直播、音視頻會議、AI媒體生產等一系列音視頻解決方案和技術最佳實踐，作為此次阿里雲峰會的重要內容和議題，獲得了各界參會嘉賓和行業的廣泛關注，以低代碼、高性能、強體驗的音視頻服務為全行業的視頻化、線上化、數智化轉型加速，展現了阿里雲視頻雲在多行業多場景的深入探索和全面佈局。 互動課堂，讓教育更智能 阿里雲視頻雲互動課堂產品負責人 王凱旋 教育的未來是基於數字技術的終身學習，未來的學習不再僅限於書本知識，更會擴展到工作技能、社交、認知、興趣等更廣泛的領域。根據麥肯錫的研究報告，預計到2030年，基於數字技術的在線教育平臺將覆蓋中國 9億以上的人口。 一個理想的在線教育平臺核心環節有三個，首先是穩定的產品的平臺，其次是高質量的課程，再者是優質的學習體驗，這三個環節既包含了廠商、老師和學生的不同需求，還對音視頻編解碼、網絡傳輸、AI智能生產等眾多技術提出了更高的要求，這對於任何以一個在線教育公司來說都不是一件容易實現的課題，它意味著很長的研發週期、高企的研發成本和深厚的技術壁壘，特別是一些傳統的教育機構面臨著更多的困難。 阿里雲視頻雲最新推出的智能互動課堂解決方案，可以幫助各類教育機構一站式地快速搭建教學平臺，它覆蓋了所有主流的教學場景的功能，深入各類授課場景，直擊在線教育實時互動痛點。 視頻雲智能互動課堂基於淺綠幕和深度學習技術，實現人像和課件背景的最佳融合，高度還原現場聽課效果；通過手勢識別、虛擬老師、體態動作識別等，豐富課程趣味性，讓教育交互更加有趣。 針對在線課堂效果不透明的問題，互動課堂自動生成課堂報告，提供專注度檢測，提升授課質量和學習效果。此外，場景化的AI組件聚焦音樂、美術、美妝穿搭、棋類等，幫助教育機構快速靈活搭建自有品牌的在線互動課堂，滿足更多素質教育和興趣教學場景。 互動直播，重塑業務場景 阿里雲視頻雲產品解決方案架構師 王艮 直播已經成為行業標配。2020年前三季度新增近2.5萬家與視頻直播相關企業，較去年同比增長565.32%，‘直播+’模式重構傳統場景、創新商業模式、促進直播向細分領域發展。 傳統的互動直播業務包括基礎能力構建、實時互動、內容傳播，需要很高的人力開發成本，而阿里雲視頻雲期望給大家提供更快接入、便於互動、高效分發、安全穩定的互動直播服務。 在阿里雲視頻雲看來，真正面向未來的直播服務應該具有高度的互動性，它具備了快速搭建、超低成本、相互嵌合、智能安全等特點。 在阿里雲視頻雲的服務體系下，各類客戶都可以通過LowCode平臺，快速接入業務變現；以豐富的原廠組件和場景化的互動組件，提升C端互動體驗；基於AliRTC+AliRTS+AliIM提升轉化效率，實現高效分發；基於阿里先進的多模態內容理解AI技術和萬億級數據資源保障直播安全。

全新一體化安全業務加速解決方案發布 阿里雲安全可以在保證Web應用安全的同時，完成內容交付，以高效、可信、安全的方式加速靜態與動態的內容網絡。DCDN（CDN的動態路由）中的嵌入式安全，使業務安全不以犧牲業務效率為前提真正落地。 對於內容提供商來說，安全的網絡環境和順滑的用戶體驗同時實現，是一直魚和熊掌不能兼得的痛處。逐年走高的攻擊態勢，一個高效的內容安全解決方案的需求更加迫切。 安全能否助力業務發展速度，阿里雲在嘗試解決這個問題。 典型業務場景 中國遊戲公司出海大軍中，有一匹脫穎而出的黑馬。這家企業使用阿里雲DCDN來整合超大規模的用戶體驗，允許用戶將其源服務器的所有邊界網關協議（BGP）網絡資源替換為單個操作網絡，將源服務器的帶寬成本降低了50%以上。 阿里雲採用DDoS防護、WAF、限速、Bot管理、訪問控制等全方位的邊緣安全措施，保護源頭、保持站點在線、保障用戶數據安全，布點延伸至各邊緣，並且不影響網絡速度。 全球領先的DCDN安全 阿里雲CDN加速安全解決方案，採用最新DCDN技術，全球2800多個CDN節點，為客戶提供全方位的基於邊緣的安全措施。 這些基於邊緣的安全特性集成於整個網絡，能夠減輕流量密集的DDoS攻擊和Challenge Collapsar （CC）攻擊。同時，阿里雲使用智能算法提供應用級保護，能夠及時主動防護多種網絡安全場景，在線保護用戶業務免受各種威脅，如0day攻擊和DDoS攻擊，進一步優化最終用戶體驗。

5 月 29 日，阿里雲開發者大會的《基礎設施的雲上管控》分論壇上，Mobvista 資深運維架構師於龍水發表了主題為《雲架構下的運維體系構建》的演講，詳細闡述瞭如何高效地用雲以及雲上成本優化的五個方向。 Mobvista 資深運維架構師於龍水 本文根據於龍水的演講整理成文。 為什麼要用雲？ 首先來看一個比較簡單的雲的原生態架構。相較於傳統 IDC 來說，雲計算的架構有五大特點： 開發要求變高。上雲需考慮單機能力、請求能力、負載能力和轉發能力。 服務器數量變化。雲上資源可以自由地彈性伸縮，資源不再固定，這對運維人員挑戰很高。 資源利用率高。雲計算平臺最大的特點是高彈性，能根據用戶需求提供雲資源，提升整體資源利用率。 業務增長不受限。上雲後，可以靈活地使用雲資源，隨時調整雲的使用量。不論是當前的業務，還是未來的業務都不受資源限制。 安全性高。像阿里雲的公有云，都有一套內置的安全方案。只要用雲，就可以免費使用這套安全方案。在雲上，安全方案會提醒 DDoS 的觸發時間、處理情況與結果。所以，安全性會相應提高。 如何高效地用云為企業服務？