美团面试:微服务如何拆分?原则是什么?

尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中,最近有小伙伴拿到了一线互联网企业如美团、字节、如阿里、滴滴、极兔、有赞、希音、百度、网易的面试资格,遇到很多很重要的面试题:

微服务如何拆分?

微服务拆分的规范和原则是什么?

谈谈你的DDD落地经验?

谈谈你对DDD的理解?

最近有小伙伴在美团,又遇到了相关的面试题。小伙伴懵了, 当然,面试也就挂了

这里尼恩给大家做一下系统化、体系化的 DDD、微服务拆分的 梳理,使得大家可以充分展示一下大家雄厚的 “技术肌肉”,让面试官爱到 “不能自已、口水直流”

也一并把这个题目以及参考答案,收入咱们的 《尼恩Java面试宝典PDF》V128版本,供后面的小伙伴参考,提升大家的 3高 架构、设计、开发水平。

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF,请到文末公号【技术自由圈】获取

除了本文,尼恩输出了一个 《从0到1,带大家精通DDD》系列,帮助大家彻底掌握DDD,链接地址是:

《阿里DDD大佬:从0到1,带大家精通DDD》

《阿里大佬:DDD 落地两大步骤,以及Repository核心模式》

《阿里大佬:DDD 领域层,该如何设计?》

《极兔面试:微服务爆炸,如何解决?Uber 是怎么解决2200个微服务爆炸的?》

《阿里大佬:DDD中Interface层、Application层的设计规范》

《字节面试:请说一下DDD的流程,用电商系统为场景》

《DDD如何落地:去哪儿的DDD架构实操之路》

《DDD落地:从腾讯视频DDD重构之路,看DDD极大价值》

《DDD落地:从美团抽奖平台,看DDD在大厂如何落地?》

大家可以先看前面的文章,再来看本篇,效果更佳。

另外,尼恩会结合一个工业级的DDD实操项目,在第34章视频《DDD的顶奢面经》中,给大家彻底介绍一下DDD的实操、COLA 框架、DDD的面试题。

文章目录

    • 尼恩说在前面
    • 微服务设计的规范和原则
      • 1.准备好微服务治理基础设施
      • 2.单一责任原则(SRP)
      • 3.松耦合原则
      • 4.领域驱动原则,不数据驱动原则,也不是界面驱动原则
      • 5.架构分层职责明确,严守调用规范,规避 “微服务小泥球”
      • 6.进行全方位的监控、记录
      • 7.通过CI/CD实现devops (开发运维一体化),提升工程效能
      • 8.基于业务需求变化频率进行微服务拆分
      • 9.基于吞吐量进行微服务拆分
      • 10.基于技术异构因素进行微服务拆分
    • 参考文献
    • 未完待续,尼恩说在最后
    • 尼恩技术圣经系列PDF

微服务设计的规范和原则

单体架构往往以烟筒式方式发展,往往存在两个主要问题:中心化高耦合

所谓中心化,就是数据集中存储在单个数据库中,业务系统集中部署在单台服务器上,通过集群部署方式提供服务能力,然而中心化的问题,也就是单点问题。

所谓高耦合,主要是指其中一个功能模块升级,其它的模块都得一起升级。模块依赖度高的本质是架构腐烂。因为本来架构可能就没有设计好,但是,在实际场景中,随着快速迭代开发,研发换了一波又一波,产品走了一茬又一茬,难免系统架构腐化严重。

如何解决单体架构的问题呢? 方案很多,主要有: SOA、微服务架构。

SOA(Service-Oriented Architecture,面向服务的架构)是一种高层级的架构设计理念,可通过在网络上使用基于通用通信语言的服务接口,让软件组件可重复使用。SOA 集成了独立部署和维护的服务,并允许它们相互通信和协同工作,以构建一个跨不同系统的软件应用。

微服务(Microservices)是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模块化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic)的API集相互通信。

2014年,Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用HTTP API通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力,服务可以用不同的编程语言与数据库等组件实现。

如何 做单体架构 到微服务架构的升级呢?

1.准备好微服务治理基础设施

微服务首先需要有微服务基础设施,没有微服务基础设施,实践微服务就是一场灾难。

美团面试:微服务如何拆分?原则是什么?_第1张图片

注意:请点击图像以查看清晰的视图!

2.单一责任原则(SRP)

SRP是微服务架构重要的原则。

每个微服务都应该负责一个单一的业务,并确保做好这个业务,这个业务粒度的大小取决于你对业务和架构综合考虑。

SRP能够确保微服务职责单一性、功能完整性拆分, 这样,就便于维护、测试和部署。

美团面试:微服务如何拆分?原则是什么?_第2张图片

