持续交付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
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,509评论 6 504
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,806评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,875评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,441评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,488评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,365评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,190评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,062评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,500评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,706评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,834评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,559评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,167评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,779评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,912评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,958评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,779评论 2 354

推荐阅读更多精彩内容