我本人是在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類庫。
講完推薦的開發模式之後，我稍微講一下實戰的案例。
比如說第一個客戶騰訊乘車碼，他們之前把大量的配置資料放到小程式裡，但随着向全國不同城市擴張，非常臃腫。用上了雲開發之後，它把不需要離線加載的配置改到雲開發上面，并剝離了一些靜态資源到雲開發的存儲服務裡，這樣就讓整個的小程式的加載更快。
第二個是騰訊相冊，這個小程式的背景人力很緊缺，他們的前端就嘗試用雲開發去實踐。他們的使用者資訊本身是存儲在原有的背景裡面的，是以他們決定采用混合的架構。怎麼混合呢？他們通過雲函數先去通路一下原有的相冊服務，查詢使用者權限，如果這個使用者是有權限的話，它會把這個評論和贊的資料寫到雲開發的資料庫裡，如果沒有就拒絕，這就是典型的原有服務和雲開發混合使用的案例。
最後一個案例是我之前給一個酒店設計的入住小程式方案。當使用者使用小程式的時候，它可以把身份證傳到雲函數裡面，通過雲函數通路騰訊雲的智能圖象服務進行身份證的識别，如果識别成功了，雲函數會通路原有的服務進行入住登記。從這個案例來看雲函數非常合适這種并發不是特别高的業務場景。
最後，推薦三個官方的類庫，希望可以友善大家更好地使用雲開發。