持续交付2.0 第五章 持续交付的软件系统架构 读书笔记

5.1 大系统小做原则

5.1.1 持续交付架构要求

1. 为测试而设计，强调研发的服务或功能需要易于测试。
2. 为部署而设计，强调研发的服务或功能需要易于部署。
3. 为监控而设计，系统设计要易于监控，且易于收集数据。
4. 为扩展而设计，需要支持团队规模的扩展，同时支持系统自身的扩展。
5. 为失效而设计，考虑一旦部署失败，如何优雅的快速进行处理。

5.1.2 系统拆分原则

大系统应该由很多组件（component）或服务（service）组成。它们通常以jar/war/dll/gem等形式出现，其粒度比类（class）要大，但是要比整个系统小很多。组件通常在比编译构建或者部署时被集成在一起，而服务可以由多个组件构成，能独立启动运行，并在运行时与整个系统进行通信，成为整个系统的一个组成部分。

对系统进行拆分的原则

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

5.2 常见架构模式

5.2.1 微核架构

微核架构(microcore architecture)又称插件架构(plugin architecture),指软件的核心框架相对较小，而其主要业务功能和业务逻辑都通过插件实现，插件间的通信只通过核心框架进行。
优点

• 良好的功能延伸性（extensibility）：需要什么功能，开发一个插件即可。
• 易发布：插件可以独立地加载和卸载，是它比较容易发布。
• 易测试：功能之间是隔离的，可以对插件进行隔离测试。
• 可定制性高：适应不同的开发需要。
• 可以渐进式地开发：逐步增加功能。

劣势

• 扩展性差（scalability），内核通常是一个独立单元，不容易做成分布式，但对客户端软件来说，这不是个严重问题。
• 开发难度相对较高。

• 高度依赖框架，框架升级后导致大量改造工作。

  
  
  image.png

5.2.2 微服务架构

将单一应用分成一组小的服务，服务之间相互协调配合，为用户提供最终价值。每个服务在独立的进程中运行。服务之间通过restful api 交互。每个服务可以独立构构建部署。
优点

• 扩展性良好，各个服务之间低耦合。
• 易部署
• 易开发
• 易于独立单元测试

缺点

• 可能会被拆分的过细，导致大量微服务，变得凌乱而笨重，网络开销大。
• 一次外部请求会涉及多个内部服务，问题调试难于诊断。
• 为原子操作带来困难，例如事务类操作。

• 跨服务的组合业务场景测试比较困难，需要同时启动多个微服务。
  公共类库的升级管理比较困难。

  
  
  image.png

5.2.3 巨石应用（monolithic application）

也被称作巨石架构，指由单一结构体组成的软件应用，其用户接口和数据访问代码都绑定在同一语言平台的同意应用程序
优势

• 利于开发和调试。
• 部署才走本身比较简单
• 很容易扩展

劣势

• 对整体程序不熟悉的人来说，容易产生混乱的代码，污染整个应用，给老代码学习和理解带来苦难。
• 难与新技术共同使用
• 只能将整个应用作为一个整体进行扩展

• 持续部署非常困难。

  
  
  image.png

5.3 架构改造实施模式

5.3.1 拆迁者模式

指根据当前的业务需求，对软件架构重新设计，并组织单独的团队，重新开发一个全新的版本，一次性完全替换原有的遗留系统。
模式的好处
没有历史包袱。
风险

• 原业务需求遗漏
• 市场环境变化，由于新版本架构无法一蹴而就，当市场需求发生变化时，会错失良机。
• 人力资源消耗大

• 闭门造车

  
  
  image.png

5.3.2 绞杀者模式

指保持原来的遗留系统不变，当需要开发新的功能时，重新开发一个服务，实现新功能。通过不断构建新的服务，逐步使遗留系统失效，并最终替换。
优势

• 不会遗漏原有需求
• 可以稳定地提供价值，频繁地交付版本，可以让你根号地监控其改造进展
• 避免闭门造车

劣势

• 架构改造的时间跨度变大

• 产生一定的迭代成本

  
  
  image.png

5.3.3 修善者模式

指将遗留系统的部分功能与其余功能隔离，以新的架构进行单独改善。在改善的同时，需要保证与其他部分仍能协同工作。
优势

• 系统外部无感知
• 不会遗漏原有需求
• 可以随时停下改造工作，响应高优先级的业务需求。
• 避免闭门造车现象

劣势

• 架构改造的时间跨度变大

• 会有更多额外的架构改造迭代成本

  
  
  image.png
  
  
  image.png

5.3.4 数据库的拆分方法
步骤

1. 详细了解数据库结构，包括外键玉树，共享的可变数据以及事务性边界等如图5-10（a）
2. 先拆分数据库，并按照12.3.2节的介绍进行数据迁移，如图5-10（b）
3. 数据库双写无误后，找到程序架构中的缝隙，如图5-10c

4. 将拆分出来的程序模块和数据库组合在一起，形成微服务。如图5-10d

   
   
   image.png