《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（三） 软件架构
持续交付架构的要求
为了提升交互速度，获得持续交付能力，我们会需要对系统架构做一些调整。书中对系统架构做了一些要求，要求如下：
- 为测试而设计（design for test）。如果我们每次写好代码以后，需要花费很大的精力，做很多的准备工作才能对它进行测试的话，那么从写好代码到完成质量验证就需要很
长周期，当然无法快速发布。 - 为部署而设计（design for deployment）如果我们开发完新功能，当部署发布时，需要花费很长时间准备，甚至需要停机才能部署，当然就无法快速发布。
- 为监控而设计（design for monitor）。如果我们的功能上线以后，无法对其进行监控，出了问题只能通过用户反馈才发现。那么，持续交付的收益就会大幅降低了。
- 为扩展而设计（design for scale）。这里的扩展性指两个方面，一是支持团队成员规模的扩展；二是支持系统自身的扩展。
- 为失效而设计（design for failure）俗语说“常在河边走，哪能不湿鞋。”快速地部署发布总会遇到问题。因此，在开发软件功能之前，就应该考虑的一个问题是:一旦部署或发布失败，如何优雅且快速地处理。
系统拆分原则
根据目前软件的发展趋势，以及持续交付的要求，对系统进行拆分有以下几个原则。
- 作为系统的一部分，每个组件或服务有清晰的业务职责，可以被独立修改，甚至被另一种实现方案所替代。
- “高内聚、低耦合”，使整个系统易于维护，每个组件或服务只知道尽可能少的信息，完成相对独立的单一功能。
- 整个系统易于构建与测试。将系统拆分后这些组件仍需要组合在一起，为用户提供服务。
- 使团队成员之间的沟通协作更加顺畅。
常见架构模式
微核架构
微核架构（microcore architecture）又称为插件架构（plugin architecture），指的是软件的核心框架相对较小，而其主要业务功能和业务逻辑都通过插件实现，如图所示。核心框架部分通常只包含系统启动运行的基础功能，例如基础通信模块、基本渲染功能和界面整体框架等。插件则是互相独立的，插件之间的通信只通过核心框架进行，避免出现互相依赖的问题。
巨石应用
巨石应用（monolithic application）也称巨石架构，是指由单一结构体组成的软件应用，其用户接口和数据访问代码都绑定在同一语言平台的同一应用程序。这种巨石架构应用通常表现为一个完整的包，如一个Jar包或者一个Node.js或 Rails的完整目录结构。只要有了这个包，就什么都有了。
组织良好的巨石架构同样也有其优势，包括以下几个。
- 利于开发和调试:当前所有开发工具和IDE都很好地支持了巨石应用程序的开发。系统架构简单，调试方便。
- 部署操作本身比较简单:例如，只需要有运行时所需部署的一个WAR文件（或目录层次结构）即可。
- 很容易扩展:只要在负载均衡器后面运行这个应用的多个副本就可以扩展应用程序。
它的劣势有以下几个。
- 对整体程序不熟悉的人来说，容易产生混乱的代码，污染整个应用，给老代码的学习和理解带来困难。
- 难与新技术共同使用。
- 只能将整个应用作为一个整体进行扩展。
- 持续部署非常困难。为了更新一个组件，必须重新部署整个应用程序。
架构改造实施模式
通常，这类改造有3种实施模式，分别是拆迁者模式、绞杀者模式和修缮者模式。其中，绞杀者模式和修缮者模式都有利于持续交付，降低架构改造和发布的风险。
拆迁者模式
“拆迁者模式”就是指根据当前的业务需求，对软件架构重新设计，并组织单独的团队，重新开发一个全新的版本，一次性完全替代原有的遗留系统，如图所示。
这种方式的好处在于:
- 不会遗漏原有需求；
- 可以稳定地提供价值，频繁地交付版本，可以让你更好地监控其改造进展；
- 避免“闭门造车”现象。
其劣势在于:
- 架构改造的时间跨度会变大；
- 产生一定的迭代成本。
修缮者模式
“修缮者模式”是指将遗留系统的部分功能与其余部分隔离，以新的架构进行单独改善。
- 详细了解数据库结构，包括外键约束、共享的可变数据以及事务性边界等，如图a所示。
- 先拆分数据库，并按照12.3.2节的介绍进行数据迁移，如图b所示。
- 数据库双写无误后，找到程序架构中的缝隙，如图c所示。
- 将拆分出来的程序模块和数据库组合在一起，形成微服务，如图d所示。
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8725 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！