第五章 持续交付的软件系统架构

面向服务架构(SOA)

  1. 所有的团队都要以服务接口的方式,提供数据和各种功能
  2. 团队之间必须通过接口来通信
  3. 不允许任何其他形式的互操作,唯一许可的通信方式,就是通过网络调用服务
  4. 具体的实现技术不做规定
  5. 所有的服务接口,必须从一开始就以可以公开为设计导向,没有例外
  6. 如不遵守上述规定,就会被解雇

#“大系统小做”原则

持续交付架构要求

  1. 为测试而设计:易于测试新代码
  2. 为部署而设计:易于部署新功能
  3. 为监控而设计:易于监控新上线的功能
  4. 为扩展而设计:支持团队成员规模的扩展,支持系统自身的扩展
  5. 为失效而设计:一旦发布或部署失败,如何优雅且快速地处理

系统拆分原则

系统、服务、组件

  • 大系统应该由很多组件或服务组成,组件或服务的颗粒度比类大,但比整个系统小很多
  • 服务可由多个组件构成,能够独立启动运行,并在运行时与整个系统进行通信
  • 组件通常在编译构建或者部署时被集成在一起

系统拆分原则

  1. 作为系统的一部分,每个组件或服务有清晰的业务职责,可以被独立修改,甚至被另一种实现方案所替代
  2. “高内聚、低耦合”,每个组件或服务只知道尽可能少的信息,完成相对独立的单一功能,使整个系统易于维护
  3. 整个系统易于构建与测试。将系统拆分后,组件仍要能够易于组合在一起进行构建和测试
  4. 使团队之间的沟通协作更加顺畅

为了避免系统拆分带来的调用链路过长、查找问题难度高等问题,在系统拆分的同时,要同步建立相应的构建、测试与部署和监测机制
补充:这些机制都有哪些?

#常见架构模式

3种常见架构模式:微核架构、微服务架构、巨石应用

微核架构
常用于需要向客户端分发的客户端软件
第五章 持续交付的软件系统架构_第1张图片
微服务架构
用于企业自身可控的后台服务端软件
第五章 持续交付的软件系统架构_第2张图片
巨石应用
分层的巨石应用,常见于创业公司的产品项目
第五章 持续交付的软件系统架构_第3张图片

#架构改造实施模式

3种模式
拆迁者模式:对软件架构重新设计,开发一个全新的版本,一次性完全替代
绞杀者模式:保持原来的遗留系统不变,当需要开发新功能时,重新开发一个服务,实现新的功能,通过不断构建新的服务,逐步使遗留系统失效,并最终替代它
修缮者模式:将遗留系统的部分功能与其余部分隔离,以新的构架进行单独改善

数据库拆分方法:

  1. 详细了解数据库结构,包括外键约束、共享的可变数据以及事务性边界等
  2. 先拆分数据库
  3. 数据库双写无误后,找到程序架构中的缝隙
  4. 将拆分出来的程序模块和数据库组合在一起,形成微服务

你可能感兴趣的:(《持续交付2.0》读书笔记)