1.1 什么是微服务
微服务就是一些协同工作的小而自治的服务。
关键词: 小而自治
-- 小
“小”这个概念,一方面体现在微服务的内聚性上。
-- 自治
“自治”这个概念,强调的是,一个微服务就是一个独立的实体。体现在服务之间的松耦合上。黄金法则:你是否能够修改一个服务并对其进行部署,而不影响其他任何服务?
1.2 微服务的好处
1. 3微服务的弊端
对运维能力要求高;运行效率会降低;技术要求高,需要处理事务最终一致性等问题。微服务不该是这样的:
2.1松耦合
松耦合指的是,修改一个服务,而另一个相关的服务,不需要修改。微服务的重要特点就是:能够独立修改和部署单个服务,而不会影响、甚至修改系统中的其它服务。
一个服务应该尽可能少地了解与之协作的服务信息。因为过度了解,会导致紧耦合。
2.2高内聚
高内聚指的是,把相关的行为聚集在一起。这样,需要改变行为时,只需要在一处修改,然后独立发布。
我们需要做的是,找出业务领域的边界,然后实现高内聚
还是要重申两个重要概念,高内聚和松耦合,对应前面的关键词:小而自治。
3.1限界上下文
微服务一定要有清晰的功能边界。一个微服务对应了一个功能集合,这些功能一定是有一些共性的。比如,订单服务,那么创建订单、修改订单、查询订单列表,一般是订单服务的功能集合。
3.2逐步划分
一开始,我们会首先识别出一个粒度比较粗的服务模型。领域拆分并不是一步到位的,应当根据实际情况逐步展开。从单体应用到微服务体系的拆分过程能很好的说明这个问题。所以如果一开始不知道应该划分多细,完全可以先粗粒度划分,然后随着需要,初步拆分。比如一个电商一开始索性可以拆分为商品服务和交易服务,一个负责展示商品,一个负责购买支付。随后随着交易服务越来越复杂,就可以逐步的拆分成订单服务和支付服务。
DDD 是一种架构设计方法,微服务是一种架构风格,DDD可以看作是微服务的方法论。两者从本质上都是为了追求高响应力,而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发,其核心要义是强调根据业务发展,合理划分领域边界,持续调整现有架构,优化现有代码,以保持架构和代码的生命力,也就是我们常说的演进式架构。
4.1 领域和子域
领域可以是多个子领域的一个虚拟集合,换句话说多个微服务也可以形成一个大域,不必纠结于领域和微服务之间的数量对应关系。例如在做架构设计的时候可能就把订单域作为一个领域,代表了这个域就是关于订单的,具体该有几个微服务,这需要更细的详细设计来提供。子域可以根据自身重要性和功能属性划分为三类子域,它们分别是:核心域、通用域和支撑域
4.2 界限上下文
任何领域模型都必须是在其特定的上下文环境中,如果DDD超出了其界定的上下文,则会产生歧义或者错误。例如社交媒体中的连接和网络应用中的连接的含义是完全不同的。对于任何上下文,我们都必须要能够建立明确的上下文的关联关系和边界。模型中的角色和边界的定义,在项目中非常重要。
4.3 库
库(Repositories)库指的是所有拥有共同实体和值接口的服务,且这些实体和值都在同一个聚合组中。库通常应该有增加,删除,修改和查找组中对象的方法。可以直接通过应用业务逻辑查询的引用来进行简洁的查询。
4.4 通用语言
通用语言就是能够简单、清晰、准确描述业务涵义和规则的语言。通用语言是团队统一的语言,不管你在团队中承担什么角色,在同一个领域的软件生命周期里都使用统一的语言进行交流。那么,通用语言的价值也就很明了,它可以解决交流障碍这个问题
4.5 聚合和聚合根
聚合(Aggregate):用来定义领域对象所有权和边界的领域模式,是用来帮助简化模型对象间的关系。通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚,并避免了错综复杂的难以维护的对象关系网的形成。
聚合根(Aggregate Root):每个聚合都有一个根对象(聚合根实体),从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用,但是外部对象只能引用根对象实体。只有聚合根才能使用仓储库直接查询,如果根实体被删除,聚合内部的其它对象也将被删除。
4.6 实体和值对象
实体(Entity):一个由它的标识定义的对象叫做实体。通常实体具备唯一ID,能够被持久化,具有业务逻辑,对应现实世界业务对象。
值对象(Value Object):一个没有概念上标识符描述一个领域方面的对象,这些对象是用来表示临时的事物,或者可以认为值对象是实体的属性,这些属性没有特性标识但同时表达了领域中某类含义的概念。通常值对象不具有唯一ID,由对象的属性描述,可以用来传递参数或对实体进行补充描述。
4.7 领域事件
领域事件是对领域内发生的活动进行的建模。一个消息监听可以当成一个领域事件,表示发生了什么事情,然后需要做什么。领域事件对象用于记录模型产生的离散事件,我们必须谨慎选择和记录领域事件,仅仅对于那些有意义的事件进行记录。
4.8 领域和数据库
一般按垂直业务拆分,一个服务对应独立的库(也可能出现多个服务公用一个库,从设计上通常没有公用表),绝大多数情况下,一个服务和一个数据库搭配,对外提供接口。数据库应该被视为每个领域服务层微服务的私有数据库。
4.9 领域内拆分
领域拆分并不是一成不变的,应当具体情况具体分析。比如大众点评,其订单服务就拆分为了order-service和order-query-service,一来为了读写分离,二来order-query-service作为单独应用可以按需水平扩容。
4.10 核心子域、支撑子域、通用子域
-- 核心子域:
决定业务成功和公司核心竞争力的子域,整个系统最重要部分。 Eric Evans 曾提出如下问题助识别核心域:
若你对这几个问题的回答能帮你找到这个系统非写不可的理由,则它就是核心域。如电商系统的订单、商品服务。
-- 支撑子域(Supporting Subdomain)
不是你的核心竞争力,但又得做,市场无现成方案的子域。既不包含决定产品和公司核心竞争力的功能,也不包含通用功能的子域,但又必需。
具有企业特性,但不具通用性,如:
-- 通用域(Generic Subdomain)
无太多个性化需求,同时会被多个子域使用的通用功能子域。如认证、权限等,无企业特点限制,无需太多定制化。行业里都这么做,即便不自己做,也不影响业务运行。
如很多 App 要给用户发通知,这种功能完全可买个服务,丝毫不影响业务运行。
脚本式编程(dao+service)与DDD领域驱动模式区别如下:
5.1展现(表现层/用户接口层)(Presentation Layer):
负责以Restful的格式接受Web请求,然后将请求路由给Application层执行,并返回视图模型(View Model),其载体通常是DTO(Data Transfer Object);
5.2应用层(Application Layer):
主要负责获取输入,组装上下文,做输入校验,调用领域层做业务处理,如果需要的话,发送消息通知。当然,层次是开放的,若有需要,应用层也可以直接访问基础实施层;应用层连接用户接口层和领域层,不应该实现领域模型的核心领域逻辑。主要职能:协调领域层多个聚合完成服务的组合和编排。应用服务主要负责服务组合、编排和转发,处理业务用例的执行顺序以及结果的拼装。在应用服务中还可以进行安全认证、权限校验、事务控制、领域事件发布或订阅等。
5.3领域层(Domain Layer):
领域层是领域模型的核心,主要实现领域模型的核心业务逻辑。领域模型的业务逻辑主要由实体和领域服务来实现。其中实体会采用充血模型来实现业务功能,如单一实体(或值对象)不能实现时,就交由领域服务进行组合和协调聚合内多个实体(或值对象),实现复杂的业务逻辑。
主要是封装了核心业务逻辑,并通过领域服务(Domain Service)和领域对象(Entities)的函数对外部提供业务逻辑的计算和处理;
5.4基础实施层(Infrastructure Layer):
主要包含Tunnel(数据通道)、防腐层,Config和Common。这里我们使用Tunnel这个概念来对所有的数据来源进行抽象,这些数据来源可以是数据库(MySQL,NoSql)、搜索引擎、文件系统、也可以是SOA服务等;Config负责应用的配置;Common是通用的工具类。
基础层贯穿DDD所有层。其职能:提供通用的技术和基础服务,包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。
DDD 包括战略设计和战术设计两部分,它们分别从不同的视角出发,完成领域建模和微服务的拆分和设计。事件风暴(Event Storming)是落实领域驱动的一种常用方法,使用事件风暴能够通过领域事件来识别出聚合根,组合的聚合根则又组成限界上下文,限界上下文则正是我们寻找的“微服务”的概念。
6.1战略设计
是从业务视角出发,划分业务的领域边界,建立基于通用语言和业务上下文语义边界的限界上下文,构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界。以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交流的工具,在不断交流的过程中发现和挖出一些主要的领域概念,然后将这些概念设计成一个领域模型;
6.2战术设计
则是从技术视角出发,侧重于对领域模型的技术实现,按照领域模型完成微服务的开发和落地。在战术设计中会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象,这些领域对象会以代码的形式映射到微服务中完成设计和系统落地。 由领域模型驱动软件设计,用代码来表现该领域模型。领域需求的最初细节,在功能层面通过领域专家的讨论得出。
UML建模示例:
- @startuml
-
- hide circle
-
- note "知识库领域建模" as knowledge_uml #yellow
-
- entity 知识库 {
- kie_knowledge
- ==
- 知识来源:工单、设备
- 类型: 知识、案例
- 知识状态: 待提交、已发布、已撤销
- 查看次数:调用详情次数
- }
-
- entity 知识操作日志 {
- kie_knowledge_operation_log
- ==
- 操作名称
- 知识ID
- 操作人ID
- 操作人名字
- 是否成功(success)
- 操作类型: 存入草稿,撤销,发布
- }
-
- entity 知识关联对象 {
- kie_knowledge_linked_object
- ==
- 知识ID
- 对象上下文快照: jsonb
- }
-
- entity 知识点赞记录 {
- kie_knowledge_like_record
- ==
- 用户ID
- 知识ID
- 点赞标识:bool
- }
-
- 知识库 ||--|{ 知识操作日志
- 知识库 ||--o{ 知识关联对象
- 知识库 ||--o{ 知识点赞记录
-
- @enduml