最近需要用到阿里的全套服务，有些问题请教下大佬们

你提工单，会有人完整来找你介绍价格和 SLA 这些东西的

接口不多用函数计算还行 接口多了用函数计算管理起来头要炸

云数据库就是花钱买服务了，有钱的话很值。而且其实没加多少钱

你自己租服务器搭的 MySQL 性能会比他们卖的差很多，稳定性就不说了，卖的数据库要是挂了就是砸自己招牌，你自己搭的就全看你自个了
函数计算只支持分布式不支持单机，如果你要做有状态的服务，比如说全局 session，就必须用 redis 分布式 session，不能用单机本地内存 session 。而且函数计算有扩容冷启动响应时间毛刺，用户偶尔能感受得到卡了几秒。好处就是你不需要自己搞 k8s 那一套，扩容和缩容都是阿里帮你做，小白都能搞出来并发量很可观的接口，下限很高
至于成本，云数据库是很贵的，比你自己买服务器搭贵得多，好处在上面不多说了，除了贵没啥缺点。函数计算虽然说是按量计费的但是不一定比你自己搞服务器省钱

@xmumiffy #2 粒度是你自己把握的，不一定需要分那么多个函数

@xmumiffy 现在一般都是买云数据库了吧， 还有公司直接在云主机上再自己建一套吗？感觉自己建一套，机器的配置又要考虑要买多高配置的

@xulolololololo 想自己运维还有在云服务器上搭的，云数据库功能受限

@ch2 我感觉我要自己租个服务器来部署应用，那个函数计算用起来不太习惯，而且路由管理啥的不太方便感觉。 目前主流的是买云数据库吗，自己搭建数据库其实也行，就是配置啥的，我可能一开始不清楚需要多大配置，主要是存一些设备的数据，量级就单表百万级别。

@xmumiffy 看起来经受过函数计算的摧残，哈哈，公司就两个后端，连个运维都没有，一脸懵逼地选型中

@xulolololololo #8 路由配置啥的都是小事，函数计算本身还有很多 feature 没有开发出来，不像用服务器一开始能用什么都是一清二楚的。过个一年半载又有新的官方更推荐的写法搞出来了你还得再适配

云函数下层是容器，你可以当作你的程序在容器中运行。但是云函数和容器中程序的区别是云函数不能长时间驻留内存，也就是说如果你的请求生命周期很短，基本上云函数可以解决你的问题，但是像那种长时间运行的（举个例子超过 60 秒）的应用或者需要长时间后台任务执行的应用需要做很多其他处理。云函数也是可以做路由处理的，不过这部分逻辑需要一些额外代码处理，我记得官方文档中有例子。

自购基础服务就是找人背锅，当然你也不要太期望你自己部署套在壳子里面的性能会比他们的性能好一些...当然了，有钱人就是可以为所欲为的选择。不过如果刚开始没专职运维，考虑到你的业务上到一定层度的时候还需要专职运维相关岗位，对比在某些时间点上购买服务也是会比自建便宜。

@xulolololololo 自己搭数据库省不下什么钱，云数据库的价格基本就是两台服务器的价格，还不用自己管主从同步的事。
除非你打算数据库就弄一个服务器不做主从和备份，那自己搭可以省点钱

所谓函数计算，就是你只管写代码，不用管运维而已。价格可比买 ECS 贵多了。自己稍微懂点容器和自动化部署，就没必要用函数计算服务。

1. 不要用云厂商绑定的服务，阿里云废弃的服务可不止一个。想要部署简单，可以买 ECS 自建容器环境。
2. 如果价格不敏感，用云数据库。如果想要低成本，可以买 ECS 自建， 甚至跟程序放一台都可以。另外加一个数据库备份服务。

@xuanbg 我用过 aws 的 lambda apigateway， 感觉不太符合我的开发习惯

