李成熙，騰訊雲高階工程師。2014年度畢業加入騰訊AlloyTeam，先後負責過QQ群、花樣直播、騰訊文件等專案。2018年加入騰訊云云開發團隊。專注於效能優化、工程化和小程式服務。微博 | 知乎 | Github
小程式誕生以來，業界關注小程式前端的技術演進較多，因此眾多小程式前端的框架、工具也應運而生，前端開發效率大大提高，而後臺的開發技術則關注不多，痛點不少，具體痛在哪裡呢？
小程式後臺開發之痛
第一個是腦袋瓜疼，怎麼疼呢？
隨著像騰訊雲等的雲服務商提供的雲服務越來越便捷，業務上雲已經是大勢所趨。但是從簡單地在雲虛擬機器上部署頁面，到實現真正全面地上雲，還是有很多區別。要真正實現全面的上雲，要了解的東西非常多，當你第一次接觸這些概念的時候，學的這些東西是一個接一個，讓你應接不暇，往往分散了你的對業務的專注力。比如我自己，來騰訊雲之後，為了對雲服務有更好地瞭解，就去報了個騰訊雲的課程。這課程系列分雲架構師、雲開發、雲運維三門課程，還分初級、中級、高階，需要花費大量時間才能理清這些知識概念，並且還要花大量的時間去上機做實驗。所以對於開發來說，要徹底搞清楚，還真的不是件容易事，絕對讓你的腦袋疼。
第二是肉疼，尤其是你老闆肉疼。
最開始當網際網路還沒有云服務商的時候，公司都得自己搭服務，不僅花大價錢買機器、買寬頻流量，還得請人過來維護。如果在這種情況下要搞小程式開發，公司得請一個維護伺服器硬體的、一個維護網路的，一個資料工程師，一個後臺還有一個前端，剛好五個人。當雲服務商開始進入變革整個市場的時候，我們就不用再自己維護硬體了，由雲服務商來維護，因此我們可以少請一個維護硬體的，但還是得有一個運維去維護雲服務。當雲服務商將資料庫、容器服務都抽象出來上雲之後，我們們連專業的資料庫維護都可以不請了，由後臺或者雲維兼崗就行。雲服務商的不斷髮展，確實是讓雲服務的成本不斷下降，但投入的錢還是很多呀，要投入的人還是不少，這幾年生意難做，作為老闆肯定是想投入成本、試錯成本越少越好。
第三個是腎疼。
大家都知道，開發是一個走腎的工作。比如，這些年流行的前後端分離，雖然讓專人專項，但卻引入了聯調這個事，所以也增加了腎的負擔。
這裡列出了三個前後端分離帶來的麻煩。
- 權責往往不清晰，有很多臨界的位置，誰管都可以，容易引發扯皮。
- 溝通時間增多，因為畢竟是兩個人工作嘛，需要不少的溝通
- 除了溝通，還需要兩邊的程式碼除錯，看看資料、展示通不通，這個時間也很不可控，尤其是如果環境特別複雜，調起來不僅麻煩重重，還很有挫敗感。
無服務開發小程式是未來趨勢
正因為小程式後臺開發的麻煩重重，因此業內都想出了各種各樣的開發方案，其中一種方案，“無服務開發小程式”，我們認為，將會是未來的趨勢。但這個未來，其實今天已經到來了。
那什麼是無服務開發呢？無服務，又稱為 Serverless。Serverless 還處在一個比較初期的階段，目前也沒有權威和官方的定義，不同人不同公司有不同說法，今天我也不打算講太複雜。顧名思義， Serverless 就是指應用的開發不再需要考慮伺服器這樣的硬體基礎設施，基於 Serverless 架構的應用主要依賴於像騰訊雲這樣的雲服務商提供的後臺服務。比如說無服務雲函式、雲資料庫、物件儲存服務等等。簡單來說，相當於你現在要開個水果店賣水果，以前你還得要租店面，搞水電、裝修門面。現在這些都不用了，你就在一個已經搭好各種各樣設施的超市裡，租一個已經幫你搞好門面的架子或者箱子，賣得好你就租大一點，賣不好就租小一點，隨時隨地隨你的心意，非常靈活。
為什麼說無服務化開發是趨勢呢？因為雲服務的程式，已經從物理機，演進到 IAAS，再到 PAAS。IAAS 就是包括像雲虛擬機器、私有網路、網路專線、負載均衡等等的基礎服務；PAAS 則更抽象一些，比如像雲資料庫、網路防護等等。基於 IAAS、PAAS，雲服務商發展出 Serverless 這類更高階的開發服務。因此呢，無服務開發就會是今後開發類似小程式這類輕量應用的新的開發趨勢。
一句話概括就是說，有了無服務開發之後，你就不用再處理安裝、運維，底層了，只管寫介面、寫邏輯就好。總得來說，雖然你管的東西越來越少，但開發效率卻越來越高，開發出來的輕應用、小程式卻是具備高效能、高可用、高擴充套件的特性。
那無服務開發，具體怎麼去解決剛剛提到的後臺開發痛點呢？
第一是讓你更加關注你的業務邏輯。雲服務許多好用但難理解的概念，什麼冷備熱備、彈性伸縮、負載均衡等等，通通都不用管，你只需要寫好你的業務，服務好使用者就行。
第二，更省人力更省資金，老闆不再肉疼。因為有了無服務開發，運維工作也不用操心了，像小程式這類的輕應用，有一個全棧開發，或者一個前端，半個後臺就可以輕鬆應付了，資金和人力的需求可謂大大節省。
第三，就是前端工程師向全棧工程師的轉變。有了無服務開發，前端工程師其實也可以安全、高效能地去操作一些以前只有後臺才敢操作的資料和邏輯，如果要開發的應用是像小程式一樣輕量的、簡單的，完全可以由前端工程師完成，除非是特別複雜的，可能才需要後臺的介入。這樣也省缺了先前提到的前後端聯調的麻煩。
小程式·雲開發
說了這麼多無服務開發的概念、優點，在小程式無服務開發這一塊，騰訊雲有什麼樣的作品呢。這就是今天要重點介紹的，小程式·雲開發，這就是騰訊雲與微信聯合研發後，交出的答卷。
雲開發，一共提供了三大能力，分別是儲存、資料庫、雲函式。簡而言之，就是提供了存檔案、存資料和執行業務邏輯的能力。接下來，我會採取前後對比的方式，從方方面面去對比雲開發和舊有的開發模式的不同。
首先是開發模式與架構上的對比。在雲開發模式出來之前，舊的小程式後臺開發模式就是上面這幅圖，在小程式端發請求，往往你得引入額外封裝好的 SDK，然後你需要在雲服務這邊配置大量的運維產品才能做出效能、可用性非常好的產品。開發者要關心的內容，從前端、後臺一直關心到運維這塊。
而云開發的全新模式，只要呼叫小程式原生的介面，就可以操作最基本的三大資源，而云開發背後又有騰訊雲的基礎服務作為支撐，本身就高可用、高效能、可擴充套件，你要關心的事情是大大減少了。
其次是資源管理平臺的對比。以前你需要管理雲資源，你需要在騰訊雲的皮膚裡，幾十上百的產品裡找到你需要的產品。
而云開發呢，你在小程式開發工具裡，就可以找到雲開發的控制皮膚入口。進入後，我們將你要關注的產品，做成一個獨立皮膚供你使用，極為簡潔方便。
第三，我們對比一下在小程式端呼叫資源。以上傳檔案為例，舊的開發模式，小程式端，你需要用 wx.chooseImage 還有 wx.uploadFile 小程式介面，後臺要部署業務框架、路由，還有寫邏輯上傳到騰訊雲的物件儲存，你還要考慮這個後臺服務的效能與安全，萬一使用者量峰值很大怎麼辦，有黑客攻擊怎麼辦。
而云開發的例子，則極為簡單，十幾行程式碼，就可以寫出安全、效能好的程式碼上傳邏輯！
假設開發者是一個菜鳥，只懂 JavaScript 基礎，對比下來，傳統的開發模式，前端耗時2分鐘開發，1小時聯調，後臺框架、邏輯和聯調一共8小時，運維，要花一整天時間去學，總共要花1142分鐘，對比只要寫2分鐘就能完成的雲開發模式，足足是雲開發耗時的571倍！
最後，我們來對比在服務端裡插入資料。這裡的服務端裡指的包括有云函式、還有你自己買的伺服器。舊模式下，小程式端要用一個 wx.request 傳送請求到後臺，後臺搭建好框架、路由等服務之後，開始寫插入資料到騰訊雲MongoDB例項的邏輯，自然也是需要考慮服務的效能與安全。
而云開發的新模式，十幾行程式碼，就可以開發出效能好、安全性高的插入資料邏輯。
假設開發者是一個菜鳥，對比下來，傳統的開發模式，前端要花31分鐘進行開發與聯調，後臺要用6小時部署服務開發邏輯還要30分鐘聯調，而運維的話從學習到會用大概也得10小時，基本上是雲開發模式耗時的1000多倍。
從程式碼、耗時等多個方面去對比新舊兩種開發模式，我們可以發現，雲開發是絕對的碾壓。
小程式·雲開發背後的技術力量
大家現在知道了無服務開發是未來的開發新趨勢，帶有無服務特性的小程式雲開發帶來的各種各樣的好處，那麼騰訊雲在背後，做了些什麼技術進行支撐呢？
架構上，一個請求操作從小程式端，通過微信後臺，一直到騰訊雲這邊的雲開發服務層，雲開發服務層呼叫的這些資料庫、儲存、雲函式，其實都是基於騰訊雲的各種基礎服務。在這個請求通路上面，微信會將小程式的使用者 openid， 小程式 appid 直接帶過來，將使用者的資訊寫到雲函式、資料和檔案元資訊裡面，為更方便的許可權控制打下基礎。
另外，既然是複用了騰訊雲的基礎資源，那自然是具備了雲資源的特性。比如儲存自動接入了 CDN 加速, 資料庫天然就帶有自動備份、無損恢復等功能，雲函式有彈性伸縮、多地可用的特性，能響應峰值不同的服務。而云開發服務層，我們也做了負載均衡、並且與微信後臺進行就近接入，讓效能更好。
目前雲開發正式上線5天（注：9月10日深夜釋出，掘金技術大會是在9月16日），我們的服務所支撐的 API 日呼叫量最大的單個小程式，已經達到 1000W+ 的呼叫量了，這個呼叫量是什麼概念呢？一般只有BAT，一些高頻使用的獨角獸開發的小程式才能達到這個呼叫量級。因此90%以上的小程式用我們這個服務都是沒有問題的。
推薦實踐
講一項技術，除了講功能、講底層，其實更重要地說講怎麼去用這門技術去實踐。接下來，我會介紹一些我們推薦的實踐方式，但我只會是點到為止，我們其實更希望社群能基於雲開發，做出更多更好的實踐。
第一點是資源操作的推薦實踐。
在小程式端操作資源方面，我們是使用小程式的原生介面進行操作，而在小程式端操作資源，由於安全的考慮問題，基本上操作儲存、資料庫等的資源只能寫使用者自己的資料，而讀資料則根據規則來判斷是否有許可權。在服務端操作資源方面，我們使用 wx-server-sdk 或者 tcb-admin-node 來處理，前者是基於後者的能力進行了封裝。在服務端使用這兩個 SDK 去操作資源，所擁有的許可權是管理級的，就是意味著可以操作一切的資源。
左邊的圖是資料庫的許可權控制，右邊的圖是儲存的許可權控制。這兩個控制皮膚都有各自不同許可權的一些推薦的使用場景，大家可以開啟控制去讀下面每個許可權的灰色的解釋。
第二點，是資料庫的推薦實踐。這裡以騰訊乘車碼為例，像這種交通的小程式，可能會面對弱網或者無網的情況，開發初期為了省事，將大量的配置資訊都寫在小程式端中。但隨著向更多城市的推進，配置檔案越來越大，小程式的包體積越來越大。正好這個時候雲開發推出了，騰訊乘車碼就採用雲開發的資料庫，將一些不一定要在離線環境使用的配置遷移到雲開發，另外還採用雲開發的儲存服務來存放靜態資源。這就大大壓縮了乘車碼小程式的體積，為其它新增功能騰挪了空間。
第三點，推薦使用雲開發的儲存存放小程式中所需要的靜態資源。因為雲開發的儲存天然自帶 CDN 加速。比如在控制面版的儲存中，檔案的詳情裡獲取的下載地址，就是 CDN 已經加速的地址。
第四點，是雲函式的使用。目前雲函式暫時不支援過於耗時、太複雜的操作，目前的超時時間為20s，函式包大小控制在20M左右。但其實這也已經能滿足超過80%的需求，隨著服務的逐步穩定，我們會考慮將這些限制進一步放寬。
雲函式另一種用法就是，我們可以將相同的一些操作，比如使用者管理、支付邏輯，按照業務的相似性，歸類到一個雲函式裡，這樣比較方便管理、排查問題以及邏輯的共享。甚至如果你的小程式的後臺邏輯不復雜，請求量不是特別大，完全可以在雲函式裡面做一個單一的微服務，根據路由來處理任務。
比如這裡就是傳統的雲函式用法，一個雲函式處理一個任務，高度解耦。
第二幅架構圖就是嘗試將請求歸類，一個雲函式處理某一類的請求，比如有專門負責處理使用者的，或者專門處理支付的雲函式。
最後一幅圖顯示這裡只有一個雲函式，雲函式裡有一個分派任務的路由管理，將不同的任務分配給不同的本地函式處理。
雲函式還有一種用法就是，可以作為中間路由，然後將 appid, openid，轉發給原有的服務。這裡以騰訊相簿為例。具體怎麼操作呢。比如騰訊相簿之前將評論功能接入了雲開發，但一些敏感操作，像刪除、編輯評論，這個請求傳送到雲函式，然後雲函式會將使用者資訊轉發給相簿原本的後臺，然後再將該使用者是否有許可權返回來告訴雲函式，如果有許可權，就在雲函式裡刪除評論。
最後，如果你們想在雲函式呼叫 AI 服務，還有一些微信相關的操作，可以使用我封裝的這兩個 SDK。第一個 image-node-sdk 覆蓋面比較全，覆蓋了全部的騰訊雲智慧影象服務，下面的 wx-js-utils,也提供了微信支付、模板訊息、使用者資訊獲取等幾個常用的介面。
可以關注我的微博或者 Github 獲取最新雲開發的資訊或者技術資料。