尼恩说在前面
在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. 最终服务落地
- 五、总结
- 说在最后
- 尼恩技术圣经系列PDF
一、前言
作者:京东物流 赵勇萍
现在对于一个后端开发工程师来说,微服务,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。
尼恩技术圣经系列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,请到下面公号【技术自由圈】取↓↓↓