李成熙 ：云开发——小程序后台服务开发最佳实践

我本人是在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类库。

讲完推荐的开发模式之后，我稍微讲一下实战的案例。比如说第一个客户腾讯乘车码，他们之前把大量的配置数据放到小程序里，但随着向全国不同城市扩张，非常臃肿。用上了云开发之后，它把不需要离线加载的配置改到云开发上面，并剥离了一些静态资源到云开发的存储服务里，这样就让整个的小程序的加载更快。

第二个是腾讯相册，这个小程序的后台人力很紧缺，他们的前端就尝试用云开发去实践。他们的用户信息本身是存储在原有的后台里面的，所以他们决定采用混合的架构。怎么混合呢？他们通过云函数先去访问一下原有的相册服务，查询用户权限，如果这个用户是有权限的话，它会把这个评论和赞的数据写到云开发的数据库里，如果没有就拒绝，这就是典型的原有服务和云开发混合使用的案例。

最后一个案例是我之前给一个酒店设计的入住小程序方案。当用户使用小程序的时候，它可以把身份证传到云函数里面，通过云函数访问腾讯云的智能图象服务进行身份证的识别，如果识别成功了，云函数会访问原有的服务进行入住登记。从这个案例来看云函数非常合适这种并发不是特别高的业务场景。

最后，这里有推荐三个官方的类库，希望可以方便大家更好地使用云开发。