持续交付2.0 第五章 持续交付的软件系统架构 读书笔记
5.1 大系统小做原则
5.1.1 持续交付架构要求
- 为测试而设计，强调研发的服务或功能需要易于测试。
- 为部署而设计，强调研发的服务或功能需要易于部署。
- 为监控而设计，系统设计要易于监控，且易于收集数据。
- 为扩展而设计，需要支持团队规模的扩展，同时支持系统自身的扩展。
- 为失效而设计，考虑一旦部署失败，如何优雅的快速进行处理。
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 数据库的拆分方法
步骤
- 详细了解数据库结构，包括外键玉树，共享的可变数据以及事务性边界等如图5-10（a）
- 先拆分数据库，并按照12.3.2节的介绍进行数据迁移，如图5-10（b）
- 数据库双写无误后，找到程序架构中的缝隙，如图5-10c
-
将拆分出来的程序模块和数据库组合在一起，形成微服务。如图5-10d
image.png
