小程序·雲開發最佳實踐：零基礎如何快速上手小程序開發？

聖誕快樂

我本人是在2014年的時候加入騰訊，主要做過有像QQ，小程序也做過一些，如騰訊文檔的小程序。現在主要負責小程序·雲開發。

今天這個分享希望解決開發者的困惑，比如說小程序的後台開發有哪些痛點？什麼是無服務化開發呢？還有小程序·雲開發解決方案，具體的實戰案例。

小程序本身提供的開發能力，主要聚焦在前端這一塊，這讓我不得不佩服微信團隊。因為他們做組件、插件其實是極大地方便了我們開發者的在前端這塊的開放，但後台的開發流程跟以前一樣地讓人困擾。

小程序開發

怎麼麻煩呢？主要有三條。

第一點是腦袋瓜疼。

現在我們創業基本上要上雲，除了業務邏輯之外，我們要做一個高性能、高並發、高擴展的服務，要理解非常多的概念，一個普通人、一個新入行的開發難以開發出穩定性高、性能好的後台服務。

第二點是肉疼。

去買雲服務我們要投入很多的機器成本，在早年我們甚至要買一些物理機，假設在物理機時代開發小程序，我們要買一個機器，還要請一個維護物理機硬體的同事，再請一個維護網路的同事，請一個資料庫的專員，再分別請一個前端、後台五個人，這樣才能把一個完整的小程序從前端到後台開發出來。隨著我們騰訊雲服務商不斷地發展，進行了生態變革之後，我們進入了雲主機時代，可能不再需要硬體運維了，一個運維人員就可以把系統和網路搞定。

再到下一個年代，我們把一些業務邏輯進一步抽象，我們進入了PAAS時代，我們連資料庫的維護都不需要了，我們只需要一個運維、一個後台，加一個小程序的工程師就能完成開發流程了。但目前的人員和機器配置，成本動輒數十萬，對於創業公司而言成本還是太高了。

第三點是腎痛。

我們開發是一個走腎的工作，尤其是推崇前後端分離。雖然說前後端分離是專人專項，分工明確。原以為很和諧，但是在實際開發的過程中，比如說中間地帶出了問題誰負責呢？還有的時候前端工作量做完了，後台還沒有完成，導致項目時間分配不協調，這些小事導致的無休止的爭吵可能會導致開發的效率變低。

那麼有沒有一種全新的開發模式讓我們的開發者更加專註於自己的業務邏輯呢？有的，我們認為無服務化開發的模式是很合適的。

無服務開發

什麼是無服務開發呢？

我來解釋一下，無服務化開發就相當於我們把雲資源包裝了一下，然後我們希望開發者可以盡量少去關注一些基礎設施建設和運維方面的事情，更專註於我們業務邏輯的書寫。

一般來說，我們以前通過URL發請求的方式進行前後端的通信，現在直接給你一個封裝好的SDK，無論是內置還是外部引入的，通過SDK直接操作就可以操作到雲資源了。這個模式是未來的趨勢，今天已經到來。以前我們有物理機，隨著雲服務商的發展，我們推出了PAAS、IAAS服務，基於IAAS、PAAS服務我們再做出了無服務化開發更方便於我們的開發者，這是我們的趨勢。

無服務化開發的優點其實也很明顯：

第一個讓我們更加專註業務邏輯的開發。因為我們幫開發者做了很多事情，一些高並發、高擴展、高可用的配置都不用管了，只關注業務邏輯就行了。

第二，更省人力和資金。無服務化針對某些小程序的後台功能，往往可以只由一個工程師就開發完了，為什麼只有一個人就可以呢？傳統的開發模式需要很多的儲備知識才能把一些服務做到足夠好，但由於我們的無服務開發已經幫我們做好了像備份、容災、負載等等的基礎後台和運維服務，作為一個前端工程完全可以做一些以前他不太敢做的事情，比如說資料庫的讀寫，現在都可以承包下來。

小程序·雲開發就是騰訊雲和微信在無服務開發這個領域交出的答卷。

三大核心能力

目前小程序·雲開發提供了三大能力，雲函數、雲資料庫、雲存儲。

