Adrian給出了一個令人信服的例子，即在同樣的技術驅動力情況下，更快的網絡和成本更低的消息傳遞，將會推動微服務的發展。
毫無疑問，人們聽到有關Serverless的一些情況。但Adrian以一種有趣的方式進行開發，他在追蹤架構如何隨時間的推移而演變。以下了解一下這個報告的細節。
未來的函數是什么?Adrian談到將Lambda函數推向了邊緣計算。這個話題讓人頗感興趣。
(1)數據中心消失。Lambda函數將不再運行在AWS上面，其代碼放置在使用CDN端點的客戶的附近。現在，企業在邊緣網絡有一個完整的分布式，可以低延遲在客戶端運行代碼。企業可以構建架構，部分位于數據中心，部分位于客戶端。因為在AWS區域，所以當然是圍繞著Lambda函數進行構建。AWS公司也在采用Greengrass和Snowball Edge窺探未來會變成什么樣子。
(2)這里有一個隱藏的局勢。一旦將代碼放在邊緣計算，就會違反Lambda的兩個關鍵假設：函數是使用可擴展的后端服務組合和消息傳遞低延遲。邊緣計算將有一個高延遲路徑返回到服務中的數據中心，那么如何在邊緣網路創建基于分布式應用程序的函數?邊緣計算是否支持一個以更少的信息的傳統架構返回到一體化架構的核心?
還是邊緣計算需要完全不同的東西?這里有一個想法可能完全不一樣，看起來可能是這樣的：Datane是一個新的CRDT數據庫，讓用戶將做壞的事情分布數據。
現在讓我們展望一下未來，首先回顧一下過去：
從單片機到微型設備再發展到功能
以往
•10年前。
•大部分為1gbps網絡帶寬。
•當時采用的最先進的技術是連接到大型關系數據庫的單片Java應用程序。
•使用交換XML消息的Web服務分解系統。
•通過慢速網絡發送XML的開銷很高。解析XML很慢。
•由于Web服務速度較慢，因此最終結構的特征是大型服務器之間交換的消息數量相對較少。
•系統的緩慢意味著請求在回復前不能超過兩到三個服務，因此很難將整體分解成較小的服務。
現在
•網絡帶寬為25 gbps。
•消息是Avro，gRPC等，其效率比XML高出100倍。
•將更快的網絡與更好的消息格式相結合，意味著在服務器之間發送消息的效率提高了100倍至1000倍。
•現在有可能將架構分解成許多較小的服務，因為可以進行100個微服務調用，并在延遲范圍內返回回復。
•由于技術變革，微型服務成為可能。一個系統可以分解成更小的服務，每個服務都有一個單一的責任。
•現在可以通過將微服務進一步分解成組成這些服務的單獨功能。
•有能力將所有這些功能連接在一起，因為信息成本已經變得更低。
交付代碼的時代
你想放多少代碼?構建和提供代碼需要多長時間?
(1)以往：
•轉到供應商，購買機器，將其放入數據中心，然后將代碼交付給它。
•提供代碼是一個手動復雜的項目，它們都是獨立的。
•有一些自動化，但通常是高度人工發布的程序。
•每6個月或一年發布一次，這是一個復雜的過程，需要進行大量測試才能確保一切正常。
(2)DevOps的第一波-敏捷時代
•代碼交付加快，每兩周發布一次。
•需要自動化，以便能夠快速發布代碼。
•第一波DevOps。自動化已經到位，以便更快地完成工作。Chef和Puppet被用來使用新的代碼來升級一系列機器。
(3)DevOps的第二波 - 云計算，API，開發者驅動
•還有一個問題：如果用戶需要更多的機器怎么辦?
•這就是采用云計算的原因所在：建立彈性系統，提供按需配置的能力。不使用機器時可能縮小，按需支付。
•云計算在開發和操作之間放置API。
•開發人員使用平臺API來完成任務。
•開發人員能夠通過自動化盡可能地推動操作。
•使用API?? +彈性+開發者驅動，可以創建Blue-Green部署：
o新的軟件版本在新的一組機器上推出。
o新軟件并列運行。
o當驗證新的構建工作時，舊機器被終止。
o不需要使用Chef或Puppet。 Netflix架構從來不需要它們。只需部署新的東西，并從頭開始創建東西，而不是升級。
o這是Immutable 基礎設施的理念。
•這讓很多事情加快速度。因為交付費用的時間不是6個月，而是一天或幾個小時。
•需要聚集的人數減少。創建個人微服務的個人開發人員可以根據需要使用自動化來推出。
容器周圍的組件標準化
•這個階段是在幾年前開始的。
•當部署一個新的自動縮放組的實例時，需要幾分鐘才能完全啟動，并按小時付款。部署可能需要幾分鐘到幾個小時。
•適用于日間流通模式，白天忙碌，夜晚安靜，預測這些模式和自動調整比較容易。
•網站受到電視廣告驅動的大量負載影響時會發生什么?用戶需要快速響應，但不知道負載會有多大。
•處理尖峰負載的第一步是轉移到容器。容器大約在一秒鐘內啟動，所以部署時間已經從幾分鐘減少到幾秒鐘。
•使用容器可以構建更精細的微服務器。
•容器開始標準化。每個人都運行相同的Redis或Nginx容器，取決于DockerHub上最新的容器。
•采用標準化調試良好的服務在容器中取代自定義組件。因此不需要數百人調試的組件從頭開始編輯軟件?
Serverless的第一階段
•這個階段是兩年前開始的。
•編寫代碼，但在被調用之前不會部署。它只是在那里準備部署，但不能在任何地方運行。當代碼中的請求出現時，必須進行部署和啟動。
•Javascript或Python的啟動時間相當快，達到了100毫秒。
•一旦預熱，將在十幾毫秒內啟動。
•停止使用時，用戶可以停止支付費用。
•在幾秒鐘內部署能力，但需要部署的機器，即可在10秒或100毫秒內部署，并以100毫秒的單位付費。
•如果用戶每秒運行一百萬個請求，則使用容器，因為計算機始終需要啟動并運行。有很多工作負載往來的流量很大。
•減少內存使用。在微服務器或整體中有很多不同的功能。這些功能中的一些調用并不頻繁，即使沒有使用，它們仍然使用內存。通過將系統分解為功能，只有在使用時才占用內存，所以平均的內存占用量將會下降。
•CPU的成本下降，因為用戶只需支付使用的費用(以100毫秒為單位)。
•將代碼投入生產中需要多長時間?答案是100毫秒。
•構建塊并不是容器，它們是服務，如DynamoDB。這些服務很少使用。
•現在可以在很短的時間內開發應用程序。在亞馬遜re：Invent，Hackathon的團隊的四個人能夠在十二個小時內構建一個完整的復雜系統。它們不僅僅是原型，可以被部署在規模生產中，因為它們是建立在Lambda之上的，所有的組都使用Lambda。
•快速構建時間是一個有趣的新功能。從數據中心移動應用程序時，用戶可以考慮使用Lambda從頭開始重寫，而不必將原有的應用程序解鎖。
Serverless的第二階段：事件驅動的基礎設施
云基礎設施本身開始發布可被Lambda函數消耗的事件。例如，創建一個新的實例可以觸發一個Lambda函數。
•這使得自動化水平達到了新的水平。這是用戶基礎設施的新的bash腳本，只有作為事件驅動的Lambda函數的腳本。
•這是一個新的事件驅動的基礎設施，事件可以鏈接在一起。例如：當有新機器使用Lambda函數來附加卷時;或者在實例死機之后進行清理。
Serverless的第三階段：邊緣的Lambda函數
•人們還不了解Radical departure。
•數據中心消失。函數不在AWS區域運行，代碼位于CDN端點處的CDN附近。
•現在，使用與其他地方相同的Lambda編程模型，可以從客戶運行代碼的方式全面分布，低延遲，毫秒級(注意目前在AWS邊緣網絡所做的很有限)。
•邊緣計算與物聯網相銜接。如果用戶想編程這個東西，那么Greengrass項目讓其可以在該項目中放置一個功能。
•現在，可以構建部分位于數據中心的架構，部分位于客戶端。
•Snowball邊緣設備是一個重達50磅的設備，里面有Lambda以及100TB的存儲空間。可以在用戶的控制臺上在云端編程，并且在現場交付盒子。微服務可以在飛機，船舶，通信發射塔或商店中分發。
•功能可以使用相同的編程模型推送。
組織的影響
•高層管理人員的問題幾乎都是人員管理的問題。他們可以改變的是雇用人員，如何組織，以及他們的預算。企業可以告訴他們使用某種技術，但他們應該自己來選擇。
•組織團體的新方法。如果想要一個特定的架構，你需要做一個反向操作：設置組大概是用戶想要的分區，并假定這些組將建立彼此通話的服務。
•新的工作方式。在新的世界里，需要建立一個開發人員和產品經理構成的團隊。這是亞馬遜能夠擴大其工程組織的原因之一。這些小群體需要被賦予自由和獨立來建立某種東西。
•大多數有微服務問題的人會發現，有些團隊沒有完成的責任，在一個地方做了一些工作，就會轉交給另一個小組。
•如果用戶有團隊分散在世界各地，每個團隊都應該完全擁有一個微服務器并自行更改。用戶應該能夠完全擁有和修改微服務器，而不會超出時區。希望都在一個房間辦公，或至少在同一個聊天室中會話。
•用戶正在建立的是一個可以高度信任的團隊，這是關鍵。很多大型組織本來就是低信任的組織。而當每個人都彼此相識時，就相互信任，組織可以非常有效地操作。
•組之間的低信任接口是API和SLA。這是為了使用像Google地圖這樣的服務或在同一個房間中實施另一個微服務的團隊。這需要團隊具有高度的信任。
擔心AWS鎖定?
•不要擔心。用戶表示在Lambda上構建速度非常快，用戶應該只需要構建它，而不用擔心它是一個僅限于AWS的功能。
•如果需要遷移，也只需一個星期的時間。
•Lambda函數封裝了業務邏輯的核心和業務邏輯，并且相當容易進行遷移。
•不要擔心再次使用，因為代碼更容易更換。
京公網安備 11010502049343號