写点什么

微服务与 DDD

用户头像
eazonshaw
关注
发布于: 2020 年 08 月 12 日

微服务架构

引入

阿里早期微服务架构重构:从巨无霸系统到微服务的改造

单体应用系统的问题:

  • 编译、部署困难:工程庞大,构建时间长

  • 代码分支管理困难:merge 代码耗时长

  • 数据库连接耗尽:数据库连接使用连接池,连接池数量有限

  • 新增业务困难

解决方案:拆分,将模块独立部署,降低系统耦合性

  • 纵向拆分:大应用拆分为小应用

  • 横向拆分:将复用的业务拆分出来,独立部署为微服务

历史

Web Service 与企业级分布式服务:

  • 角色:服务提供者(Provider)、服务请求者(Requester)、服务注册中心(Broker)

  • 关系:请求者向注册中心请求得到wsdl,然后根据SOAP协议向提供者请求数据

  • 缺点:臃肿的注册与发现机制、低效的XML序列化手段、开销相对较高的HTTP远程通信、复杂的部署与维护手段

微服务框架

基本要求

微服务框架需要满足条件:

  • 失效转移(Fail Over)

  • 负载均衡:通常不会使用负载均衡服务器,而是微服务自己解决,如 netflix 的 Ribbon

  • 高效的远程通信

  • 对应用最少侵入(RPC)

  • 版本管理(服务提供版本号)

Dubbo



Dubbo 如何满足微服务框架所需条件?

  • 失效转移

  • 负载均衡

  • 高效的远程通信:建立长连接,而不是每次请求都重新建立TCP连接

  • 对应用最少侵入:提供接口,直接调用

  • 版本管理:服务保持为期半年的有效期

Service Mesh 服务网格

  • 一个基础设施层,用于处理服务间的通信

  • 通常表现为一组轻量级网络代理,与应用程序部署在一起,对应用程序透明

  • Sidecar(边车)模式:用于服务器间互相调用的先行者

微服务实践

微服务架构的落地

  • 业务先行:先理顺业务边界和依赖,技术是手段而不是目的

  • 先有独立的模块,后有分布式的服务

  • 业务耦合严重、逻辑复杂多变的系统,重构需谨慎

  • 搞清楚实施微服务的目的:业务复用/开发边界需清晰/利用分布式集群提升性能

不要用战术上的勤奋来掩盖战略上的懒惰。

命令与查询职责隔离(CQRS)

在服务接口层面将查询(读操作)与命令(写操作)隔离,实现服务层的读写分离。

事件溯源

将用户请求处理过程中的每次状态变化都记录到事件日志中,并按时间序列进行持久化存储。

  • 精确复现任何用户状态,进行复核审计

  • 有效监控用户状态变化,并在此基础上实现分布式事务

断路器

当某个服务出现故障,响应延迟或者失败率增加,继续调用这个服务会导致调用者请求阻塞,资源消耗增加,进而出现服务级联失效,这种情况下使用断路器阻断对故障服务的调用。

服务重试及调用超时

上游调用者超时时间要大于下游调用者超时时间之和。

最重要的是需求

Needs > Values > Principles > Practices > Tools

微服务网关

基于网关的微服务架构

网关的作用

  • 统一接入

  • 流量管控和容错

  • 协议适配

  • 安全防护(核心)

微服务网关

角色:注册中心,网关(服务消费者),服务提供者

网关管道技术



定义:网关本身没有业务,主要职责是做各种校验与拦截,可以通过管道技术连接起来

核心:责任链模式/Handlers

开放平台网关

定义:开放给第三方使用的网关,如微博、微信、淘宝、高德等。

开放授权协议 OAuth2.0:授权码授权(最常用的方式)



领域驱动设计 DDD

引入

为什么需要 DDD ?

很多项目实际情况:

  • 用户或产品经理需求零散,变更多;

  • 工程师在各处代码修补;

  • 软件只有需求没有真正的设计,系统没有统一的领域模型维持内在的逻辑一致性;

  • 功能特性不是按照领域模型,而是人的主观想象。

时间一长,问题多,需要重构。

对比

事务脚本(传统的开发模式):Controller -> Service -> Dao。特点,核心的业务都堆在 Service 中,不利于迭代。

领域模型:contract -> product -> recognitionStrategy -> revenueRecongnition。特点:设计对象,拥有自己的属性、数据、方法、计算能力。

贫血模型 VS 充血模型

战略设计

领域:一个组织所做的事情以及其包含的一切,通俗地说,就是组织的业务范围和做事方式,也是软件开发的目标范围。

领域驱动设计:从领域出发,分析领域内模型及其关系,进而设计软件系统的方法。

领域范围太大,如何下手?

通常的做法是把整个领域拆分成多个子域。如电商场景下,拆分为用户、商品、订单、库存、物流、发票等。

限界上下文

  • 在一个领域中,会创建一个概念上的领域边界;在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义。这个边界称为限界上下文。

  • 限定上下文和子域具有一对一的关系,用来控制子域的边界。

  • 通常限定上下文对应一个组件,模块或者微服务。

上下文映射图:不同的限界上下文,也就是不同的子系统或者模块之间会有各种交互合作。



战术设计

实体

  • 即领域模型对象,每个实体都是唯一的,具有一个唯一标识,如订单对象是实体,订单ID是唯一标识。

  • 实体可能发生变化,但是唯一标识不会变化。

  • 实体设计是DDD的核心。

值对象

  • 仅用来做度量或描述的对象,称为值对象。

  • 特点:不变性。值对象创建后不能再改变。

聚合

  • 关联对象的集合,将其作为一个单元来处理数据更改。

  • 每个集合都有一个根和一个边界。边界定义了聚合内部的内容,根是聚合中包含的单个特定实体。

  • 聚合根:将多个实体和值对象聚合在一起的实体。

用户头像

eazonshaw

关注

还未添加个人签名 2019.04.10 加入

还未添加个人简介

评论

发布
暂无评论
微服务与DDD