在40岁老架构师 尼恩的读者交流群(50+)中,最近有小伙伴拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格,遇到很多很重要的面试题:
微服务一定要用DDD,为什么?
TDD也很流行,什么是TDD? TDD和DDD 有何关系?
小伙伴没有回答好,导致大厂机会没了, 多么可惜。
所以,这里尼恩给大家做一下系统化、体系化的梳理,使得大家可以充分展示一下大家雄厚的 “技术肌肉”,让面试官爱到 “不能自已、口水直流”。
也一并把这个题目以及参考答案,收入咱们的 《尼恩Java面试宝典PDF》V164版本,供后面的小伙伴参考,提升大家的 3高 架构、设计、开发水平。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF,请到文末公号【技术自由圈】获取
微服务解决大单体架构的的很多问题,比如扩展性、弹性伸缩能力、小规模团队的敏捷开发等等。
好是好,但是微服务实践过程中,大部分架构师遇到很多难题:
微服务的粒度应该多大呀?
微服务到底应该如何拆分和设计呢?
微服务的边界应该在哪里?
拆分微服务的时候,两种情况:
很多“水货架构师”,在拆分微服务的时候凭借感觉:简单的把微服务理解为小单体,粗暴的把原来一个大单体包拆分为多个部署包,导致后期工程风险严重失控。从而陷入了微服务设计和拆分的困境。
微服务设计和拆分的困境,分成两个方面:
DDD 就是这种不可多得的微服务设计和拆分的理论和方法指导。
DDD 指导了两个层面的设计和建模:
宏观层面: 指导了微服务外部的建模,包括系统和系统之间, 微服务和微服务之间依赖关系的建模。
微观层面:指导微服务内部的建模,包括 领域对象建模, 微服服务落地的各层关系的建模。
正因为如此,DDD现在非常火爆,有其巨大生产价值、经济价值的, 绝不仅仅是一套概念那么简单。
各个大厂的大致情况是:
下面是尼恩在网上梳理到的案例, 实际上这仅仅就是冰山一角:
《阿里DDD大佬:从0到1,带大家精通DDD》
《阿里大佬:DDD 落地两大步骤,以及Repository核心模式》
《阿里大佬:DDD 领域层,该如何设计?》
《极兔面试:微服务爆炸,如何解决?Uber 是怎么解决2200个微服务爆炸的?》
《阿里大佬:DDD中Interface层、Application层的设计规范》
《字节面试:请说一下DDD的流程,用电商系统为场景》
《DDD如何落地:去哪儿的DDD架构实操之路》
《DDD落地:从腾讯视频DDD重构之路,看DDD极大价值》
《DDD落地:从美团抽奖平台,看DDD在大厂如何落地?》
《美团面试:微服务如何拆分?原则是什么?》
《DDD神药:去哪儿结合DDD,实现架构大调优》
《DDD落地:从网易新闻APP重构,看DDD的巨大价值》
《DDD落地:从阿里单据系统,看DDD在大厂如何落地?》
《DDD落地:有赞的生产项目,DDD如何落地?》
《DDD落地:从携程订单系统重构,看DDD的巨大价值》
《DDD落地:京东的微服务生产项目,DDD如何落地?》
《DDD落地:阿里供应链商品域,DDD如何落地?》
《240Wqps,美团用户中台, 如何使用DDD架构?》
《DDD落地:爱奇艺打赏服务,如何DDD架构?》
《大厂痴迷DDD:从高德portal重构,看DDD的巨大价值》
《高开面试:给一个需求,请用DDD设计出来》
测试驱动开发是一种开发方法,其核心理念是在编写实际代码之前先编写测试用例。
这些测试用例描述了所期望的代码行为。
开发者根据这些测试用例来编写代码,以确保代码通过所有测试并符合预期。
TDD的步骤通常是:
编写测试用例 -> 运行测试(测试应该失败) -> 编写代码 -> 再次运行测试(测试应该通过)。
常见的TDD框架包括JUnit(Java)、RSpec(Ruby)和unittest(Python)。
适合TDD这种模式的项目具备以下特点:
DDD如此之香,那么多大厂对DDD如此痴迷, 背后 有深层次、根本性的原因
具体参见尼恩在《DDD学习圣经》为大家深度总结的、下面的6点:
DDD 的一个根本能力,提升了 可测试性
DDD 为 TDD 的落地,提供很好的 基础支撑 和 前置条件。
面试官在问DDD之前,先会问下 微服务。
这里把这些前置问题,也给大家简历梳理一下。
微服务是由Martin Fowler大师提出的。微服务是一种架构风格,通过将大型的单体应用划分为比较小的服务单元,从而降低整个系统的复杂度。
微服务**,是一种架构风格,它将应用构建为一个小型自治服务的集合,**。通俗地说,就像蜜蜂通过对蜡制的等边六角形单元来构建它们的蜂巢。他们最初从使用各种材料的小单元开始,一点点的搭建出一个大型蜂巢。
微服务优点:
优势 | 说明 |
---|---|
独立开发 | 所有微服务都可以根据各自的功能轻松开发 |
独立部署 | 根据他们所提供的服务,可以在任何应用中单独部署 |
故障隔离 | 即使应用中的一个服务不起作用,系统仍然继续运行 |
混合技术栈 | 可以用不同的语言和技术来构建同一应用程序的不同服务 |
粒度缩放 | 各个组件可根据需要进行扩展,无需将所有组件融合到一起 |
微服务缺点:
1、服务调用的复杂性提高了: 网络问题、容错问题、负载问题、高并发问题。
2、分布式事务: 尽量不要使用微服务事务。
3、测试的难度提升了:
4、运维难度提升:单体架构只要维护一个环境,而到了微服务是很多个环境,并且运维方式还都不一样。所以对部署、监控、告警等要求就会变得非常困难。
5、微服务拆分, 缺乏统一的标准,拆分不合理会导致后面 出现 内部混乱,从 “大泥球” 演变成 更多的 ”小泥球“
DRY(Don’t Repeat Yourself) , 代表:不要重复自己。
DRY促进了重用代码/代码复用。
这意味着在多个地方不要重复同样的代码,而应该将它们封装为库或服务,以便在其他地方调用。
这种思想可以促进代码的模块化和可重用性,提高开发效率和质量。
所以,从微服务出发, 就演进出来了 技术中台、数据中台、业务中台的架构
具体请参见尼恩 《DDD 学习圣经》
但是
DRY反过来导致紧耦合。
具体答案,请参见尼恩之前写过的一个面试题答案:
美团面试:微服务如何拆分?原则是什么?
注意其中的核心点:领域驱动原则,不数据驱动原则,也不是界面驱动原则
DDD 面试题,是非常常见的面试题。大家面试的时候, 可以参考以上的内容去答,基本上 面试官会被你 震惊到、吸引到。
另外, 如果大家在实操DDD的过程中,遇到困难,也可以找尼恩求助:
此题目收入了最新的尼恩面试宝典,在面试之前,建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》,并且在刷题过程中,如果有啥问题,大家可以来 找 40岁老架构师尼恩交流。
最终,让面试官爱到 “不能自已、口水直流”。offer, 也就来了。
……完整版尼恩技术圣经PDF集群,请找尼恩领取
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF,请到下面公号【技术自由圈】取↓↓↓