微服务架构设计模式-(5)软件架构

软件架构

  • 构建系统所需要的一组结构,包括软件元素和软件元素之间的关系

观察一个软件架构,可以从多个角度来看。通常我们一次都是看的一个场景。

  • 逻辑
    • 元素:类、包
    • 关系:继承、关联、依赖
  • 实现
    • 元素:模块、组件
    • 关系:依赖关系
  • 进程
    • 元素:进程
    • 关系:进程间通信
  • 部署
    • 元素:机器、进程
    • 关系:网络

架构风格

  • 组件和连接器的词汇表
    • 就是以什么语言来表述元素和元素关系
  • 分类
    • 分层架构
      • 元素以层的方式来组织
      • 每层有自己的职责,层与层之间限制依赖关系
      • 举例
        • 表现层
          • 用户界面、外部API
        • 业务逻辑层
        • 数据持久化层
      • 问题
        • 实际上一个系统可能有多个表现层、数据层,在这里不能很好的表现出来
        • 业务逻辑依赖数据层
          • 有的不需要数据层
    • 六边形架构
      • 以业务逻辑为中心组织的逻辑视图
        • 单体架构可以具有六边形架构风格的逻辑视图
      • 结构说明
        • 外层为入站、出站适配器
          • 入站为公开的API
          • 出站为调用调用外部的服务
            • 数据库也是一种出站适配器
        • 内层为业务逻辑
      • 特点
        • 业务逻辑不依赖适配器
          • 就是服务本身为重点,由服务本身来决定提供什么服务功能,提供服务的形式就是适配器
        • 适配器依赖业务逻辑
      • 优点
        • 适配器中包含了表示层和数据层的逻辑,这里与业务逻辑分离开来。业务逻辑不依赖表示层和数据层
    • 微服务
      • 一种架构风格
      • 描述
        • 实现视图由多个组件构成,组件是服务,连接器是通信协议
        • 每个服务都有自己的逻辑视图架构,通常也是六边形架构
      • 服务
        • 单一的、可独立部署的软件组织
      • 核心特性
        • 服务之间的松耦合
          • 保证数据的私有属性是实现松耦合的前提之一
            • 数据解耦好处
              • 一个服务的数据加锁不会影响另一个服务
            • 数据解耦带来的问题
              • 数据一致性、跨服务查询变得复杂
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值