尼恩说在前面

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

谈谈你的DDD落地经验?

谈谈你对DDD的理解?

如何保证RPC代码不会腐烂,升级能力强?

微服务如何拆分?

微服务爆炸,如何解决?

你们的项目,DDD是怎么落地实操的?

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

也一并把这个题目以及参考答案,收入咱们的 《尼恩Java面试宝典PDF》V137版本,供后面的小伙伴参考,提升大家的 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神药:去哪儿结合DDD,实现架构大调优

DDD落地:从网易新闻APP重构,看DDD的巨大价值

DDD落地:从阿里单据系统,看DDD在大厂如何落地?

DDD落地:有赞的生产项目,DDD如何落地?

DDD落地:从携程订单系统重构,看DDD的巨大价值

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

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

DDD现在非常火爆,是有其巨大生产价值,经济价值的, 绝不仅仅是一套概念那么简单。

DDD的绝大价值,具体请参见以下视频:

从腾讯视频DDD重构案例,看看DDD极大价值

本文目录

- 尼恩说在前面

- 一、前言

- 二、首先,我们需要思考一下:什么是微服务架构?

  - a. 白马是马

  - b. 服务治理

  - c. 十二要素

- 三、其次,我们的问题焦点:微服务架构的难点是什么?

  - 第一个难点, 微服务的服务治理和流量治理。

  - 第二个难点, 微服务拆分的架构思想.

- 四、最后,来点干货:采灵通系统–微服务架构落地实践

  - 1. 业务场景解析

  - 2. 技术架构解析

    - 1)业务前端层

    - 2)网关层

    - 3)业务服务层

    - 4)技术底座层

  - 3. 最终服务落地

- 五、总结

- 说在最后

- 部分历史案例

一、前言

作者:京东物流 赵勇萍

现在对于一个后端开发工程师来说,微服务,DDD都是挂在嘴边的东西,感觉大家接触到多,也了解的多。然而,个人对微服务架构的理解却如同我小时候读《三国演义》,随着年龄和经验的增长,感受也各不相同。微服务对于开发人员而言,如同千面镜,每个人看到的风景都独具特色。基于此,我想结合自己的业务实践,分享一下在微服务架构实践过程中的心路历程。

二、首先,我们需要思考一下:什么是微服务架构?

图片

在笔者看来,微服务架构并没有一个准确的定义,但他会有很多特征,通过描述他的特征用来把控它是什么。

a. 白马是马

这是一个哲学命题,表明个别和一般的关系。我认为,任何的技术和架构都不是凭空出现的,一定是发展而来,而微服务架构的前身就是SOA,面向服务的编程。SOA是一种架构设计模式和思想,微服务架构继承了这一思想。在我看来,微服务就像是那匹白马,它将复杂系统从业务视角划分为独立的模块,每个模块都具有提供服务的能力。基于这些能力,我们构建了一个复杂的系统架构,并在此基础上演化了去中心化和分布式思想。

b. 服务治理

以上说的是思想层级,在战术层面,微服务架构的核心诉求和能力在于服务治理,包括服务寻址、流量管理、可观测性等。

c. 十二要素

Heroku创始人Adam Wiggins 提出的微服务十二要素,下面,我贴出我对微服务十二要素的解读:

图片

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

这十二要素可以说是微服务架构的方法论,有了思想,方法论和战术维度,我觉得就可以完整的描绘出一个微服务架构的全景图。然后,我将我理解的微服务架构总结成一句话:

微服务架构是一种去中心化的分布式服务架构,具备服务寻址、故障容错、流量调度、控制访问和可观测性的服务治理能力,从而实现服务的隔离性、可移植性、可扩展性和稳定性。

三、其次,我们的问题焦点:微服务架构的难点是什么?

笔者认为,微服务的两个核心点正事他的难点:

第一个难点, 微服务的服务治理和流量治理

对于这个难点,现阶段已经有了很好的解决,因为服务治理和流量治理具有去业务场景化的特点,许多先行者通过努力和开源框架的贡献,使我们能够直接应用并实现良好兼容。以下是一个典型的微服务治理架构图:

图片

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

第二个难点, 微服务拆分的架构思想

如何基于领域驱动设计(DDD)方法论将服务分解落地。这里涉及许多核心能力,如子域划分、限界上下文定义、实体、聚合根抽象、基于领域事件的事件驱动设计,以及工厂模式、策略等设计模式的应用。

这第二个难点是很难做到直接的迁移,因为面对的业务场景各异。前人经验只能以思想为指导,但具体的实施将考验每位架构师的经验和理解。如同画家对同一景色的诠释各异,有的成为梵高,有的成为毕加索。对我而言,现阶段可能只是一个初学素描的爱好者。然而,我仍愿意分享我在采灵通项目中对微服务落地的经验,供大家参考。

四、最后,来点干货:采灵通系统–微服务架构落地实践

笔者负责的采灵通业务是一个相对复杂的系统,带领20人的开发团队历时5个月,从零开始设计、开发并上线。该系统涵盖了ToB全供应链数字化相关的全场景业务。下面将从业务场景分析、技术架构解析和服务落地几个方面解读该系统的实践过程。