注意:请点击图像以查看清晰的视图!

3.松耦合原则

什么事松耦合:松耦合是指每个微服务都应该是独立的,并通过API与其他服务进行通信。

松耦合的优势:可以降低 级联故障 的风险,也可以提高服务可扩展性,提高微服务的可复用性。

尽量做彻底解耦,包含数据库层的解耦:

  • 数据库层的解耦,就是避免一个微服务与其他微服务共享数据库,因为这可能会导致数据不一致,并且会使故障排查变得非常困难。
  • 每个微服务也都应该只管理自己的数据,每个微服务都有自己的数据库来存储数据,以确保可扩展性和可靠性。

在设计微服务时,应该专注于创建小型、松散耦合和高度内聚的服务。

美团面试:微服务如何拆分?原则是什么?_第3张图片

注意:请点击图像以查看清晰的视图!

4.领域驱动原则,不数据驱动原则,也不是界面驱动原则

DDD是一种软件设计方法,它专注于特定业务领域的软件设计。

微服务架构、微服务设计非常适合采用DDD,为啥呢?

因为每个服务都可以设计为特定业务领域的具体实现。

美团面试:微服务如何拆分?原则是什么?_第4张图片

注意:请点击图像以查看清晰的视图!

领域驱动设计,首先应建立领域模型,确定领域限界上下文,然后才进行微服务拆分,

如果是 数据驱动原则/界面驱动原则 ,那么,是一上来就定义数据库表结构,就去调整领域逻辑代码。

领域模型和领域服务应具有高度通用性、稳定性,通过接口层和应用层屏蔽外部变化对业务逻辑的影响,保证核心业务功能的稳定性。

基于领域模型进行拆分,围绕业务领域按职责单一性、功能完整性拆分。

5.架构分层职责明确,严守调用规范,规避 “微服务小泥球”

老的单体架构, 常常被成为大泥球。

“大泥球”单体,主要的问题

  • 代码腐化:业务代码经过长时间的迭代,有很多重复代码。比如一个功能可能有 3,4 种实现。
  • 业务逻辑交织:业务应用经过长时间发展,功能变多,业务功能里的逻辑代码可能相互引用,交织不清。
  • 代码复杂:功能多,业务逻辑复杂,只有少数员工能理解。这也是代码腐化一种。
  • 维护性变差:修改 bug 或增加新功能时,牵一发而动全身。一个 bug 没修好可能导致整个软件不可用。
  • 扩展性变差:增加新功能时,牵一发而动全身。
  • 编译发布变长:软件代码量大,编译时长变长,导致发布时长也变长。

化解“大泥球”单体的措施,是微服务架构。微服务架构最基本的一个点:分而治之,由大化小。

  • 松耦合:划分为一个一个小的微服务,代码之间逻辑交织降低。
  • 独立部署:每个划分的微服务都是一个独立的项目,可以独立部署。
  • 编译发布改善:划分为独立的小项目,编译时长变短,发布时长相应变短。
  • 故障隔离:由于划分为一个一个微服务,故障仅发生在独立的微服内。
  • 可扩展性:每个服务可以独立横向扩展,也可以从应用程序中提出独立功能变成服务,扩展变强。
  • 职责单一团队:每个小的微服务都由一个小型的高度专注的团队负责。
  • 技术异构:每个团队可以选择适合该业务的技术。

微服务架构目的就是把一个大单体划分为各种微服务,松耦合,独立自治。

微服务架构把一个大泥球,变成了很多个小而美的颗粒。

每个小颗粒职责单一,边界明确,可以通过简单组装完成大的功能,自然就比之前的大泥球好处理得多

但是,迭代过程中,出现了一种奇怪现象,微服务内部没有进行内部的模块划分,代码耦合严重,调用关系混乱,就像一个小泥球。

在腾讯视频的DDD重构案例中,在老的微服务架构中,存在分层不明确,下层服务过于理解业务逻辑,存在下层调用上层的问题,出现了代码耦合严重,调用关系混乱的 “微服务小泥球”。

具体请参考《DDD落地:从腾讯视频DDD重构之路,看DDD极大价值》

在腾讯视频的DDD重构的过程中,明确架构分层,降低模块间不必要的耦合;

严格遵守分层架构原则,上层服务可调用下层服务,下层服务不涉及业务逻辑。如上下层服务需交互,可通过逻辑解耦方式实现,如消息队列或中转。

如果规避 “微服务小泥球”? 各层职能定位清晰,只能上层调用下层,也就是说只能从外层调用内层服务,下层服务通过封装、组合或编排对上层暴露,服务粒度由细到粗。

微服中,各层职能定位清晰:

  • 基础层为各层提供资源服务

  • 领域层负责领域业务逻辑的实现

  • 应用层负责服务的编排和组合

  • 接口层对外进行服务暴露

