当前位置:网站首页>架构设计杂谈

架构设计杂谈

2022-08-11 05:22:00 架构精进之路

hello,大家好,我是张张,「架构精进之路」公号作者。

什么是架构设计

架构设计是基于架构原则和目标给出问题解决方案的过程。架构和设计遵循相同的原则和方法,只是解决问题的规模和层次不同,而这规模和层次没有明显界限。

问题:

  1. 架构设计最基础的个人素质是什么?
  2. 架构设计最基础的技术能力是什么?

原则、目标与方法

原则:

动静分离,高内聚,低耦合

目标:

  1. 可控性:拆分,分而治之,拆分粒度取决于业务、人、制度多方因素
  2. 复用性:抽象,在阶段都要做好抽象复用,开发->设计->架构->领域->组织架构
  3. 系统标准:高性能(高并发)、可靠性(数据一致)、稳定性、可用性、安全性、易用性、可扩展、可维护

方法:4+1视图

  1. 用例视图:用户怎么看,UML用例图
  2. 逻辑视图:系统功能抽象,UML类图、交互图、时序图
  3. 开发视图:开发人员怎么看,开发文档和设计文档
  4. 进程视图:程序运行状态,线程、进程、系统交互,UML活动图
  5. 物理视图:部署视图,部署、网络、可靠性、可伸缩

问题:

  1. 在不同开发阶段实现架构设计的方法论有哪些?
  2. 影响拆分粒度的因素有哪些?
  3. 实现架构目标的技术有哪些,其原理是什么?
  4. 为什么数据驱动设计使用最广泛,数据库三范式体现了哪些架构原则?
  5. 为什么互联网公司不招初中级开发,而软件公司会大量招?

架构分类

进程角度分类:

  1. 单体架构:服务在一个进程内
  2. 分布式架构:服务在多个进程内

单体架构分类

  1. 简单模式:内部没有拆分
  2. MVC模式:内部分层
  3. 前后分离:前后端逻辑独立实现
  4. 组件模式:子项目打包为一个整体项目,手工打包->ant->maven
  5. 组件库模式:公共代码打包成组织库发布

web项目前后分离两大阶段:

  1. 后端渲染阶段:servlet->jsp->struts->springmvc->模板引擎->ajax
  2. 前端渲染阶段:ajax->jquery->Angular、react、vue、echart

单体架构问题:代码耦合不适合迭代更新、更新部署影响大、大型项目开发困难、项目启动慢可用性下降、扩展性不好

分布式架构分类

  1. SOA面向服务架构:关注企业IT生态建设、企业服务总线、异构服务整合;基于RPC、MQ技术
  2. DSA分布式服务架构:关注系统业务拆分,考虑系统架构和服务治理,服务使用同一分布式框架
  3. MSA微服务架构:精进的DSA架构,按架构原则目标实现系统,基于微服务治理技术
  • 微服务治理:服务注册与发现、服务监控、资源隔离、熔断、降级、限流
  • 微服务问题:服务雪崩、幂等、超时、事务一致

问题

  1. 我们有哪些系统是单体架构,而且必须是单体架构?
  2. SOA考虑的拆分粒度是什么?
  3. SOA实现服务整合和复用的方式方法是什么?
  4. 分布式服务架构有哪几种常用框架,优缺点是什么?
  5. 推进DSA向MSA发展的技术有哪些,分别解决了哪些问题?
  6. 单体架构、SOA、DSA、MSA优缺点是什么,用什么方法技术满足了架构原则和目标?

常用系统架构

分层架构

分层架构模式里的组件被分成几个平行的层次,每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种,大多数的结构都分成四个层次:展示层业务层持久层,和数据库层。如下图:


Clean架构

外圈的层次可以依赖内层,反之不可以;内圈核心的实体代表业务,不可以依赖其所处的技术环境。

六边形

六边形架构又称“端口和适配器模式”,是Alistair Cockburn提出的一种具有对称性特征的架构风格。在这种架构中,系统通过适配器的方式与外部交互,将应用服务于领域服务封装在系统内部。

六边型的适配器类似于反腐层的概念。

反腐层(Anti-corruption layer,简称 ACL)介于新应用和旧应用之间,用于确保新应用的设计不受老应用的限制。是一种在不同应用间转换的机制。

CQRS

命令查询的责任分离Command Query Responsibility Segregation Command和Query数据源分为同构和民构两种,读写分享是这种架构的一种简单实现。

从事务的角度来看 CQRS,需要面对的问题从根本来说是个最终一致性的问题。

问题:

  1. 同构数据源有哪几种,怎么实现的数据同步?
  2. 异构数据源有哪几种,怎么实现的数据同步?
  3. 数据一致性的保障方法有哪些?

事件驱动

异步、高度解耦


常用业务分析方法

  1. 数据库驱动:基于数据库表设计构建上层系统
  2. 用例驱动(Use Case)
  3. 用户故事(User Story)
  4. 测试驱动(TDD)

