Serverless 入门课
蒲松洋(秦粤)
前百度国际化前端组组长
16491 人已学习
新⼈⾸单¥29
Serverless 入门课
15
15
1.0x
00:00/00:00
登录|注册

05 | 后端BaaS化(上):NoOps的微服务

你好,我是秦粤。现在我们知道了在网络拓扑图中,只有 Stateless 节点才能自由扩缩容,而 Stateful 节点因为保存了重要数据,我们要谨慎对待,因此很难做扩缩容。
FaaS 连接并访问传统数据库会增加额外的开销,我们可以采用数据编排的思想,将数据库操作转为 RESTful API。顺着这个思路,我引出了后端应用的 BaaS 化,一句话总结,后端应用 BaaS 化就是将后端应用转换成 NoOps 的数据接口。那怎么理解这句话呢?后端应用 BaaS 化,究竟应该怎么做?接下来的几节课,我们会展开来讲。
我们先回忆一下上节课的“待办任务”Web 应用,这个项目前端是单页应用,中间用了 FaaS 做 SFF 数据网关,后端数据接口还要 BaaS 化。这个案例会贯穿我们的课程,所以你一定要动手 run 一下。为了让你对我们的项目有个宏观上的认识,我还是先交付你一张大图。
“待办任务”Web应用架构图
这个架构的优势是什么呢?我们将这个图变个形,你就更容易理解了。
架构变形示意图
咱从左往右看上面这张图。用户从浏览器打开我们网站时,前端应用响应返回 index.html;然后浏览器去 CDN 下载我们的静态资源,完成页面静态资源的加载;与此同时,浏览器也向前端应用发起数据请求;前端应用经过安全签名后,再将数据请求发送给 SFF;SFF 再根据数据请求,调用后端接口或服务,最终将结果编排后返回。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Serverless 入门课》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • qinsi
    请问数据库解耦时副本数据库允许数据写入吗?如果允许写入的话会不会因为写入的数据冲突导致数据不一致呢?

    作者回复: 数据副本只是为了区分的叫法,当然允许写入了。Binary log有一定的容错性,要考虑事务逻辑。但如果是银行或者支付的场景,要解决强一致性。可以直接写消息队列,再去消费数据。

    4
  • 电光火石
    老师好,在后台服务baas化的过程中,关于数据库跟以前微服务的方式有些不一样,微服务的各个节点是共享数据库的,但是baas化中,每个节点有自己的数据库,而且数据库的内容是一样的。这样是否带来2个问题: 1. 在数据量很大的情况下,每个节点都有一样的数据库,是否会使得数据存储量会翻几倍,成本会很高 2. 在扩容的情况下,如果数据量很大,新节点需要复制的数据也很多,启动时间会非常的长 3. 有多少个应用,就有多少个数据库实例。一般情况下,我们应用的数量会远高于数据库机器的数量。高并发场景下,会不会导致网络占用很高,性能整体上升 还是说这种方案本身就不适合大并发或者数据量很高的场景,谢谢了!

    作者回复: 微服务标准的做法是一个微服务实例独享一个数据库实例的。当然你业务量不大,可以多个微服务实例共享一个数据库实例。 微服务架构在docker流行后才火,就是因为docker可以让计算资源进一步碎片化,所以成本并不会很高。 数据实例的启动时,通常是先从现有数据库副本创建,再根据消息队列同步后续数据。启动实例过程是秒级的。 微服务架构,本身就是通过拆解将复杂的业务问题变成一个个小的职责单一的小服务。运维的复杂度会上升,但是整体性能并不会下降多少。 你可以想想,现在的京东,淘宝这样的网站,背后都是微服务架构的。如果你用单体应用开发这么庞大的一个应用,这么多团队和人员参与,怎么去运维和开发。

    4
    4
  • 我来也
    哈哈,原来老师也觉得云厂商提供的kafka云服务贵。 我对这个深有体会! 我看领导买的一个阿里云kafka云服务,要4K+/月,配置也就一般吧,可能监控做的比较好吧。 再想想我买的竞价付费实例,约64元/月,4cpu8g配置,还不是突发性能的。当开发环境的k8s节点,也不怕丢数据,哈哈。 想一想,还是有钱真好。

    作者回复: 用CaaS服务,自己搭建一套Kafka还便宜一些。现在程序员可以调度的机器资源还是很充沛的。

    3
    4
  • 此方彼方Francis
    微服务标准的做法是一个微服务实例独享一个数据库实例的。 这个说法有些夸张了吧?老师有生产上的实践案例吗?

    作者回复: 我这里提的微服务实例独享一个数据库实例是标准做法,这样做可以让微服务实例+数据库形成的整体,变成stateless。这个叫做:数据库的可弃性。 实际场景比较灵活,你可以一个微服务多个实例,使用一个数据库。不过你需要额外关注:这个数据库不会成为你的瓶颈。

    3
    2
  • liubin
    确实,有点扯了,每个应用副本一个db,谁来负责业务数据同步,不是kafka能解决的吧。而且事物也没法搞。这工作量比单db要大100倍

    作者回复: 首先kafka有专门的各种db同步解决方案,你可以了解一下,这门课不展开了。其次单个db对于并发量高的应用来说通常的解决方案就是分库分表,看你如何去组织而已。如果你的场景db不是瓶颈,你100个应用用一个db实例都可以。跟事务也没关系事务是数据库本身就应该保证的,同步数据库用的是数据库日志。

  • Wisdom
    一个微服务,n个实例,一个实例对应一个数据库,这种方案,有点太浪费,而且数据的一致性方面还可能会有问题,不赞同这样,京乐、淘宝也没有这样搞,感觉这里有点误导

    作者回复: 一个微服务N个实例,只用一个数据库也可以,甚至几个微服务共享一个数据库也可以。我这里举例子是在数据库是瓶颈的时候,将数据库解耦。

  • youngwang1228
    我记得是微服务说的是: 每个服务有自己单独的数据库。 假如一个服务有5个实例,每个实例独享一个数据库的话,会不会有点奢侈。 例如,一个数据库的数据量是10G,那5个库就要50G,存储成本直线上升。 而且,新加实例的话,复制一个10G数据量的库实例,时间不短吧。

    作者回复: 微服务,推荐一个实例对应一个DB。是因为通常DB是瓶颈,如果微服务实例是瓶颈也可以1:n,不过有些协调成本。 数据库通常并不是那么弹性的,需要随时从0创建。通常微服务的数据库还也是需要定期精心维护的。 微服务的拆解是为了解耦数据库,当数据库积累到一定量后也要看看能否进一步拆解。 如果你的核心业务可以做到这么庞大,公司体量也会很庞大,那就需要更加高级的架构解决的问题了。

  • PP-CIPDS-GRC
    BaaS 化只能基于 HTTP(RESTful)进行吗?可不可以基于 TCP,比如走 RPC 的方式?

    作者回复: BaaS可以基于RPC的。 不过http目前各种service mesh支持度比较广泛,可以做无侵入式网络接管。

  • 方勇(gopher)
    请问Rocketmq 10个9是怎么得出来的,是mttf 还是mttr 是一年周期么

    作者回复: 阿里云官方提供的数据:服务可用性 99.95%,Region 化、多可用区、分布式集群化部署,确保服务高可用,即便整个机房不可用仍可正常提供消息服务;数据可靠性 99.99999999%,同步双写、超三副本数据冗余与快速切换技术确保数据可靠; 数据可靠性,是数据不会丢失。实际使用的服务可用性是99.95%,尤其因为网络等等问题无法获取数据。

  • Geek_a5c054
    TypeError: Cannot read property '0' of undefined at Response.<anonymous> (/home/zyq/Downloads/todolist-backend-lesson08/index.js:182:44) 这个是为什么呀

    作者回复: 读取数据库失败了,data.row.attributes[0].columnValue。请看一下08课的答复里面内容。

    3
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部