上周与 boss 沟通了一下，试图向 boss 解释 serverless 的优势，但 boss 最终一句话让我无语：“你用什么技术我不关心，但必须要能够根据客户的要求进行任意独立、私有化部署，客户买云服务器，不管是阿里云、腾讯云还是华为云，都要能支持。客户自己的服务器，还要能支持”。
不可否认，unicloud 确实很好用，但如果官方迟迟不推出平民化私有化部署解决方案，相信全国像我一样千千万万的开发者，都将面临放弃 unicloud 的艰难选择。
望官方听取广大开发者的心声。
联系过官方，但是价格太贵了， unicloud想发展 肯定要平民化独立部署，建议要开平民化部署呀，很多项目都是因为独立问题转移到了java php，希望官方给予“unicloud平民化独立部署”服务方案！
因为对unicloud的热爱与对云开发趋势的信心，所以我们愿意投入精力发起建议，供大家讨论，无论是否被采纳，这都是对开发者社区活跃的一种促进，能被采纳或者有更好的方案，直接受益者是广大的开发者，最终的受益者是unicloud。新方案下unicloud或许有新的收费模式，广大开发者为价值买单不差钱！
回复 博览群书: 谢谢解答，自己购买服务器，那是不是就不能自动弹性扩容了（只买一台服务器的情况下），这样的话就失去云开发最大的优势了。本身就是冲着低成本、高性能/安全来的。我是觉得只要让开发者能够自己控制腾讯云/阿里云资源账号就可以了。这样开发者才能完全控制自己的项目也能同时使用云厂商提供的其他服务（比如调用自己在云厂商的其他资源），不知道我这个想法是否合乎实际。
回复 oooooo3383: 你是没用过，现在一个月基本的要99元， 19元那个配置基本没法用，99元的也就只能调试用！其次最重要 客户需要部署到自己服务器的 这个是弊端！
回复 oooooo3383: 那种单位吧，都是特定业务，使用量很小，单台服务器就够了，比较常见的情况通常是开发一个系统，然后每个月就用3天左右，并发访问都不超过100，主要就是数据要保密，现在啥都保密，关注安全嘛
服务器维护这事一点都不小，以往的系统环境部署都非常成熟了，所以你觉得简单，而且以往的大多都是单台服务器，这种云架构肯定没那么简单，至少目前不容易维护，还没有形成一个成熟的框架，需要的人自然会用，不需要的人再好的东西都没用，就目前的情况中小应用足够了，大型应用一般也不会轻易的更换为一个不太成熟的框架，一旦承载不了满盘皆输。
任何事物都不能催熟，技术更是如此，必然是需要一个时间去沉淀
别以往，就说现在，什么云架构也都是直接部署到服务器里的，我手上现在有7台服务器，系统数量那就更不用说了，有什么可维护的，就那么点东西，夸大其词。“到需要非常高级别的维护，那就盈利百万了，就需要专业的运维，专业的团队级别了！ 初期别提什么服务器维护！”
官方继续沉默中，而我的下一个景区小程序项目已经开始启动，甲方明确要求独立部署，因此该项目只能放弃 unicloud。相信越来越多的开发者不得不做出这样的选择。
“开发者逃离 unicloud，官方，这难道是你们的选择吗？”
回复 oooooo3383: 除了有自己独立机房，运行在自己机房服务器的项目，至于其他的，所谓的要求独立部署在自己的阿里云或者腾讯云或者什么云服务器，本质上跟让他自己注册一个 unicloud 账号买个云空间，是一个意思，只不过是客户还没有接受这个东西而已。
你这个问题确实是很实在的问题，需求。对于客户、公司而言，把dcloud开发者的账号给客户不现实。客户一般都是希望买了云服务器，能给我部署上去，源码交付，东西都在自己手机。即使在公司上班，公司都是希望有一定自主权，而不是别卡脖子。
DCloud这边是希望尽可能满足开发者的各种需求的。
独立部署目前的成本降不下来，主要还是投入产出的原因。
只有足够的用户量才能把单个用户的成本摊下来。
目前还不具备这样的条件，但我们会持续评估。
我一个45岁的老程序员，努力学习和适应了云开发模式，感觉比较有前景，开发效率也提高了不少，结果客户一句话要求部署到他们自己的服务器，还是得乖乖的迁移到C#环境里面。。。
强烈建议unicloud开发一个类似php+mysql整合的东西，让用户可以直接部署到自己服务器。现在的政府项目对安全要求特别高，都是放在政务云上，不可能用外面的云空间，如果必须放公共云，转私有化费用还那么高，那么这块市场基本就失去了。
针对您提到的uni-app结合unicloud独立部署以应对万人请求的场景，这里提供一个简化的代码案例和配置示例，以帮助您理解如何构建高效、可扩展的后端服务。请注意，实际应用中还需考虑负载均衡、数据库优化、缓存策略等多方面因素。
1. 初始化unicloud项目
首先，确保您已经安装了HBuilderX并登录DCloud账号。在HBuilderX中创建一个新的uni-app项目，并选择集成unicloud服务。
2. 配置unicloud云函数
在uniCloud/cloudfunctions目录下创建一个新的云函数，例如requestHandler。
requestHandler/index.js
// 引入uni-cloud的db模块
const db = uniCloud.database()
exports.main = async (event, context) => {
// 假设处理一个简单的GET请求
const { action, data } = event
switch (action) {
case 'fetchData':
const collection = db.collection('your_collection_name')
return await collection.where(data).get()
default:
return { error: 'Invalid action' }
}
}
requestHandler/package.json
确保包含必要的依赖，如uni-cloud等（通常由HBuilderX自动生成）。
3. 配置云函数触发器
在uniCloud/cloudfunctions/requestHandler/trigger.json中配置HTTP触发器，以便外部请求可以触发该函数。
{
"triggers": [
{
"name": "httpTrigger",
"type": "http",
"config": {
"auth": "open", // 可根据需要设置为open（公开）、function（函数级鉴权）或admin（管理员鉴权）
"methods": ["GET", "POST"] // 支持的HTTP方法
}
}
]
}
4. 部署与测试
在HBuilderX中，右键点击uniCloud目录，选择“部署云函数到云端”进行部署。部署完成后，可以通过生成的云函数URL进行测试。
5. 性能优化考虑
- 负载均衡：使用云服务商提供的负载均衡服务，将请求分发到多个云函数实例上。
- 数据库优化：根据查询模式设计索引，使用分片等策略提高数据库性能。
- 缓存：利用Redis等缓存服务，减少数据库访问压力。
- 自动扩缩容：配置云函数自动扩缩容规则，确保在高并发时能够自动增加实例数量。
上述代码和配置仅为示例，实际项目中需根据具体需求进行调整和优化。希望这能帮助您开始构建能够应对万人请求规模的uni-app+unicloud应用。
