Serverless往事

我想單獨(dú)開一個叫《Serverless往事》的topic，講述從2018年年初開始我們“艱難探索”新架構(gòu)的一些故事。Topic會不定期更新，希望能一直更新到一個大型網(wǎng)站的面世。

背景

18年初，突然得到領(lǐng)導(dǎo)通知，要起一個serverless的web應(yīng)用。當(dāng)時并不清楚具體緣由，只是隱約聽說原先架構(gòu)成本過高已無力支撐產(chǎn)品上線。一番調(diào)研后，海外的某個組首次實(shí)踐了serverless并獲得巨大成功。大中華區(qū)CEO很快通知我們，要在中國推廣aws serverless。

當(dāng)時的情況極為尷尬：除了一些樸素的java知識，全組甚至全廠都沒有粗通架構(gòu)的后端；前端也極為原始，幾乎沒人接觸過三大框架；CI/CD，更是無從談起。最大的困難是：我廠只做B端，對Internet網(wǎng)絡(luò)攻擊毫無抵抗力。然后，我們接到了任務(wù)：搭建一個叫E-pub的互聯(lián)網(wǎng)web應(yīng)用。一個新時代就這樣開始了。。。

業(yè)務(wù)分析

E-pub是我所在某招聘相關(guān)產(chǎn)品組的一個子模塊，主要面向互聯(lián)網(wǎng)端的應(yīng)聘者。業(yè)務(wù)流很簡單：應(yīng)聘者通過E-pub錄入個人信息，并向雇主申請Job。雇主在企業(yè)內(nèi)部HR系（姑且叫IVF吧）能及時同步應(yīng)聘者申請。主要頁面其實(shí)就兩個：1. 隱私條款 2. 用戶信息錄入頁面

• 性能

  設(shè)計之初，我們開發(fā)的是ST模式（single tenant）的E-pub。就單個Tenant來說設(shè)計用戶不會超過1萬人。以每天8小時計算，TPS峰值也就個位數(shù)，因此性能并不復(fù)雜。數(shù)據(jù)庫的話，Dynamodb也能勝任了；Web服務(wù)用api gateway + lambda就搓搓有余。因此，我們不需要自找麻煩去討論MQ、Redis、Zookeeper這類大型應(yīng)用。

• 可擴(kuò)展性

  E-pub功能很簡單，幾乎不會再擴(kuò)展了。

• 可用性

  E-pub晚上幾乎不會有人訪問，即便是白天，宕機(jī)幾個小時其實(shí)也不會有太大影響。復(fù)雜均衡、異地多活這類方案就免去了。但是數(shù)據(jù)丟失可能比較麻煩，因?yàn)楣椭骱蛻?yīng)聘者之間本沒有聯(lián)系方式，數(shù)據(jù)丟失意味著永遠(yuǎn)失聯(lián)了。所以搭建數(shù)據(jù)庫的話必須考慮主備方案。

• 安全性

  E-pub包含應(yīng)聘者個人信息，有一定的隱私性；但是不會包含密碼、銀行賬戶等信息。只需要控制訪問權(quán)限并及時清除線上數(shù)據(jù)就行了。

• 成本

  系統(tǒng)很簡單，有一個主備從的數(shù)據(jù)庫和一個簡單的服務(wù)器就能搞定。

技術(shù)棧

業(yè)務(wù)確定后我們立馬討論了技術(shù)棧的選擇。

• ExpressJS

  我果斷放棄了java，主要原因就是冷啟動太慢了。E-pub只是先期項(xiàng)目，我們后續(xù)有更復(fù)雜的業(yè)務(wù)。當(dāng)時lambda會在無響應(yīng)5分鐘后自動關(guān)機(jī)（現(xiàn)在已變）。從我們已有的IVF項(xiàng)目中得出的經(jīng)驗(yàn)是，Java服務(wù)調(diào)用?冷啟動很容易突破這個限制。于是我果斷選擇了node js。其實(shí)說來也慚愧，組里除了會java和js，沒人會別的語言了orz

  Nodejs最出名的框架是Express，它的啟動時間極端；后來在生產(chǎn)實(shí)踐中也得到驗(yàn)證：最慢一次lambda冷啟動時間也就800ms。在同期實(shí)踐的其他serverless項(xiàng)目中，竟然有幾十秒冷啟動的服務(wù)。