資料庫跟存儲都比較好理解，它就是存數據以及存儲我們的一些靜態資源文件，比如說圖片、音視頻等等。

雲函數有點抽象，它就是一個代碼執行的能力，以前我們是在雲伺服器上面跑自己的一個服務，現在的話就沒有這種伺服器的概念，我們把應用拆成函數，然後把它傳到雲開發上面就可以跑這個邏輯了。

小程序雲開發的優勢

目前我們這個優勢主要有五點：

第一點，小程序·雲開發是屬於原生的服務，整個小程序的前後台開發在小程序的開發者工具里形成了閉環，在左上角有一個雲開發的控制入口，在裡面點擊之後一鍵就可以創建雲開發資源，不需要額外的操作；

第二點，可以進行快速的開發。我們提供了官方的SDK，包括前後台的，其中前端即小程序端是直接把SDK內置了。

第三點，高效鑒權。這個鑒權一會兒講得更清楚一些，其實是相當於在整個網路請求通路裡帶上了鑒權信息。

第四點，是穩定可靠，這是經過騰訊雲長期驗證比較穩定的資源項目，比如資料庫、存儲等等。

第五點，可以降低成本，一個工程師就可以扛起小程序開發的服務。

雲函數

雲函數這裡我再詳細講講它的功能和特性。

它是不需要我們去搭建伺服器，只要在開發工具裡面一鍵把我們寫好的函數上傳上去，然後通過官方提供的SDK調用。我們私有協議可以在雲函數的參數裡面可以直接獲取到APPID 、OPENID等等。它是一種比較彈性伸縮的雲資源，以前買CVM的話一定是要買一台在這兒放著，如果我的服務是很少用戶用的話，會造成我們的伺服器有很大的冗餘。現在用雲函數的話，它只有真正在用戶調用的時候啟動這個服務，如果不用就會把整的銷毀掉，所以是非常靈活的。如果我們的用戶量突然間猛增，也可以通過提升配額進行擴容。

最後一個是伺服器模式和無伺服器模式的對比。

雲資料庫

傳統伺服器模式代碼是部署在伺服器上的，我們需要考慮到服務的分層、做一個微服務或者進行邏輯解耦。我們要去做運維，做架構設計，事情非常多。而基於無伺服器的這種模式，我們其實是不用考慮太多的分層解耦的事情，它其實天然就是做了解耦了，因為雲函數更希望專註於一個業務邏輯，而且我們可以非常方便的進行擴縮容。所以如果雲函數非常適合比較有彈性的服務。

第二個是雲資料庫，它是基於MongoDB來做的，比較契合小程序這種用JavaScript來開發的應用。在小程序端直接通過內置的SDK就可以調用；另外我們有一個許可權的控制，根據不同的用戶場景進行許可權的管控。我們還可以給數據量比較大的集合添加索引，以加速數據的提取速度。

雲存儲

最後一個是雲存儲，雲存儲其實就是提供了一種能力讓我們開發者更快地把資源上傳的能力，它天然自帶CDN加速，它也有許可權的管控，與資料庫一樣根據不同的用戶場景對資源實施許可權的控制。

我們對比一下傳統開發模式跟雲開發模式的異同。

傳統開發模式，開發者就像一個保姆一樣，從前端到後台，再到運維全部都需要照顧，雲開發模式要關心的僅僅是我們的業務以及業務側的運維就可以了，從這個角度來看我們需要關心的事情非常少。

這裡舉一個例子，假設我是作為一個有一定計算機基礎的菜鳥，我需要寫一個上傳文件的高性能服務，如果是一個傳統的開發模式首先我要在小程序端調用兩個介面，把圖片給選擇起來，然後在後台搭一個服務跑起來，接收前端傳來的文件的內容。如果要做一個百萬級用戶量且不會崩掉的文件上傳服務，還要去買機器上負載做好安全管控，相當繁瑣。而如果我們用了雲開發，我們去小程序文檔上面去看一下文檔，只需要十幾行代碼就可以達到跟傳統開發模式一樣的效果。

我稍微算過，我看文檔花2分鐘，寫代碼花2分鐘，我其實花4分鐘時間就可以寫出一個高性能文件上傳的服務。

