小程序云开发的方方面面

## 简介

云函数的开发实战有很多，这里我就不多说，我们从企业产品的角度去思考，云开发是否值得考虑，是否能满足需求，经得起挑战，有哪些经验可以值得借鉴。

## 小程序云开发的好处

为啥要使用云开发？因为小程序有免费的云函数托管资源啊，而且还有2个哦（一般一个充当开发测试环境，一个实际生产环境），对于我这种喜欢白嫖的同学来说，肯定首选它咯，当然只是开个玩笑，对于学生党，个人开发者来说确实可以考虑的这点小费用。但是对于企业毕竟是认认真真的做一个产品，马虎不得，技术选型还是得慎重考虑下的。但不管你是高手，低手，还是新手都应该来了解下云开发的好处。

### 1、无需自建服务器

小程序云开发实际使用的也是腾讯云的serverless服务。好处就是免运维，非常方便，资源可动态扩充，但之前使用serverless服务来说也并不是很顺利，也需要做部分配置（网关API，触发器等）。而微信小程序云开发则做了更高一层的封装，真正的完全傻瓜部署，动几下鼠标就可以部署成功了。

免运维也许对于高手来说不是事，一套脚本就能轻松的搭建一套环境。但对于新手，对于大部分前端小伙伴来说，运维可是一个复杂的事情。哪怕搞一个简单APP ，一上来就nginx，jdk环境，PHP环境等一堆，还要搞一套基本的自动化部署设施，小程序后台服务的域名至少也要备个案，还得租个云服务器，整个基本的高可用，怎么也要2个台服务器吧？一买就是一年。说句不好听，产品失败，服务器又得吃灰了。云开发则帮你搞定这些烦恼，功夫再高，也要使在刀刃上。免去这些烦恼后，你就能拥有更多的时间开发业务功能。对于创业团队来说，人力和效率就是金钱，都是可减低成本的啊。

### 2、降低运营成本

假设你是一位高手，懂的如何搞服务器环境，自动化部署等。但是日后的服务维护也是需要花费一定精力的。哪天日志占满了磁盘啦，服务端口被攻击啦，某个软件（OpenSSH）出现漏洞要更新等各种问题。这些都是运维日常的工作了，如果团队不大，还要把部分精力花费这上面，那么就得不偿失了。

### 3、 自动扩展性

一般自建服务器前期都是固定的数量，但是哪天小程序搞一个有趣活动，遇到爆发性的用户访问，可能还需要继续购买服务器。而云开发能快速扩充你的应用实例，而不会出现冗长的部署和配置延迟。

### 4、开发更敏捷，功能上线更快

通常我们上线一个产品新功能都是需要对整体的服务进行完整的测试，当然现在微服务的也是可以解决这个问题。但是云函数解决的更加彻底，新功能，只要新增一个云函数即可，测试的范围就很小，异常排查也很方便。通常一个大业务会是一个云函数，细腻度完全取决于你的设计，在你的掌控中。实际上云函数就类似一个完整的微服务实例了。

## 云开发的不足

无状态：刚说到的云开发就是serverless，那么它是无状态的，因为每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。如果要共享数据，则只能通过第三方服务，比如Redis（第三方服务目前还没有）或者数据库等。

迁移成本：云开发的优点也是它的缺点，由于它帮我们做好了很多东西，也是强绑定了很多东西，比如数据库。如果需要把应用迁移到云服务器来，那么数据库目前还是需要花时间迁移，而且小程序的数据库貌似是自己产品，跟mongodb还不完全一样。代码的修改和数据库的迁移会是一个痛点。

## JWT实践

很早以前，并没有像redis那样的中间件时候，实现多个节点的服务器认证就是使用JWT方案的。云函数是无状态的，因为每次函数执行可能使用不同应用容器运行，所以不存在共享内存。类似session那样的机制就玩不转了。

虽然小程序天生免登录得到openid, 但是其他用户自填写的信息并不能得到哦，如果每次都要去数据库查询很不科学。jwt就是可以满足无状态服务的需求，把部分不是那么重要的信息在登录后，加密存在在客户端中，每次都由客户端提交上来，只要做好加密和签名校验即可。如果信息比较重要（最好不要放重要信息）即可通过加密方式，否则只要简单base64加上签名校验即可，不管哪种最好定期更换加密算法的KEY或者签名算法的key。

## 小程序开发框架wx-koa

不管是前端还是后端，都会有各种框架，框架就是为了协助大家快速的开发，解决日常开发过程中经常遇到的麻烦,更高效的开展我们研发需求。所以云开发也有一些框架可以选择的。

在做小程序开发的时候就遇到过那样的问题，官方的demo是每个接口就是一个云函数，通常一个小程序随便都十几个接口把？复杂一点的几十个，上百个。按这样的开发思路，不管是维护还是代码共用都不太方便。

