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

06 | 后端BaaS化(中):业务逻辑的拆与合

你好,我是秦粤。上一课中,我们学习了后端 BaaS 化的重要模块:微服务。现在我们知道微服务的核心理念就是先拆后合,拆解功能是为了提升我们功能的利用率。同步我们也了解了实现微服务的 10 要素,这 10 要素要真讲起来够单独开一门课的。如果你不熟悉,我向你推荐杨波老师的《微服务架构核心 20 讲》课程。
BaaS 化的核心其实就是把我们的后端应用封装成 RESTful API,然后对外提供服务,而为了后端应用更容易维护,我们需要将后端应用拆解成免运维的微服务。这个逻辑你要理解,这也是为什么我要花这么多篇幅给你谈微服务的关键原因。
上节课我们将“待办任务”Web 服务的后端,拆解为用户微服务和待办任务微服务。但为什么要这样拆?是凭感觉,还是有具体的方法论?这里你可以停下来想想。
微服务的拆解和合并,都有一个度需要把握,因为我们在一拆一合之间,都是有成本产生的。如果我们拆解得太细,就必然会导致我们的调用链路增长。调用链路变长,首先影响的就是网络延迟,这个好理解,毕竟你路远了,可能“堵车”的地方也会变多;其次是运维成本的增加,调用链路越长,整个链条就越脆弱,因为其中一环出现问题,都会导致整个调用链条访问失败,而且我们排查问题也变得更加困难。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了后端BaaS化的重要模块:微服务,以及拆解和合并业务逻辑的重要性。作者首先强调了微服务的核心理念是先拆后合,拆解功能是为了提升功能的利用率。然后讨论了微服务拆解和合并的度需要把握,过细的拆解会增加调用链路和运维成本,而过粗的拆解则会降低微服务的复用性。接着,作者介绍了领域驱动设计(DDD)作为主流的微服务拆分解决方案,并强调了动态网络优化的重要性。在合并方面,作者提出了工作流的编排思路,以及使用Serverless工作流来实现业务流程。最后,作者强调了数据安全性的重要性,提出了使用CDN托管静态文件,并对FaaS服务的接口进行安全防护的必要性。文章内容涵盖了微服务拆解和合并的关键思想,以及在实际应用中的具体方法和注意事项。 总结起来,本文重点介绍了微服务拆解和合并的关键思想,包括领域驱动设计(DDD)、动态网络优化、工作流编排以及数据安全性。这些内容对于后端BaaS化的实践具有重要意义,能够帮助读者快速了解微服务架构的设计原则和实际应用方法。同时,文章还提到了发布管道的流水线和安全策略,为读者提供了在实际项目中落地这些概念的指导和参考。文章内容丰富,涵盖了微服务架构设计和实施的多个方面,对于从事后端开发和架构设计的技术人员具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Serverless 入门课》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • lyonger
    老师,请问下BaaS化就是把后端服务设计成微服务,提供标准的RestFul Api给客户端,且客户端无需关注服务端的ops工作是吧, 感觉像是后端服务直接"云化"了。

    作者回复: 你的感觉没有错。 后端BaaS化,现在就是让大家的应用后端,变成类似云服务商提供的BaaS服务。 采用HTTP,而非RPC方案,这样的好处是可以享受我们后面讲的Service Mesh接管流量,和服务发现,服务注册。

    2020-05-09
    3
  • 我来也
    今天在实践的过程中,走了些弯路,在此提醒一下同学. 实际上的架构图是'JWT示意图'. index-faas和rule-faas两个是分开部署的. 两个函数的触发器都是ANONYMOUS方式!!! index-faas中的/api/currentUser接口负责生成jwtToken. rule-faas中接口/api/rule的post、delete、put方法才验证jwtToken. 作为实验,可以在`新建`代办前,将浏览器中的cookie移除,再请求时会收到403的错误码.

    作者回复: 陈独秀同学~

    2020-04-29
    2
  • miser
    或许我有基本的后端部署认知,我感觉serverless在架构设计上意义不大,但是在人员安排上意义重大,对于前端来说可以不太关心运维的工作,代码推上线就完了,它帮助前端或者不太懂运维的开发者解决了大量运用工作,降低了上线成本和学习成本。

    作者回复: 是的,未来组织结构和架构演变上,前后端分离会更加彻底。前端同学可以自己写FaaS编排服务,后端同学专注写BaaS。FaaS还具备价格优势。

    2020-04-29
    1
  • 吴科🍀
    老师的课程实践性很强。实验的例子,如果没有云服务器,可以在本地环境模似吗。

    作者回复: 可以的,我后面的实践课就是教大家在本地搭建环境。

    2020-04-29
    1
  • Programmer
    老师想咨询一下,为什么“待办任务”架构图到这一节没有SFF层了呢,这里的faas函数充当什么角色呢

    作者回复: SFF层是可选项,通常是后端比较完善或者已经比较成熟的团队,用FaaS做服务编排,将后端的服务通过这一层聚合数据给前端使用。 这里是FaaS的另外一种用法,直接将node.js应用整个运行在FaaS函数里面,index-faas.js是入口文件。

    2021-10-28
  • 神仙朱
    老师好,现在我们做的作业就是baas吗,怎么感觉还是在faas中做,这样还是不能连数据库哇

    作者回复: 这个是给大家展示用FaaS去做微服务。不是不能连接数据库,FaaS本身并没有做限制。具体的应用场景,可以都尝试一下,体验一下优缺点。Serverless未来也会针对各种场景优化,只要官方不做限制,都可以多尝试一下。

    2020-07-06
  • 左耳朵狮子
    "线上根据灰度策略,将小部分流量导入灰度环境验证灰度版本。" 老师这块能否说的再细一点。 假设在Cloud-native 开发中,小部分流量倒入这个docker container(s) 来验证,如果灰度发布不成功。是否多个containers 全部销毁,还是编排到其他containers。

    作者回复: 灰度发布不成功,只需要撤回灰度版本就可以了。撤回后需要重新修改验证,再次发布,直到灰度版本成功。 这个类似于多版本在线的概念,后面Knative会讲到如何控制多版本流量分配权重。 线上版本用K8s或者Knative的方案都支持版本回滚。

    2020-05-19
  • 我来也
    我昨天实践了云溪社区的一篇文章,是关于Serverless进行CI/CD的. 觉得值得一看,推荐给大家. [Serverless 实战 —— Funcraft + OSS + ROS 进行 CI/CD](https://yq.aliyun.com/articles/741414) 该文章,演示了发布前的验证环节. 后面的回归验证和灰度流量验证,就需要其他技术了. 比如借助k8s方便的部署多套环境,进行回归验证. 使用k8s/istio实现金丝雀/灰度发布.

    作者回复: 文中提的前后端分离方案,其实中间SFF可以抽象出接口层。后端同学做微服务,针对文档化接口编程,很容易测试。前端同学自己写FaaS编排后端BaaS,也很容器Mock测试。前后端,各个微服务分开迭代测试发布。 掌握了这些工具,其实研发流程和架构设计,随手拈来。所以现在也有云开发者的概念,未来大部分开发者应该都掌握云服务的各种能力。

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