本文為 Serverless 社區成員撰稿。作者雲洋，從事信息管理工作，多年電子政務信息系統建設管理經驗，對 Serverless 技術和架構有濃厚興趣。
這個假期挺長的，不過有幸在騰訊雲 Serverless 在線直播裡看到了 Serverless 的相關課程，從第一期學完，還是憑添了很多學習樂趣。
前面三節課學了一些 Serverless 的基本知識和架構特點，也跟著開發部署，其實都蠻有趣的，唯一就是都沒有管理後臺。第四期課程很好的彌補了這一不足。劉宇老師給大家帶來的項目 Python+HTML 的動態博客，後臺是基於 Flask 的，雖然我不太熟悉這個框架，但是老師給提供了課程的源碼，所以可以先用後學。
- 這節動態博客的直播回放地址是： https://cloud.tencent.com/edu/learning/live-1926
- 劉宇老師的項目的 Github 地址是： https://github.com/anycodes/ServerlessBlog
直播那天我提前準備好手機和電腦，就進教室了，不過當天課程收到網絡的干擾很大，一直很卡，後來劉老師重新錄製了課程，據說錄到凌晨兩點，這一點必須點贊，敬業精神太感人啦。在老師的熱情帶領下，我們的學習勁頭也是十足的啊。
我的學習路徑可謂十分曲折，整整折騰了三天，不過最後終於實現了項目的成功部署，很開心！
整體來說，其實項目部署就是四個步驟：
- 下載源文件
- 執行init.py
- 修改 serverless.yaml 文件
- sls --debug 部署到雲端。
我在每一個步驟都踩過坑，我基本上按照順序把坑和解決方案列出來，感興趣的同學可以基於上面的鏈接嘗試開發部署，如果遇到相關的坑，可以對照參考。
坑一：Git 下載報錯
Git下載報錯，錯誤信息是這樣如下：
<code>remote: Counting objects: 100% (1438/1438), done.remote: Compressing objects: 100% (1100/1100), done.error: RPC failed; curl 18 transfer closed with outstanding read data remainingfatal: The remote end hung up unexpectedlyfatal: early EOFfatal: index-pack failed/<code>
百度之後，發現針對RPC錯誤需要修改Git的buffer，調到700M後依然報了上面的fatal錯誤，和網絡有關，最後放棄用git，選擇老師發在文檔裡的壓縮包，地址上面列出來了，大家可以去自行取用。
坑二：pip 的源設置和 pymysql
部署過程中因為 init.py 裡面用到了 pymysql，可是我沒有安裝，於是打開Anaconda Prompt 開始用 pip 安裝，然而 pip 好像死了一樣，完全沒有反應，最後報錯說找不到包。後來經同學和老師提醒，修改 pip 的源到國內，我用了清華的源，速度一下很快啊，安裝成功。修改源的代碼是：
<code>pip install pymysql -i https://pypi.tuna.tsinghua.edu.cn/simple/<code>
如果大家需要安裝其他包，就把 pymysql 換成要安裝的包。
但是 init.py 依然報錯，於是就吧 pymysql 的包放在項目目錄中，解決了問題。
坑三：yaml 沒有 FullLoader 屬性
init.py 的執行一致不順利，pymysql 的坑填完後繼續報錯。
於是以為自己沒有安裝對 yaml，後來老師建議刪掉該語句，大家要注意，這個語句裡 Fullloader 出現在一個逗號後面，所以我們只刪掉逗號後面的 loader=yaml.FullLoader 就好了。
坑四：數據庫連接
其實如果用老師提供的測試庫的話，這個坑就不是問題，但是我覺得那麼多同學做作業，老師的庫壓力會很大，正好我自己買了一個騰訊的雲數據庫是 MySql的，可以直接拿來用。
於是我就天真的把數據庫地址改成了自己的，以為它可以連上，但是連接超時，於是我有把用戶和密碼改成自己的，結果還是拒絕訪問，一直到我去雲數據庫控制檯去測試連接，才發現原來我的數據庫端口沒有寫對。
雲數據庫的外網鏈接設置還是很方便的，這次作業讓我還進入了 PMA，進行了在線數據庫操作，挺好用的。到這裡，init.py 的坑就填平了，我看到新建數據庫的成功。
坑五：網絡問題
這個坑有點深，我在裡面爬了兩天才爬出來，而且之所以爬出來，完全是因為換了網絡哦。
不得不說移動的家庭寬帶真的不給力啊，Git 連不上，部署函數總是斷線。我之所以在這個坑裡沒有很快出來，還有一個原因，就是每次的報錯信息不一樣，這深深的吸引了我。
我的報錯信息五花八門，給大家分享一下：
這個錯誤出現的原因其實也很難想通，因為給的信息太少，並不知道到底是哪裡有問題。後來還報過一個類似的錯誤，印象裡是說讀不到 'admin_add_article'，我後來發現 git 上面又更新了一個文件夾 picture，裡面有這個名字對應的圖片，所以我就重新 git clone 了項目文件，把picture文件夾拷貝了過來。
這類 443 的錯誤，我是一直沒有解決啦，直到我更換了網絡。不過大家可以看到上面有一個存儲桶的部署信息，那個桶不是我的。
關於 InvalidParameterValue 不太理解，什麼樣的 ID 是合法的呢？我考慮應該是網絡中斷丟失了數據，導致有些字符沒了。
ECONNRESET 這個錯誤報了很多次，具體是什麼意思不太明白，socket hang up應該還是網絡不通暢吧。
還有一個是超時了，估計是網絡情況不好。
這個 undefined RequestId 也是出現了多次的錯誤，很奇特。估計是網絡數據丟包造成的吧。
以上所有的問題都是網絡問題，解決方法：同學們提醒我不要部署到 hongkong 區域，可能海外服務器會有網絡不穩定的情況，於是我換到了beijing，依然不行，我還換到多 guangdong，網絡錯誤依然不斷。
這個網絡問題引發了我的不少猜疑啊：比如，我是不是頻繁部署系統被封IP了？是不是防止勒索病毒，443端口封閉啦？我家的寬帶是不是該換運營商了？
顯然最後一個猜疑是並確認了的。我利用手機數據流量包部署系統就很快，240s 左右解決問題。
這裡面其實報錯信息不是很友好，首先，我不知道具體到哪一個文件的時候網絡斷開的，所以我不能肯定是不是某一個文件有問題，如果這時候能夠定位一個斷開的時候處理在哪一個文件，會對用戶更有幫助。
而關於那個存儲桶，應該是老師的，因為後來在部署成功的一次我在信息裡看到了從老師的存儲桶裡上傳了代碼到一個存儲桶裡，而我在自己的存儲桶列表裡看到了那幾個桶。
之所以有幾個，是因為我換過幾個區來部署。有一些程序老師可能部署在他的桶裡，這樣是不是省我們的流量呢？也可能是為了部署 Flask Admin 的過程更加平順，老師把一些依賴部署到了線上的桶裡。
記得上節課的老師也用了 Flask，他說 Flask 需要對應 Python 的精確版本，我們每個人的版本可能都會有些細小差別，造成部署過程的顛簸，老師為了避免這種狀況，就額外處理了。老師，您用心啦！
坑六：UploadPicture
因為每次網絡問題都發生在部署uploadPicture這個部分，時間很長，所以我都會忍不住cancel重來。
於是這個部分後來被我註釋掉了。註釋之後，部署很順利，因為換用了手機的網絡。這突如其來的順利讓我覺得 uploadPicture 可能是無罪的，我應該把它放回來。於是我就取消了註釋，這時候災難發生了，10000s 之後它還在部署。
我很好奇，為什麼這個部分這麼特殊，於是我打開一些 uploadPicture 的源文件來看，發現在 demo.py 裡面有很多設置和我們的 global 設置不一樣，於是我開始七七八八的修改起來，然而，老師說那個文件不在全局發揮最用，只是qqcloud_cos 這個依賴的一個 demo，於是我又改了回去。
後來，有同學說清空存儲桶可以解決這種超長時間部署的問題，於是我試了一下。恩，真的管用哦！感謝同學的提醒。
PS：我後來回想很可能就是缺少 picture 那個文件夾吧，我猜測部署的過程可能會跑有些 test 程序，文件的代碼會被執行，而如果裡面的參數讀取不到就會一直停在那裡。
坑七：後臺無法使用
部署成功之後，我訪問後臺，發現只有登陸頁可用，其他頁面基本上一點就報錯，Internal error。在老師的提示下，我到了函數的控制檯，查看了Blog_Admin的報錯信息，發現是數據庫連接不到。
可是我之前明明在數據庫裡新增數據的，於是我打開了 serverless.yml 文件和數據庫裡的庫名稱對照, 發現數據庫的名稱多了一個字母 l，哎，粗心啊粗心。修改了 yaml 文件後再次部署，成功了！
應該說控制檯的日誌挺詳細的，我覺得如果能把成功信息和報錯信息在顏色上區分一下就更好啦，目前看來是用時間戳來區分的，不過有時候請求多起來，很多正確和報錯信息在一起，找起來很麻煩啊。要是有豐富一些的查詢選項也許更好用。
最後，我終於跳過了這些坑，上了岸！
部署成功後的頁面如下：http://blogdemo-1253166145.cos-website.ap-beijing.myqcloud.com/
於是，我帶著劉宇老師佈置的作業來投稿，信息化資產複用最大化，感覺是一次非常開心的學習體驗！
閱讀更多 Serverless 的文章