同樣道理，假設我是一個菜鳥要做一個高性能的小程序插入數據邏輯的話，用雲開發幾分種就可以搞掂的事兒，用傳統開發模式則要上千分鐘。

雲開發的架構我們是怎麼去把它搭起來的呢？首先用戶訪問小程序進行操作，小程序通過內置的SDK去操作資源，經過微信後台之後，再到達雲開發服務的後台，再通過雲開發後台去操作對應雲底層的一些資源。從這裡其實可以看到我們分別可以在小程序端以及服務端操作這個資源。並且服務端是包括了雲開發的雲函數以及我們自己原有的伺服器。所以有很多同行可能擔心如果本身已經有了小程序的後台服務怎麼跟雲開發結合呢？其實完全可以通過我們提供的SDK在你們伺服器進行操作的。

最佳實踐案例

講了這麼多功能和優勢，講講推薦的開發模式吧。

第一個我想講講怎麼操作雲開發的雲資源，尤其是在許可權的管理方面。在小程序端操作資源，只具備用戶級的許可權，就是這個小程序的用戶只能操作自己的資源，所以我們在小程序SDK上傳一個文件的時候，我們看到控制台裡面會直接帶上上傳者OPENID。如果該文件是由管理員上傳，其他用戶是沒有辦法拿到的。

資料庫也一樣，我在小程序端插入數據，這裡面會有一個OPENID，這表明除了管理員和創建者以外別人都沒有辦法進行讀寫。

如果我們要做一些更加敏感的，我們要把它放在雲函數或者伺服器上面，我們要用到管理級許可權去進行操作。我們主要通過wx-server-sdk去操作的，它的底層是基於tcb-admin-node，兩者都有管理員的許可權的。tcb-admin-node主要關注怎麼更好地操作雲資源， wx-server-sdk 則會著力提供更多微信小程序的特有功能。

這裡列舉了資料庫跟存儲許可權的設置，這裡我稍微講一講管理員讀寫這一塊。它的意思是說我要有管理員的許可權才能操作這些資源。

第二個講雲函數的最佳實踐，傳統雲函數一般是會把雲函數的業務邏輯、粒度分得很細，讓它處理單一的業務邏輯。

如果我們想要把這個業務結合一下，我們可以通過把相通的一些業務模塊，比如說用戶管理可以全部放在一個雲函數裡面，像支付的話下單、退款等支付類的雲函數我們把它放到同一個函數裡面。

甚至可以把原來的服務遷過來，把一整個服務放在一個雲函數裡面，通過路由分發的模式分發到不同的模塊中處理。

針對最後一個模式我寫了一個叫tcb-router的類似koa風格的router類庫。

講完推薦的開發模式之後，我稍微講一下實戰的案例。

比如說第一個客戶騰訊乘車碼，他們之前把大量的配置數據放到小程序里，但隨著向全國不同城市擴張，非常臃腫。用上了雲開發之後，它把不需要離線載入的配置改到雲開發上面，並剝離了一些靜態資源到雲開發的存儲服務里，這樣就讓整個的小程序的載入更快。

第二個是騰訊相冊，這個小程序的後台人力很緊缺，他們的前端就嘗試用雲開發去實踐。他們的用戶信息本身是存儲在原有的後台裡面的，所以他們決定採用混合的架構。怎麼混合呢？他們通過雲函數先去訪問一下原有的相冊服務，查詢用戶許可權，如果這個用戶是有許可權的話，它會把這個評論和贊的數據寫到雲開發的資料庫里，如果沒有就拒絕，這就是典型的原有服務和雲開發混合使用的案例。

最後一個案例是我之前給一個酒店設計的入住小程序方案。當用戶使用小程序的時候，它可以把身份證傳到雲函數裡面，通過雲函數訪問騰訊雲的智能圖象服務進行身份證的識別，如果識別成功了，雲函數會訪問原有的服務進行入住登記。從這個案例來看雲函數非常合適這種並發不是特別高的業務場景。

最後，推薦三個官方的類庫，希望可以方便大家更好地使用雲開發。

END

Merry Christmas

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！