無服務器準備:
近兩年無服務器是軟件開發熱門話題。AWS引領這項技術且在不斷進步,而各雲廠商都具備本身的技術標準,若是要作各個雲廠商以前無縫移植,從目前看來幾乎不可能,不過我相信對這一技術的創新將來有可能會出現第三方無縫對接或者統一標準,咱們期待有這麼一天。
因爲無服務具有如下突出的優勢,如:1.實現業務快速上線、2.無須運維人員維護基礎資源,下降運維成本、3.系統級安全性更高、4.下降開發成本、5.適合微服務框架,在這些優勢吸引下以及大雲廠商推薦下,不少用戶就會試着把他們原來在On-prem的業務使用重構的方式往Lambda遷移,而這些嘗試首先必需要求用戶的人員可以在微服務基礎上繼續拆分紅Function的能力,可以把業務作成無狀態。
業務演進圖1數據庫
從原來巨型業務Refactor到Function,這對開發人員要求愈來愈高,須要開發人員對業務進行細粒度拆分,以知足這種新技術的要求。安全
實踐分享:
因爲客戶原來在On-premises的應用已經沒法知足業務的日益擴展,須要對原來的應用進行代碼重構後上雲。客戶沒有具有技術很強架構師或開發人員,幾乎都是初級外包人員。咱們的人工程師協助過客戶的外包人員作一個基於Python的Lambda Demo測試以後,他們的外包人員開始本身使用SpringBoot藉助Lambda技術對原來的應用進行重構上雲,然而進行到必定階段時發現此技術須要很專業的技術人員纔可以徹底掌握,最後不得不放棄Lambda使用,迴歸到EC2部署方式。如下是作過必定刪減的客戶業務架構設計圖:
業務架構圖2服務器
1)業務及人員
這種新技術是要求開發人員必須具有必定微服務的能力,可以應用進行拆分,並可以經過業務代碼解決新技術存在一些缺點,還要求開發人員對原來的業務邏輯徹底掌握。在新技術並不完善的狀況下,並非全部業務場景都合適重構爲Serverless服務。此客戶狀況以下:架構
2) 技術選型:
在進行技術選型時,必須有一到兩我的員對某一技術有必定掌握,前期進行大量測試與預研,充分掌握此技術缺點與優化。Lambda技術出現並不長,必然存在一些不完善,這樣就要求開發人員可以對這些不完善有所掌握,並可以經過其餘技術手段解決Lambda存在的缺陷,以知足業務持續服務的要求。
1. 冷啓動時間
2. 開發語言是否合適
3. Lambda的請求併發與內存配置容量上限
4. AWS各個服務Timeout時間
5. 在Lambda內存達到上限後,重啓的問題
6. 使用Lambda預熱方案可否知足將來業務擴展
7. 微服務化後,可否集成CI/CD功能併發
實踐總結:
用戶在經歷以上使用體驗後,慢慢知道有些業務還要具有必定能力後,纔可以去嘗試,而不是急於求成,須要聽更多專業人員的建議,一步一個腳印完成業務遷移,先從簡單再到複雜,先從Rehost再到Refactor,若是要Refactor必須通過大量驗證測試。如下是經歷過此案例後一些建議:
1. Lambda合適在輕量級業務場景
2. 作足冷啓時間評估與測試
3. 可以更細粒度拆分業務,以Function方式寫業務
4. 掌握並測試AWS各個服務的限制(例如:API gateway的Timeout 20秒,Lamdba的內存上限3GB等)
5. 選擇更輕量開發語言(例如:Nodejs/Python等),儘可能減小部署包的大小
6. 很是熟練本身的業務
7. 具有高級以上開發工程師
8. 使用完善的監控,不斷優化Function
Refactor是遷移當中最高級且最複雜的方式,最好有專業人員進行協助與指導,避免重複的成本浪費。建議若是客戶的業務確實須要進行重構,請必須通過大量的功能與性能測試驗證。(此文章如有錯誤,請指正,謝謝!)框架
參考學習地址:
http://www.javashuo.com/article/p-spjwbcoz-md.html
https://www.jeremydaly.com/lambda-warmer-optimize-aws-lambda-function-cold-starts/less
做爲一家專業的雲計算服務型企業,博思云爲專爲客戶提供 AWS 上的運營服務:包括架構諮詢服務、遷移服務、雲安全集成服務、混合雲管理服務、大數據服務以及 DevOps 服務。目前,博思云爲在大數據、DevOps、架構、數據庫以及操做系統等都已取得廠商認證,在上海、南京、杭州、武漢等地設有分公司。爲創新服務模式、引領 IT 服務業的發展,博思云爲將持續投入資源開展智能混合雲管理平臺、圖數據庫的研發等。運維