微服务

微服务框架需求

• 服务注册与发现

• 服务调用

• 失效转移

• 负载均衡

• 高效的远程通信

• 对应用侵入少

• 版本管理

Service Mesh 服务网格

Service Mesh是一个基础设施层,用于处理服务间的通信,通常表现为一组轻量级网络代理,他们与应用程序部署在一起,而对应用程序透明。

微服务网关

承接应用程序请求，把请求发送到不同的微服务进行处理

• 统一接入

• 安全防护

• 协议适配

• 流量管控与容错

网关管道技术

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



领域驱动设计

领域模型

按照面向对象的方式而非过程式的编程

充血模型 VS 贫血模型

领域模型的对象则包含了对象的数据和计算逻辑,比如合同对象,既包含合同数据,也包含合同相关的计算。因此从面向对象的角度看,领域模型才是真正的面向对象。

领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻辑的实现,也就是说,设计好了领域模型对象,也就设计好了业务逻辑实现。和事务脚本被称作贫血模型相对应的,领域模型也被称为充血模型。

DDD战略设计

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

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

子域

领域是一个组织所做的事情以及其包含的一切。这个范围就太大了,不知道该如何下手。所以通常的做法是把整个领域拆分成多个子域。

限界上下文

在一个子域中,会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有对一的关系,用来控制子域的边界。

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

实体

领域模型对象也被称为实体,每个实体都是唯一的,具有一个唯一标识

值对象

并不是领域内的对象都应该被设计为实体，DDD推荐尽可能将对象设计为值对象。

聚合

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

DDD分层架构

用户接口层应用层领域层

DDD六边形模型

领域模型通过应用程序封装成一个相对比较独立的模块,而不同的外部系统则通过不同的适配器和领域模型交互,比如可以通过HTTP接囗访问领域模型,也可以通过 Web Service或者消息队列访问领域模型,只需要为这些不同的访问接口提供不同的适配器就可以了。



DDD战略设计与战术设计

领域、子域、界限上下文、上下文映射图,这些是DD的战略设计。实体、值对象、聚合、 CQRS、事件溯源,这些是DDD战术设计。通过战略设计,划分模块和服务的边界及依赖关系,对微服务架构的设计至关重要。