论uniCloud作为服务端的利弊

zxaf2012

uniCloud 是 DCloud 联合阿里云、TX云，为开发者提供的基于 serverless 模式和 js 编程的云开发平台。
unicloud  主要是用于uniapp的后端，联通两者提供了一套完整的体系

我已经写了一整套完整的网络验证，从0走，技术上面没有压力，轻轻松松，不需要搜索外部资料，点着官网动，有手就行，使用过程中给出一下的一些看法。

[size=1.65]使用场景

云函数/云对象URL化 是 uniCloud 为开发者提供的 HTTP 访问服务，让开发者可以通过 HTTP URL 方式访问到云函数或云对象。

• 场景1：比如App端VX支fu，需要配服务器回调地址，此时需要一个HTTP URL。
• 场景2：非uni-app开发的系统，想要连接uniCloud，读写数据，也需要通过HTTP URL方式访问。
  

url化后需要注意以下几点

• 安全：为了保障业务安全性，开发者需在代码中做好权限控制和安全防护，避免未授权访问触发敏感操作。
• 计费：云函数开启了URL化后，如果遇到大量恶意访问，消耗云函数资源，开发者可以将云函数访问地址设置为空即可停止 HTTP 访问支持。
  

这样是支持我们来用其作为  服务后端的  


利【快就一个字，我只说一次】：
无需配置服务器，nodejs的优势，按需增配
搭配框架  可以很快很快的写出一个curd ，满足大部分需求
联通APP端，一套框架  应用与两个端  没有问题
nosql数据库

弊 【不要来扯高防服务器】：
需要遵守规定，比如绑定域名才有更多并发等，但云函数方面没有看到具体规定，有个大纲不知道是否也限制到云函数URL化
最主要的一点，怕攻击，官方建议就是 被攻击了你就关了 有点搞笑，解决不了问题解决自己
一些插件要购买 redis等
数据库无法分布式
不受自己控制，出了问题就是提工单，有时候很卡  ，理论压力不应很大，可能是没有绑定云函数域名问题
可以请求外部的api，不过走资源。

解决方案：

我认为最重要的  被攻击或者恶意访问 体验直接为0 ，虽然所有服务器都可能遇到。
应该购买1+N个转发服务器，只有一个目的，转发请求，缓存处理。

转发请求：
设置路由规则进行一个转发限制，转发服务器本身应该具备对缓存的处理流程，且部分缓存更新接口，对击穿做出防护
如果有条件，直接上分布式，用来 unicloud 请求更新缓存，走统一网关

我们大部分的抗揍放到转发服务器上面，基于的缓存模型减少unicloud的配置，核心逻辑数据库扔到unicloud ，解决这个问题

对于转发服务器被击穿奔溃等情况，由于不需要核心业务逻辑，可以分布式多个转发服务器，懂得都懂

unicloud的数据做同步备份问题，在curd增加中间层



这是对于个人业务者非团队的情况下适用，业界通用的分布式微服务架构呢，不做评价，我只能说  开发很快这个东西 你可能几天就搭起来一个  ，而且试错调试成本低，基本问题一看就知道哪里 ，nodejs嘛。。。。。。

衍生考虑：

基于 serverless 模式和 js 编程 大行其道，前端写后端，模式体系已经成熟，本地部署方面资料较少，
我是一个后端开发，但前端基本也都写


思考下：不考虑本地部署的情况，这玩意看起来要干掉后端的样子，来势汹汹。


可能就是以前开发代码 不考虑技术问题，运行还要烧香。


现在是让大厂来给你保障？？？？ 好吧 一技之长。。。。

qq1695283376

让前端人不关系后端配置 但是很多功能还是不行

努力赚钱的猪

让前端人不关系后端配置
但是很多功能还是不行

zxaf2012

我觉得可以开发一套请求防护系统，对接给所有软件开发者使用，配置好自己的路由，然后防护系统来做请求防护和压力减缓，按月付钱就行，是个出路 哈哈，这样开发就不需要考虑杂七杂八的问题了