【读书笔记-010】持续交付2.0之软件系统架构
2019-03-05 本文已影响101人
爱倩子的李总
背景
传统的巨石架构在每次部署时必须将整个系统都作为一个整体进行部署，即使只是其中的某个小模块的小规模代码变更，这种架构的系统的稳定性存在挑战，出现生产问题的概率大大增加。为了降低系统的耦合度和复杂性，应该将巨石架构全面改造成面向服务架构，并满足以下要求：
- 所有团队都要以服务接口的方式提供各种功能；
- 团队间必须通过接口方式通信；
- 不允许任何其他形式的互操作：不允许直接读取其他团队的数据库，只能通过网络进行通信；
- 具体实现的技术不限制；
- 所有的服务接口必须从一开始就以公开为设计导向。
”大系统小做“的原则
持续交付架构要求
- 为测试而设计：减少开发完成之后的质量验证周期，需将质量内建，持续保证软件质量；
- 为部署而设计：构建生成的可运行二进制包，必须要能够快速部署到生产环境，提供给用户并接收到真实的反馈，才能达到持续交付的目标；
- 为监控而设计：持续交付2.0的验证环强调快速验证，验证的元数据来源于监测，通过监测软件的运行情况和业务功能的数据反馈，是双环模型持续流动的关键点；
- 为扩展而设计：包括团队成员的扩展和软件系统的扩展；
- 为失效而设计：部署发布的过程必然伴随着失败，如何快速的环境恢复，是在设计之初便要考虑的问题。
系统拆分原则
- 每个组件拥有清晰的业务职责，可以被独立的修改和替换；
- 高内聚，低耦合，使系统易于维护，每个组件和服务只知道尽可能少的信息；
- 整个系统易于构建与测试，如果构建和测试的困难，将很难缩短开发周期，无
法达到持续交付的目标； - 使团队成员之间的沟通协作更加顺畅；
- 系统拆分的同时，需要同时建立相应的构建、测试、部署和监控机制。
常见的架构模式
微核架构
又称插件架构，常用于需要向用户分发的客户端软件。软件的核心框架（包括系统启动的基础模块、通信模块、界面整体架构等）相对较小，其主要业务和业务逻辑都通过插件实现，插件之间的通信只通过核心框架进行。
优点
- 良好的功能延伸性：开发插件即可
- 易发布：插件可独立加载和卸载
- 易测试：功能间是相互隔离的
- 可定制性高
- 可渐进式开发：逐步增加功能
缺点
- 扩展性差：内核是一个独立单元，不容易做成分布式
- 开发难度相对较高：设计插件与内核的通信，以及内部插件的登记机制等
- 高度依赖框架：框架接口升级时，可能会影响所有插件，导致大量改造工作
微服务架构
提倡将单一应用程序划分为一组小服务，服务之间相互协调和配合，每个小服务运行在独立的进程中，服务间通过轻量级的通信机制交互；每个服务围绕业务进行构建，且能够独立部署到生产环境。
优点
- 扩展性好：服务间低耦合，可对单个服务独立扩容
- 易部署：每个服务可独立部署
- 易开发：每个服务可独立开发、部署和升级
- 易于单独测试：只测试修改了的单一服务
缺点
- 强调互相独立和低耦合，服务可能会被拆分的很细，导致系统依赖于大量的微服务，变得凌乱和笨重，网络通信消耗也比较大；
- 一次外部请求涉及多个服务间的通信，问题的调试和定位比较困难；
- 给原子操作带来困难
- 跨服务的组合业务场景的测试比较困难，需要同时启动多个微服务
- 公共类库的升级管理比较难，往往需要修改多个微服务
正是因为微服务架构的这些缺点，才必须要保证每个服务能够独立部署，以及在部署升级时不影响其下游服务，同时建立全面的微服务检测体系。
巨石应用
又称巨石框架，由单一结构体组成的软件应用，它是一个自我完整的系统，从头到尾完成某项功能所需的全部步骤，而不是一个环节，通常拥有一个完整的软件包。
优势
- 利于开发和调试，系统架构简单，调试方便
- 部署操作本身比较简单，只需要部署一个软件包
- 易于扩展：直接负载均衡多个副本即可
缺点
- 对开发人员要求高，容易产生混乱的代码，从而污染整个应用
- 难与新技术共同使用
- 只能整体扩展
- 持续部署非常困难，更新一个组件需要重新部署整个应用程序
架构的改造模式
拆迁者模式
根据当前业务需求，对软件架构重新设计，并组织团队重新开发一个全新的版本，一次性完全替代原有的遗留系统。好处在于与旧版本没有任何瓜葛，没有历史包袱，可以按预期进行架构设计。
拆迁者模式
缺点在于：
- 业务需求遗漏：可能存在不为所熟知的功能
- 市场环境变化：无法一蹴而就，市场需求变化时无法把握机会
- 人力资源消耗大：必须分出人力，同时维护新旧两边的需求
- 闭门造车：上线后可能无法满足用户需求
绞杀者模式
保持原有的遗留系统不变，当需要重新开发新功能时，重新开发一个服务，实现新的功能，通过不断构建新的服务，逐步使遗留系统废弃并最终替代之。
绞杀者模式
好处
- 不会遗漏原有需求
- 可以稳定提供价值，频繁交付版本
- 避免闭门造车
缺点
- 改造时间跨度较大
- 产生一定的迭代成本
修缮者模式
将遗留系统的部分功能与其余部分隔离，以新的架构进行单独改善，同时保证与其他部分仍能协同工作；与绞杀者模式不同点在于，其改造发生在系统内部。
修缮者模式
好处
- 系统外部无感知
- 不会遗漏原有需求
- 可以随时停下改造工作，响应高优先级的业务需求
- 避免闭门造车
缺点
- 改造时间跨度较大
- 产生一定的迭代成本
