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