DDD(Domain-Driven Design)

  • 场景:MSA微服务架构在技术维度、业务维度、团队管理方面对架构方法论提出了新的挑战,需要综合性系统架构方法论支持MSA的落地实施。

  • 思想:开发团队应该从业务需求中提炼出统一语言,再基于统一语言建立领域模型;通过领域模型指导程序设计与编码;通过重构和设计模式改进开发质量。

DDD为两类方法论的实践集合:

  1. 领域模型分析:数据库驱动、用例驱动(Use Case)、测试驱动(TDD)、用户故事(User Story)
  2. 系统架构设计:分层架构、clean架构、六边型架构、事件驱动、CQRS模式

DDD的过程:Why->What->How

  1. 从问题域到解决方案域的过程
  2. 从需求分析到设计的过程
  3. 逐步识别限界上下文的过程

领域模型分析

问题域:核心领域、子领域、限界上下文、上下文映射

核心为限界上下文,基本与微服务可以对应上。

领域分析方法:6w2h

基本概念

实体(entity)

重点:具备唯一ID,是否是同一实体比较ID,能够被持久化,具有业务逻辑

值对象(value object)

重点:不具备唯一ID,是否是同一对象比较值是否相同

值对象的定义是:描述事物的对象;更准确的说,一个没有概念上标识符描述一个领域方面的对象。

聚合及聚合根(aggregate、aggregate root)

重点:大部分的聚合都只是一个实体,该实体同时也是聚合根,并不是所有的实体都是聚集根,但只有实体才能成为聚集根。

一个聚合是一组相关的被视为整体的对象。每个聚合都有一个根对象(聚合根实体),从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用,但是外部对象只能引用根对象实体。

基于聚合的以上概念,我们可以推论出从数据库查询时的单元也是以聚合为一个单元,也就是说我们不能直接查询聚合内部的某个非根的对象;

服务(services)

服务这个词在服务模式中是这么定义的:服务提供的操作是它提供给使用它的客户端,并突出领域对象的关系。

所有的service只负责协调并委派业务逻辑给领域对象进行处理,其本身并真正实现业务逻辑,绝大部分的业务逻辑都由领域对象承载和实现了。

当一个领域操作被视为一个重要的领域概念,一般就应该作为领域服务。服务应该是无状态的。

工厂(factories)

工厂用来封装创建一个复杂对象尤其是聚合时所需的知识,作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数,然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。当创建 实体和值对象复杂时建议使用工厂模式。

仓储(repositories)

仓储是用来管理实体的集合。

仓储里面存放的对象一定是聚合,原因是domain是以聚合的概念来划分边界的;聚合作为一个整体概念,要么一起被取出来,要么一起被删除。外部访问不会单独对某个聚合内的子对象进行单独操作。因此,我们只对聚合设计仓储。

respositories和dao:

dao是面向数据访问的,是关系型数据库和应用之间的契约。

repository:位于领域层,面向aggregation root。repository是一个独立的抽象,使用领域的通用语言,它与dao进行交互,并使用领域理解的语言提供对领域模型的数据访问服务的“业务接口”。

问题

  1. DDD在技术层面实现的最大困难在哪里?
  2. DDD在管理层面实现的最大困难在哪里?

DSL(Domain Specific Language)

如果我们能把设计做到极致,它就能成为一门语言,一门解决一个特定问题的语言。

  • 常规模式 JAVA:业务分析->架构设计->程序设计->编码设计->开发功能->形成产品
  • 原型模式 Python: 业务分析->原型->产品输出->业务分析,用原型不断迭代优化
  • DSL模式 Lisp:业务分析、DSL、原型开发、产品输出,同步开发迭代

01->Assembly->c->GPL (Generalized Programming Language)->DSL

01->Assembly->c->Lisp->DSL

常见DSL:

HTML、CSS、MAVEN、sql

我们通常所用的中间件框架实际上就是一种内部 DSL:

Spring、spring mvc、springboot、mybatis

Lisp 的本质:https://www.iteedu.com/blog/plang/lisp/lispdiary/lispbz/

Lisp之根源:https://www.iteedu.com/blog/plang/lisp/lispdiary/lispzgy/

组织架构&技术架构

开发人员组织架构分两种:

  1. 水平拆分的专业技术团队:前端、原生、后端、数据、测试、产品、PM
  2. 垂直拆分的跨职能团队:每个团队包含各类人员

管理方式:

  1. 水平拆分以专业的组长为主,强技术弱业务,沟通协调成本高
  2. 垂直拆分以产品或PM为主,强业务弱技术,技术风险大、工作量不平均

问题:

  1. 垂直拆分与水平拆分优缺点是什么,如何解决?
  2. 垂直拆分与水平拆分分别适用于哪种场景?
  3. 如何解决跨职能团队之间工作量不平均问题?



希望今天的讲解对大家有所帮助,谢谢!

Thanks for reading!


关注公众号,免费领学习资料


如果您觉得还不错,欢迎关注和转发~     

本文分享自微信公众号 - 架构精进之路(jiagou_jingjin)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

原网站

版权声明
本文为[架构精进之路]所创,转载请带上原文链接,感谢
https://my.oschina.net/jiagoujingjin/blog/5561513