美团面试:微服务如何拆分?原则是什么?_第5张图片

注意:请点击图像以查看清晰的视图!

6.进行全方位的监控、记录

监控和日志记录对于微服务架构的安全、维护和调优都至关重要。

在拥有数百个微服务的项目中开发的主要困难之一是调试非常困难,因为服务分散、日志分散,很难找到失败的原因。

因此,每个服务都应该有日志记录和监控措施,以跟踪其性能并检测错误。

美团面试:微服务如何拆分?原则是什么?_第6张图片

注意:请点击图像以查看清晰的视图!

7.通过CI/CD实现devops (开发运维一体化),提升工程效能

CI/CD是一种软件开发运维过程实践,打通开发和运维环节,实现应用程序的构建、测试和部署自动化。

任何微服务都应该是可持续部署的,实现微服务的快速高效部署,缩短了微服务上线时间。

美团面试:微服务如何拆分?原则是什么?_第7张图片

注意:请点击图像以查看清晰的视图!

总之,采用微服务架构开发有许多优势,但要确保为微服务系统成功实施就需要遵循一些设计原则。

包括但不限于上面介绍的几个基础原则,在此基础上还需要有与所在领域或者行业的做定制化优化实践。

8.基于业务需求变化频率进行微服务拆分

这是一条扩展原则,是一条针对特定场景的的微服务拆分原则。

分离变和不变, 是 设计领域遵守的一条 核心的原则。

识别变动频繁的业务需求和领域模型,考虑业务变更频率与相关度,将业务需求变动较高和功能相对稳定的业务进行分离。

经常性变动必然会导致代码的频繁修改和版本发布,分离变和不变,可以有效降低频繁变动业务对稳态业务的影响。

9.基于吞吐量进行微服务拆分

这是一条扩展原则,是一条针对特定场景的的微服务拆分原则。

识别领域模型中性能压力较大、高吞吐量的功能,并且进行解耦,解除独立的微服务。

两个好处:

  • 避免高吞吐服务,拖累整个系统的性能, 由于局部的性能拖累整体性能。
  • 解耦之后,可以对高吞吐量服务定制个性化的 扩容缩容策略、熔断保护策略、限流策略。

10.基于技术异构因素进行微服务拆分

这是一条扩展原则,是一条针对特定场景的的微服务拆分原则。

领域模型中有些功能虽然在同一个业务域内,但在技术实现时可能会存在较大的差异,也就是说领域模型内部不同的功能存在技术异构的问题。

比如,在尼恩的go+java 双语言云原生架构实操中, 有的可能用go,有的则是 Java,当然,还有的微服务用大数据架构。

所以,对于这些存在技术异构的功能,可以考虑按照技术边界进行拆分。

参考文献

https://www.51cto.com/article/769421.html

https://blog.csdn.net/inaoen/article/details/121107764

https://www.jianshu.com/p/1c16195e9a1b

未完待续,尼恩说在最后

微服务拆分、DDD 面试题,是非常常见的面试题。

大家面试的时候, 可以参考以上的内容去组织答案,如果大家能做到对答如流,如数家珍,基本上 面试官会被你 震惊到、吸引到。

另外在面试之前,建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》,并且在刷题过程中,如果有啥问题,大家可以来 找 40岁老架构师尼恩交流。

最终,让面试官爱到 “不能自已、口水直流”。offer, 也就来了。

当然,如果面试过程中,项目low,简历low,表达low,也可以找尼恩进行简历再造、项目再造,

再造之后,很容易获得面试官的青睐。

然后,依靠降维攻击, 实现快速 升级,快速上岸。

解锁:一个进大厂的捷——降维打击

尼恩技术圣经系列PDF

  • 《NIO圣经:一次穿透NIO、Selector、Epoll底层原理》
  • 《Docker圣经:大白话说Docker底层原理,6W字实现Docker自由》
  • 《K8S学习圣经:大白话说K8S底层原理,14W字实现K8S自由》
  • 《SpringCloud Alibaba 学习圣经,10万字实现SpringCloud 自由》
  • 《大数据HBase学习圣经:一本书实现HBase学习自由》
  • 《大数据Flink学习圣经:一本书实现大数据Flink自由》
  • 《响应式圣经:10W字,实现Spring响应式编程自由》
  • 《Go学习圣经:Go语言实现高并发CRUD业务开发》

……完整版尼恩技术圣经PDF集群,请找尼恩领取

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF,请到下面公号【技术自由圈】取↓↓↓

你可能感兴趣的:(面试,技术圣经,面试,微服务,java,架构,后端,ci/cd,系统架构)