您的位置:  首页 > 技术杂谈 > 正文

【实践篇】教你玩转微服务--基于DDD的微服务架构落地实践之路

2023-03-08 11:00 https://my.oschina.net/u/4090830/blog/8509861 京东云开发者 次阅读 条评论

作者:京东物流 赵勇萍

一. 前言

现在对于一个后端开发工程师来说,微服务,DDD都是挂在嘴边的东西,感觉大家接触到多,也了解的多。但笔者个人的感受是,对微服务架构的理解就像我小时候读三国,在不同年龄读的时候感触都不一样。微服务对于开发人员来说亦是如此,一千个人有一千种解读,而随着每个人自己的业务经验和架构能力的提升,每个人看到的风景也会不一样的。今天笔者想结合一下自己的业务实践,分享一下自己基于微服务架构实践后的心路历程。

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

 



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

a. 白马是马。

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

b. 服务治理

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

c. 十二要素

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



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

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

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

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

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

对于这个难点,现阶段已经有了很好的解决,因为服务治理和流量治理是去业务场景化的,所以有很多前人通过他们的努力,以及贡献的开源框架,让我们可以直接可以拿来落地的,并且可以做到很好的兼容。下图是一个比较标准的微服务治理架构图:



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

如何基于DDD方法论落地服务的分解。该处设计很多核心能力,包括子域划分,限界上下文定义,实体,聚合根的抽象,基于领域事件的事件驱动设计,除此之外,还有工厂模式,策略等等设计模式的应用。

这第二个难点是很难做到直接的迁移,因为我们面对的业务场景千差万别,前人的经验只能总结成思想来指导我们,但具体的落地就会考验每个架构师自己的过往经验和理解。 就像一为画家,对与同一片风景的理解不同,画出的画面也是不同的,所以,就会出现有的人是梵高,有的人是毕加索。而对于笔者现阶段来说,可能只是一个刚入门的素描者,不过我愿意在此抛砖引玉,介绍一下我采灵通项目对于微服务落地的经验,供大家做一个简单参考。

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

笔者负责的采灵通业务是一个相对复杂的系统,带领了20人的开发团队总共历时5个月,完成从0到1的设计,开发和上线。该系统基本涵盖了一个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. 领域服务进行天然分库处理。

五. 总结

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

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

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

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接