其实腾讯自己serverless产品可以直接使用egg.js。nest.js的那些框架。但是小程序云函数的入口和serverless的不太一样，所以不能完全照搬那些框架进来，需要自己的改造原有的框架。

这里我选择koa, 因为源码很小，只有100多行。wx-koa跟原来koa使用是一致的，不管你之前是否用过这个koa框架，上手都非常快。因为太简单了，就不在这里阐述了，有兴趣的同学可以在github查看，另外你完全可以把nest.js egg.js对接进来，使得它可以在小程序云函数上运行，可以参考一下wx-koa思路。这样就大大的方便了我们开发的习惯和效率。也为后期服务代码的迁移，可以无缝的迁移部分业务代码到云服务器来。

有一些不需要使用框架去做所有事情，一些比较特殊的业务可以使用单独函数部署，比如一些定时任务，通常是对数据的一些定时操作，设置定时执行即可。

## 小程序的管理后台

如果我使用云开发，那么我的后台怎么办？

通常我们小程序app都是需要一个管理后台，总不能手动去操作数据库把？小程序云开发有提供对接到云函数的API接口，我们只要对接上去即可。那么我们可以创建一个admin函数，云函数我们使用wx-koa框架，然后我们再创建一个web服务直接把后台管理操作全部代理起来，所有的后台管理请求，实际就通过这个web服务转发到小程序admin函数上处理，所以这个web服务大概就是100行代码即可完成。所有的后台管理实现都在云函数上实现即可。

当然这个web服务你还是需要部署的，我建议是个人项目，部署在本地即可。建议简单的东西我都推荐使用脚本语言实现就可以了，如nodejs、php、python。wx-koa有提供一个例子，大家可以参考一下。

## 小程序数据库小坑

云数据库的主键id貌似并不是自增的，这一点让我有点的意外。。。按道理分布式ID是生成方案已经很成熟了，不知道为何不支持此特性。这里我是建议小伙伴们使用分布式ID生成，比如经典的雪花算法，MongoDB客户端也自带生成方法。有同学会问这个有啥用？通常我们需要在页面分页或者排序会用到，当然你也可以用时间戳去实现，只不过咋们可是搞企业级产品的、得严谨。

## 小程序服务混合开发，云服务和其他服务结合

小程序云开发，并不是你项目的全部选择，云开发可能不能满足你的需求，并不是最优的方案，但是值得一试的方案，轻量快速，便捷，这优点都是传统服务开发不能媲美的。

现在微服务‘肆行’的年代里，如果还不会用微服务那么就凹了，微服务概念是分布式服务，强调服务和业务。所以云开发当然可以跟传统的开发模式结合，建议把一些轻量的业务，业务耦合度小的放在云开发里。一些复杂的业务或者需要一些中间件的业务（如MQ,REDIS），可以在线下的服务去实现。而且它们之间的服务调用最好不要频繁，毕竟网络的调用太耗时了，数据的集合裁剪可以在小程序端实现。虽然不是最好的方案，但是至少解决了部分问题。

BTW，小程序也是支持函数之间调用，你完全可以设计成微服务架构的形态去开发设计你的整个系统，可想象的空间很大。不过不建议在云函数上动大刀，毕竟咋们云开发初衷就是为了方便大家快速开发，引用太复杂的架构设计必然会带来复杂的开发和维护，又背离我们的初心了。

## 小程序黑暗模式的实现思路

最近写了一个小程序叫--即刻阅，主要是看互联网资讯的，不过由于背景太亮，就实现一个黑暗模式。有不少的同学在问黑暗模式的实现方式。

首先小程序的主色调，一般是蓝色或者红色，因为这2个颜色在白色或者黑色下都能比较显眼的显示（绿色好像也可以吧），比如按钮的颜色，一些下滑线的颜色，都按一种颜色设置（一般UI框架都会有默认色调的）。图标也是一样，选择一些明亮的图标。

实现主题的变化肯定少不了一套css变量。因为我们的主色调已经有了，然后我们只需要修改字体颜色和背景颜色即可，你可以设定1-5种字体颜色深浅度，color-1: #333 ,color-2: #555, 在白色主题下是默认 color: #111 黑色字体。然后黑色背景下 color-1 应该是ccc, 默认color: #eee跟白色相反即可。背景颜色也一样的道理。所以整体设计上并不会带来太大的 工作量，我自己的那套小程序仅仅也就是多了几十行的css 样式。

黑暗模式对于部分小程序来说还是挺必要的，连微信都提供了黑暗模式，你还有啥理由不支持呢？

## 4. BTW

既然云开发 实际就是serverless托管了函数，那么使用过程中肯定会遇到不少的麻烦，某些业务场景可能无法满足你的需求。不过我们先来看看它的好处。不管你是否需要云开发，但是serverless 还是值得你使用的。

这个小程序目前还有一些功能没完善，但是整体功能还是可以的，样式UI上也有很多可以提升的地方。期待越来越好。如果你觉得有用那就给个小赞。

附上小程序码：