• NuxtJs

  前端框架的選擇沒有爭議，國內(nèi)vuejs具火，我們也不免俗套。由于當(dāng)時缺少技術(shù)積累，我選擇了NUXT——VUE的SSR框架。NUXT集成了VUE全家桶里主要的插件，自帶webpack，幾乎零配置就可以上手。不過后來也被NUXT坑了一把，這是后話了。

• DynamoDB

  DB是Department Manager指定的。IVF系統(tǒng)用了NoSql的cassandra，轉(zhuǎn)到serverless后竟也保持了這種傳統(tǒng)（雖然cassandra作為主數(shù)據(jù)庫已被無數(shù)人吐槽）。

Technical stack

Architecture Review

兩個禮拜后，我旁聽了組里領(lǐng)導(dǎo)和arc team的Review，依稀記得對方來了兩日本人和一個印度人。不得不佩服我領(lǐng)導(dǎo)，他和對方leaders談笑風(fēng)生，獨(dú)留我一人茫然無知，大概是我聽力實(shí)在是太差了吧。兩次review會議后，E-pub得出了大體如下的框架。

Architecture

架構(gòu)很直白，服務(wù)部署在lambda上，應(yīng)聘者只能通過api gateway讀取Job信息，并錄入個人信息；IVF（對的，是我們的那個內(nèi)部HR系統(tǒng)）輪詢E-pub，同步信息后刪除Dynamodb和S3里的記錄。

回過頭來看，這個設(shè)計甚至不如一個學(xué)生管理系統(tǒng)復(fù)雜，不過在E-pub場景里卻是一個很務(wù)實(shí)的選擇。

說點(diǎn)閑話，漢語語境里保守和激進(jìn)都帶明顯的貶義性質(zhì)。很多人喜歡評論別人的技術(shù)選型太保守或是太激進(jìn)，然后沾沾自喜一番。但是評價者自身沒有技術(shù)判斷力呢？架構(gòu)的選擇也是如此，其實(shí)并沒有保守或是激進(jìn)之說，簡單務(wù)實(shí)才是最正確的選擇。

小結(jié)

到此為止我們的E-pub正式進(jìn)入開發(fā)階段，雖然系統(tǒng)簡單但是五臟俱全。之后我們僅僅用了一個多月就搭起了這個web應(yīng)用，對比IVF年復(fù)一年的跳票，不得不說serverless帶給了我們巨大的驚喜?？偨Y(jié)起來大約有這么幾點(diǎn)優(yōu)勢：

• 開發(fā)環(huán)境：我記得當(dāng)年首次啟動IVF環(huán)境花了整一周；E-pub的話，傻瓜操作 yarn dev
• 開發(fā)體驗(yàn)：啟動快、熱加載、部署簡易
• 開發(fā)成本：第一月的消耗只有十幾刀，對比IVF系統(tǒng)空跑的成本就是大幾千刀每月

不久之后，我們迅速開啟了另一個新項(xiàng)目——M-pub。這次挑戰(zhàn)更勝從前，更復(fù)雜的web安全、DB讀寫限制、MT、微服務(wù)治理、CI/CD……世上并沒有一勞永逸的框架，更沒有放之四海皆準(zhǔn)的技術(shù)。我們又該如何抉擇，to be continue...

后話

有一次我向某日本領(lǐng)導(dǎo)請教技術(shù)棧的問題，她道出了一些很有趣的事。領(lǐng)導(dǎo)們并不關(guān)心技術(shù)，更不關(guān)心開發(fā)體驗(yàn)，他們只想要一個低成本的產(chǎn)品。這些話讓我茅塞頓開：對于底層小職員來說，我們追求新技術(shù)是因?yàn)榧夹g(shù)是安身立命的本錢；但領(lǐng)導(dǎo)們不是，他們講的是管理，要的是可控。從某種意義上來說，正確理解領(lǐng)導(dǎo)的意圖其實(shí)也是我們底層小職員安身立命的技能。