1. 业务场景解析

理解DDD的前提是先要理解业务场景,笔者的业务场景是采灵通SAAS系统,在此简单做一个业务介绍:

采灵通是一个标准的提供B商城触达的,同时解决企业数字化采购供应链的SAAS平台,核心能力包括多供应商协同,订单管理,商品管理,客户管理,及B商城的搭建和管理,具体如下图所示:

图片

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

2. 技术架构解析

基于以上业务场景,我们构建出我们的技术架构方案,如下图所示:

图片

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

在技术架构上,整体分为四层,自上而下为:业务前端层, 网关层, 业务服务层,技术底座层。

1)业务前端层

前端根于业务场景,有多个触达端,最主要的端有供应商管理端,伙伴管理端,PC商城端,H5商城端, 页面装修系统。前端封装有统一的组件库,保证了整个系统的前端交互风格一致性。

2)网关层

入口网关为nginx反向代理,主要功能是对不同域名的SSL解析和路径映射,部分前端静态资源的直接映射。入口网关下为业务网关,包括COP网关和通用业务域网关。

通用业务域网关:主要功能是将前端有状态的HTTP请求(header:jwt信息加密和域名信息过滤),进行鉴权,过滤,路由。同时解析为明文上下文Map,存于header中,可供业务层服务使用。其中针对不同域名的路由信息是采用了nacos的配置中心进行统一管理,并下发至gateway,实现一个动态的域名路由管理。

COP网关:负责系统对外开放平台的API接口鉴权和路由代理。

3)业务服务层

该层又有细分,分为COP服务,业务平台服务,数据平台服务。

a. COP:主要封装对外开发接口统一认证服务。通过COP,SAAS系统可以实现与第三方供应链接口平台和伙伴客户ERP系统、政采平台、OMS系统等对接。

b. 业务平台:分为核心的领域服务层和聚合/适配器服务层。

领域服务层:基于DDD领域驱动设计思想,对现有业务进行抽象,按照不同子域划分不同的服务。每个领域服务内有针对该子域的聚合根抽象封装。聚合服务:针对不同业务场景,对领域服务调用进行一层聚合,使其更好地为前端提供接口服务。

应用聚合层:针对业务场景进行封装和聚合。

适配器服务层:针对不具有领域概念的但又有一定意义的服务进行封装,如基于CQRS设计理念的查询服务;以及后台异步任务服务,如数据导入导出、数据同步等。

以上这几层可以看成是对六边形架构的一个很好的分解和落地。

c. 数据平台层:针对SAAS系统的产生核心数据,例如订单,商品,基于CQRS理念,将数据进行整合和同步,实现多场景下单数据复杂查询和BI数据分析。

4)技术底座层

该层细分的话,可以分为TPAAS服务和BPAAS服务两部分。

TPAAS服务:包括k8s、容器化编排、Istio流量管理、日志采集和查看、链路追踪监控、中间件(数据存储、MQ)、CI/CD等。

BPAAS服务:包含基础jar包(如低代码框架、安全组件)和基础服务(如工作流服务、任务调度服务、分布式ID生成器服务等)。

3. 最终服务落地

图片

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

采灵通系统总计服务65个,按照服务分类分层的概念,结合DDD的六边形架构思想,可以分为:

前端服务,BFF服务,组合服务,适配器服务,领域服务,基础服务,网关服务。

其中这些服务有一些设计规约:

1. 领域服务不可依赖组合/聚合服务、适配器服务和BFF服务。

2. 组合/聚合服务和适配器服务不可依赖BFF服务

3. 领域服务进行天然分库处理。

五、总结

笔者通过采灵通业务场景的落地实践,最大的感触是在前期子域拆分时候的纠结,在此,给大家讲个例子:

比如商品模块,前期会考虑到底是拆成一个商品子域呢,还是拆成两个子域:伙伴商品子域和供应商商品子域。如果是一个商品子域,业务实现上会简单一些,但未来业务场景拓展会受限。如果拆成两个子域,前期系统设计会增加复杂度,包括商品池的同步问题,数据一致性问题,等等。但后期来说,会更适配业务场景,所以最终笔者的选择是跟产品经理充分沟通过业务需求后,选择了拆成两个子域。

所以,作为一个业务架构师,第一要务是要有充分理解业务的能力,所以如何跟产品经理紧密配合,其实是一个业务架构师的核心能力。其次才是技术维度的能力,包括对六边形架构的把控,对多种设计模式的应用,对系统高并发和高可用性的应对经验等。后面所说的这些能力,对于一个技术宅来说是很好提升的,但对于前面的这个能力,可能就因人而异了。

说在最后

DDD架构如何落地,是是非常常见的面试题。

以上的内容,如果大家能对答如流,如数家珍,基本上 面试官会被你 震惊到、吸引到。

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

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

当然,关于DDD,尼恩即将给大家发布一波视频  《第34章:DDD的学习圣经》, 帮助大家彻底穿透DDD。

图片

部分历史案例