阿里云的 RDS 都是 2C4G，我用物理机跑 MySQL，实测性能差距百分之 150 以上……而且你还要考虑人家搭建的高可用，主备，还有提供的各种监控，然后配套设施，如果公司不是很大的话，全部依赖云商是性价比最高的选择。如果公司做到中等规模，可以选择多云模式来搞，只有真正做的很大的公司才会考虑自己搞机房的……

有钱就买云服务，没钱就自建。

@x940727 这个数据我是觉得有点夸张，都是差不多的配置吗，你的物理机是机械硬盘这数据就还可以。目前我打算租服务器部署应用，数据库直接用 rds

能用阿里云提供的就用，省事，自己搭建还需要考虑高可用等问题，阿里云直接一套全包

应用可以自己部署，一不定要函数计算（还不是特别成熟）
数据库推荐直接买，不然你自己搭建的话，考虑的因素还挺多的，数据安全性方方面面要弄好了，基本上是需要一个 dba 的（或者自己承担 DBA 的责任，主要是责任！！）

@caotian 基础服务不可能废弃，只可能升级的。所以我建议函数服务可以先官网，rds 基本上可以无脑买。楼主连这个都需要问，数据库管理的水平不会太高的

云数据库什么主从 高可用 监控告警都给你配好了，你只用自己专注业务方面的开发了。

自己搭的话一般用做测试环境, 他们卖的会带很多配套服务稳定性好很多, 也搞定很多老运维才能避开的坑, 问题就是价格特别贵... 简单点说如果是特别重要的数据, 有老运维老 DBA, 自己搭也不是不行, 平时一定做好备份, 平时可以多问问老大, 很多史诗级大坑的经验一般就三个来源: 看书看报, 他人传授, 亲身经历.

函数计算原来说的就是 ServerLess, 之前接触过一点, 总体感觉就是首先费用极低, 用多少花多少, 可用性方面, 多写纯函数(输入输出完全确定, 无状态无副作用), 性能和抗高并发方面还是挺优秀的, 主要是纯函数写多了感觉 bug 都变少了. 曾几何时强烈建议把公司所有爬虫改造成 AWS lambda + kafka 的, 比现在在用的 Hadoop 和 docker 省太多钱了. 而且运维成本基本不考虑, 关键是我不会再被其他人写的共享资源的服务给拖累了...

也有些人不太习惯 serverless 部署和调试之类的麻烦, 还是看代码能力和经验, 没啥好办法.

为什么不用腾讯云, 我觉得不管是价格,还是体验都要比阿里云好

如果用函数计算来做的话，是依赖于云平台的产品、服务稳定性的。我建议找个靠谱、真正做云产品的平台，国内可以考虑腾讯云、AWS 中国，国外可以考虑 CloudFlare 、AWS，根据场景和预算都有比阿里云更好的选择

老哥加个联系方式？我是渠道 5b6u5L+haWTvvJpnYWludXA=

@xulolololololo 2 个都是 SSD……

@xulolololololo #9 技术选型不一定是要最先进或者最牛逼，能满足业务需求并且自己能管理的才是最好
基于这种团队配置，看起来核心还是在业务逻辑上，那最好是数据库采用云平台的 paas，应用部署在 ECS 上。

后期在考虑上函数计算，作为技术演进的路线。

@xulolololololo 老哥，俺专业阿里云工具人，你那有坑位么

函数计算连 MySQL ？连接池怎么弄想过吗。

@whileFalse #30 现在有 preStop 这个 hook 接口了

@ch2 我是指函数闲置一段时间之后，数据库连接过期，但函数处于睡眠过程中，无法对连接保活，导致函数恢复运行时连接无法使用的等等情况

我是阿里云运维，可以找我了解阿里云的技术，专有网络组网、负载均衡 SLB 、NAT 网关、RDS 高可用等
vx: beautwill

@whileFalse 没实际用过函数计算，但这个连接池都有问题也太夸张了吧

我用阿里云发布过 100 多台服务器的集群，不知道有没有你想了解的。主要在于扩展性，某些成本虽然高，但是看看用云的质量不中断业务其实就已经值了，何况业务真大了，加机器就能库容才是企业级应用所追求的

