[微服务设计]3_如何构建服务

一个好的服务的判定标准有很多------功能性、性能、可用性、可维护性、健壮性、协作性。在这一章节中,作者希望读者能专注在两个重要的概念上:松耦合和高内聚。

探讨基于低耦合高内聚原则的服务划分。

松耦合

一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。

微服能独立修改以及部署而不需要修改其他服务。

高内聚

把相关的行为聚集在一起,不相关的行为放在别处。这样要改变某个行为时,只需要在一个地方进行修改。

限界上下文

"限界上下文"是领域驱动设计DDD种的一个核心概念,用于解决复杂业务系统中不同业务模块的边界划分和写作的问题,其核心思想是:将一个庞大系统拆分为多个明确边界的小业务领域,每个领域内部使用统一的语言和模型,并通过清晰的接口与其他领域交互。

这个"明确边界的小业务领域",就可以是"xxx上下文"。借助"限界上下文"对业务边界进行描述会比较准确,例如:

电商系统,可以简单分出来------

订单上下文:关注订单创建、支付状态、物流跟踪。(改变订单的行为只需要在订单上下文中进行,且不需要关注其他上下文,在必要的时候进行上下文通信即可)

库存上下文:管理商品库存的增减、预留和同步。

会员上下文:处理用户积分、等级和优惠券。

交互方式:订单创建时通过事件(如 OrderPlacedEvent)通知库存系统扣减库存。

"限界上下文"就是这样一个划分业务的逻辑边界的概念工具。

开篇有讲到,微服务是"协同工作的小而自洽的服务",如何"小的刚刚好",即"如何拆分为明确边界的小业务领域",最佳实践就是一个微服务对应一个"限界上下文"------微服务和限界上下文保持一致。

但是注意不要过度拆分,将单一业务拆分为多个上下文,我们核心原则还是低耦合高内聚。

服务拆分的边界可以理解为一个领域框,框内应该是相关性强的业务。

专家级程序员强调的行业经验应当就有领域划分边界的经验。

逐步划分上下文

继续学怎么划分上下文。

在引入"限界上下文"辅助划分高度相关的业务内容为微服务后,需要理解的是------上下文的颗粒度应该根据组织结构看来决定,组织结构和软件架构会互相影响。

例如仓库系统可以拆分为:订单处理、货物接收、库存管理

财务系统与仓库系统进行通信获取库存等级,是直接与仓库系统进行通信,还是与具体的库存管理通信,还是与仓库提供通信,这可能取决于开发系统的组织架构。

关于业务概念的沟通

设计微服务时,需要考虑微服务如何就一个业务概念进行通信。

通信方式同步还是异步,性能要求如何,系统复杂度怎么控制?这些都与业务概念相关,沟通的原则是尽量可靠、安全、可拓展。

相关推荐
Ashlee_code11 分钟前
什么是Web3?金融解决方案
开发语言·金融·架构·eclipse·web3·区块链·php
c30%001 小时前
内网渗透——红日靶场五
运维·服务器
宇钶宇夕2 小时前
EPLAN 电气制图:建立自己的部件库,添加部件-加SQL Server安装教程(三)上
运维·服务器·数据库·程序人生·自动化
susu10830189112 小时前
Debian 11 Bullseye 在线安装docker
运维·docker·debian
WebInfra3 小时前
如何在程序中嵌入有大量字符串的 HashMap
算法·设计模式·架构
love530love3 小时前
Docker 稳定运行与存储优化全攻略(含可视化指南)
运维·人工智能·windows·docker·容器
岁岁岁平安3 小时前
CentOS-7-x86_64解决:使用NAT模式无法ping通www.baidu.com或无法ping 8.8.8.8问题。
linux·运维·centos·centos-7
运维小贺3 小时前
各服务器厂商调整BIOS睿频教程
linux·运维·服务器·性能优化
网硕互联的小客服3 小时前
如何排查服务器中已经存在的后门程序?
运维·服务器·github
人生匆匆3 小时前
docker进入启动失败的容器
运维·docker·容器