写点什么

架构师训练营 - 微服务,DDD

用户头像
Pontus
关注
发布于: 2020 年 08 月 11 日

参考

参考



巨无霸应用系统带来的问题

1)编译、部署困难。

2)代码分支管理困难,merge冲突,发布的时候问题互相纠缠,顾此失彼,每次发布都要半夜三更。

3)数据库连接耗尽。

4)新增业务困难。都是雷区,老人忙得要死,新人一帮忙就容易添乱。



大系统拆分方式

纵向拆分:将一个大应用拆分成多个小应用,如果新增业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统。

横向拆分:将复用的业务拆分出来,独立部署成微服务,新增业务只需要调用这些微服务即可快速搭建一个应用系统。



Web Service分布式服务



缺点:

1)臃肿的注册与发现机制

2)低效的XML序列化

3)开销相对高的HTTP网络通信

4)复杂的部署和维护手段



Dubbo微服务框架架构



Service Mesh服务网格



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



Service Mesh的sidecar模式





微服务架构落地

  • 业务先行,先理顺业务边界和依赖关系(最重要),技术是手段而不是目的。

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

  • 业务耦合严重,逻辑复杂多变的系统进行微服务重构要谨慎。

  • 要搞清楚实施微服务的目的是什么?业务复用?开发边界清晰?分布式集群提升性能?



微服务最佳实践

  • CQRS:读命令与写命令隔离。

  • 事件溯源:将用户请求过程中每次状态变化都记录到事件日志中。

  • 断路器:三种状态是关闭、打开、半开。



  • 服务重试与调用超时:上游调用者超时时间要大于下游调用者超时时间之和。

  • 最重要的是需求:



远程过程调用(RPC)



Dubbo通信协议



Dubbo利用requestId避免对头阻塞,实现全双工通信。



按作用划分架构师

  • 设计型架构师:也就是一般意义上的架构师,负责系统架构设计,同时也要负责架构的实施落地。

  • 救火型架构师:充当救火队员的角色。

  • 布道型架构师:对某一领域有较为深刻的认识,乐于分享,希望能够推广自己的技术主张,会成为忽悠大师。

  • Geek型架构师:精益求精,追求完美,通常技能不够全面。此类架构师通常怀才不遇。



网关作用

  • 统一接入:高性能、高并发、高可用、负载均衡

  • 安全防护:防刷控制、黑白名单、统一鉴权认证

  • 流量管控和容错:限流、降级、熔断

  • 协议适配:http、dubbo等



Flower异步网关与异步微服务框架



开放授权协议OAuth2.0





OAuth2.0授权码登录



为什么需要DDD?

很多项目的实际情况:

  • 产品经理需求零零散散,不断变更。

  • 工程师在各处代码中寻找可以支持需求变更的代码,反复修修补补,对每块代码的职责缺乏思考。

  • 软件只有需求分析,缺乏真正的设计,系统没有一个统一的领域模型维持其内在逻辑一致性。(产品堆功能,但是对于这个功能是否真的是这个领域所必要的,缺乏思考)

  • 功能特性并不是按照领域模型内在的逻辑设计,而是按照人自己的主观想象拍脑袋设计。



项目时间一长,各种困难重重,需求延期,线上bug不断,管理者考虑要不要推倒重来,程序员考虑要不要跑路。



贫血模型VS充血模型

贫血模型:类似Controller、Service、Dao这种这种只有方法,没有成员变量,而方法调用时传递的数值对象,比如Contract,没有方法(或者只有构造方法、getter、setter),典型的面向过程。

充血模型:合并了行为和数据的领域对象模型。通过领域模型对象的交互完成了业务逻辑。也就是说,设计好了领域模型对象,也就设计好了业务逻辑实现。



什么是领域?

领域是一个组织所做的事情以及其包含的一切,通俗地说,就是组织的业务范围和做事方式,也是软件开发的目标范围。领域驱动设计就是从领域出发,分析领域内模型及其关系,进而设计软件系统的方法。



什么是子域?

领域是一个组织所做的事情及其包含的一切。这个范围就太大了,不知道该如何下手。所以通常的做法是把一个领域拆分成多个子域。比如:用户、商品、订单、库存、物流、发票等。(一个微服务很可能就是一个子域)如何划分子域是一个关键。(卖家提现功能属于用户子域,还是财务子域?)



限界上下文

在一个子域中,会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有一对一的关系,用来控制子域的边界,保证子域内的概念统一性。通常限界上下文对应一个组件或者一个模块,或者一个微服务,一个子系统。



上下文映射图

不同的限界上下文,也就是不同的子系统或者模块之间会有各种交互动作。DDD使用上下文映射图来设计这种关联和交互。



DDD分层架构

领域实体的组合调用和事务控制在应用层。



DDD的战略设计和战术设计

领域、子域、限界上下文、上下文映射图,这些是DDD的战略设计。

实体(领域模型对象,每个实体是唯一的,有唯一标识。比如一个订单对象是一个实体。实体会发生变化,但是实体的唯一标识不会变化)、值对象(并不是领域内的对象都应该被设计为实体,比如住址的对象就是值对象,值对象不会变化,也没有行为)、聚合(是一个关联对象的集合,我们将其作为一个单元来处理数据更改。聚合根:将多个实体和值对象聚合在一起的实体)、CQRS、事件溯源,这些是DDD战术设计。

通过战略设计,划分模块和服务的边界及依赖关系,对微服务架构的设计至关重要。



作业

作业一:

  • 根据微服务框架 Dubbo 的架构图,画出 Dubbo 进行一次微服务调用的时序图。





作业二:

关于微服务架构(中台架构、领域驱动设计、组件设计原则),你有什么样的思考和认识?



相关的知识在上面的总结中均有阐述。

自己的思考,目前我的工作还是集中在单机系统,没有进行过微服务的改造,导致对其实践经验不足;但是也有考量,要根据项目实际、团队技术水平、公司运维能力等来选择是否要搞微服务,而不是强行安排。

加油!



用户头像

Pontus

关注

还未添加个人签名 2018.04.21 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营 - 微服务,DDD