AWS 深度用户路过，没用过阿里云的对应服务，但 AWS 的 Serverless （ Lambda+DynamoDB+APIGateway ）很对我胃口。

一开始确实如楼主所说，不符合传统开发习惯，但习惯以后再做传统项目，就觉得这也不爽那也不爽。所以这只是个习惯问题，没什么好坏之分。

不过没什么好坏之分是指的开发，若需要开发兼运维，那还是 Serverless 爽。尤其是云服务器，访问量稍微一大，就开始各种各样奇怪的毛病，很多是云服务器低下的 IO 性能，甚至是低配服务器被母鸡故意闲置资源所致。而 Serverless 就没有这些，还省个运维的人工成本（程序员免费加班兼任运维工作的那种公司不适用）

其实你自己买个服务器搭建服务，搭建、维护的成本就已经比直接买服务贵了。当然，如果有充足的时间且想自己搭建学点技术的可以手动。不然我还是推荐买服务。

@Rocketer 老哥居然觉得 DynamoDB 好用吗？我被它的那些查询限制恶心到了，灵活性太差了。比如简单的多个字段排序的功能都有点吃力，最后我还是组合两个字段作为二级索引的排序键才勉强能用

@xiaoqiao24 没有时间，猛压过来，刚入职一个月

@xulolololololo 这还是个习惯问题。

DynamoDB 的目标很单一，就是快，为了快，它舍弃了很多传统数据库系统提供的功能。

就拿你说的那个排序问题为例，你觉得传统数据库是怎么实现排序的呢？无非也是两种要么全读出来再在内存中排序，要么用那两个字段建个索引。你现在采取的是“索引法”，如果数据量不大的话，也可以全读出来，然后在内存中对结果执行排序算法。

看，DynamoDB 是不是跟传统数据库一模一样？只是把原先水面以下的东西拿到了水面以上而已。或者说，为了快，舍弃了传统数据库提供的包装。

其实这还算好理解的，个人觉得 DynamoDB 与传统数据库最大的区别在于数据的组合。传统上我们会用多表 join，但 DynamoDB 不好 join，只能多次查询。这让习惯传统的程序员很难受，如果你们公司有 code review 的话，一定被骂过查询太多，要求优化。

但 DynamoDB 不一样，因为它快，而且是 serverless 。这意味着我们可以同时发起成百上千个查询请求，让成百上千台服务器同时给我们干活。比如你要想把订单和用户信息组合在一起，那就先查订单，然后用异步 /协程 /多线程去同时查询这些订单里的用户 id 。不用怕，这比传统 join 还快，关键是不会形成瓶颈，就算某个查询慢了，也不会占着资源影响其它人。

@Rocketer 全查出来这种做法适应不了业务的增长性，而且查询过多的数据，占用资源多，是不是会收费更贵呢。我是刚用了半个月的 aws

@xulolololololo 传统数据库很多你以为的筛选，其实也是扫了全表。

看上去你对数据库的工作原理不是很了解，这种情况就更应该学学 DynamoDB 这种把所有本质都暴露出来的数据库了，对你使用别的数据库也有好处

@Rocketer 都全表扫， 那索引的意义何在？ 我就是单纯觉得 dynamodb 的筛选过于鸡肋，使我们可以我们可以同时发起很多个请求，一次把很多数据 load 进内存再进行筛选过滤，这样内存压力也很大吧？

@xulolololololo 一方面是习惯问题。打个不恰当的比方，玩相机的人都有一堆镜头，大部分人只习惯自动头，但有些人也习惯用手动头。其实无论手动头还是自动头，其核心原理（透镜成像）都是一样的，不一样的是外围辅助功能。

但手动头有手动头的好处，比如便宜，买一个自动头的钱能买好几个手动头，或者同价位的手动头成像质量比自动头好。

所以你如果能习惯手动头，你眼前的世界就会比别人更大一些。但如果你只想用自动头，也可以，但最好能先彻底理解一下自动头的工作原理，否则有问题你也不知道为什么。更有可能你压根发现不了问题……