《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（三） 软件架构

《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（三） 软件架构

持续交付架构的要求

为了提升交互速度，获得持续交付能力，我们会需要对系统架构做一些调整。书中对系统架构做了一些要求，要求如下：

1. 为测试而设计（design for test）。如果我们每次写好代码以后，需要花费很大的精力，做很多的准备工作才能对它进行测试的话，那么从写好代码到完成质量验证就需要很
   长周期，当然无法快速发布。
2. 为部署而设计（design for deployment）如果我们开发完新功能，当部署发布时，需要花费很长时间准备，甚至需要停机才能部署，当然就无法快速发布。
3. 为监控而设计（design for monitor）。如果我们的功能上线以后，无法对其进行监控，出了问题只能通过用户反馈才发现。那么，持续交付的收益就会大幅降低了。
4. 为扩展而设计（design for scale）。这里的扩展性指两个方面，一是支持团队成员规模的扩展；二是支持系统自身的扩展。
5. 为失效而设计（design for failure）俗语说“常在河边走，哪能不湿鞋。”快速地部署发布总会遇到问题。因此，在开发软件功能之前，就应该考虑的一个问题是:一旦部署或发布失败，如何优雅且快速地处理。

系统拆分原则

根据目前软件的发展趋势，以及持续交付的要求，对系统进行拆分有以下几个原则。

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

常见架构模式

微核架构

微核架构（microcore architecture）又称为插件架构（plugin architecture），指的是软件的核心框架相对较小，而其主要业务功能和业务逻辑都通过插件实现，如图所示。核心框架部分通常只包含系统启动运行的基础功能，例如基础通信模块、基本渲染功能和界面整体框架等。插件则是互相独立的，插件之间的通信只通过核心框架进行，避免出现互相依赖的问题。

这种架构方式的优点有以下几个：

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

当然，它也有不足，具体有以下几点:

• 扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式，但对客户端软件来说，这就不是一个严重问题。
• 开发难度相对较高，因为涉及插件与内核的通信以及内部的插件登记机制等，比较复杂。
• 高度依赖框架，既享受框架带来的方便性，当框架接口升级时又可能会影响所有插件，导致大量的改造工作。

微服务架构

微服务架构（microservice architecture）是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
这种软件架构的优点有以下几个。

• 扩展性好——各个服务之间低耦合。可以对其中的个别服务单独扩容，如图所示的D服务。
• 易部署——每个服务都是可部署单元。
• 易开发每个组件都可以进行单独开发，单独部署，不间断地升级。
• 易于单独测试——如果修改只涉及单一服务，那么只测试该服务即可。

但是，它也有不足，具体有以下几点。

• 由于强调互相独立和低耦合，服务可能会被拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，网络通信消耗也会比较大。
• 一次外部请求会涉及内部多个服务之间的通信，使得问题的调试与诊断比较困难，需要更强大的工具支持。
• 为原子操作带来困难，例如需要事务类操作的场景。
• 跨服务的组合业务场景的测试比较困难，通常需要同时部署和启动多个微服务。公共类库的升级管理比较难。在使用有一些公共的工具性质的类库时，需要在构建每个微服务时都将其打包到部署包中。
  

在使用微服务架构模式时，除确保每个服务一定要能够独立部署之外，还要确保在部署升级时不影响其下游服务（例如通过支持API的多版本兼容方式），同时建立全面的微服务监测体系。

巨石应用

巨石应用（monolithic application）也称巨石架构，是指由单一结构体组成的软件应用，其用户接口和数据访问代码都绑定在同一语言平台的同一应用程序。这种巨石架构应用通常表现为一个完整的包，如一个Jar包或者一个Node.js或 Rails的完整目录结构。只要有了这个包，就什么都有了。

组织良好的巨石架构同样也有其优势，包括以下几个。

• 利于开发和调试:当前所有开发工具和IDE都很好地支持了巨石应用程序的开发。系统架构简单，调试方便。
• 部署操作本身比较简单:例如，只需要有运行时所需部署的一个WAR文件（或目录层次结构）即可。
• 很容易扩展:只要在负载均衡器后面运行这个应用的多个副本就可以扩展应用程序。

它的劣势有以下几个。

• 对整体程序不熟悉的人来说，容易产生混乱的代码，污染整个应用，给老代码的学习和理解带来困难。
• 难与新技术共同使用。
• 只能将整个应用作为一个整体进行扩展。
• 持续部署非常困难。为了更新一个组件，必须重新部署整个应用程序。

架构改造实施模式

通常，这类改造有3种实施模式，分别是拆迁者模式、绞杀者模式和修缮者模式。其中，绞杀者模式和修缮者模式都有利于持续交付，降低架构改造和发布的风险。

拆迁者模式

“拆迁者模式”就是指根据当前的业务需求，对软件架构重新设计，并组织单独的团队，重新开发一个全新的版本，一次性完全替代原有的遗留系统，如图所示。

这种方式的好处在于，它与旧版本没有瓜葛，没有历史包袱，可以按预期进行架构设计。但是，这种模式的风险包括以下几个方面。

1. 业务需求遗漏。软件的历史版本中，有很多不为人熟知的功能还在使用。
2. 市场环境变化。由于新版本架构无法一蹴而就，当市场需求发生变化时，就会错失市场良机。
3. 人力资源消耗大。必须分出人力，一边维护旧版本的功能或紧急需求，一边要安排充分人力进行架构改造。
4. “闭门造车”。新版本上线后，无法满足业务需求。

绞杀者模式

“绞杀者模式”是指保持原来的遗留系统不变，当需要开发新的功能时，重新开发一个服务，实现新的功能。通过不断构建新的服务，逐步使遗留系统失效，并最终替代它，如图所示。

这种方式的好处在于:

• 不会遗漏原有需求；
• 可以稳定地提供价值，频繁地交付版本，可以让你更好地监控其改造进展；
• 避免“闭门造车”现象。

其劣势在于:

• 架构改造的时间跨度会变大；
• 产生一定的迭代成本。

修缮者模式

“修缮者模式”是指将遗留系统的部分功能与其余部分隔离，以新的架构进行单独改善。

其收益包括:

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

而其劣势在于:

• 架构改造的时间跨度会变大；
• 会有更多额外的架构改造迭代成本。

数据库的拆分方法

一般来说，关系型数据库很可能是巨石应用中的最大耦合点.因此，对于有状态微服务的改造，我们需要非常小心地处理数据库数据做数据库拆分时，我们应该遵循以下步骤，如图所示。

1. 详细了解数据库结构，包括外键约束、共享的可变数据以及事务性边界等，如图a所示。
2. 先拆分数据库，并按照12.3.2节的介绍进行数据迁移，如图b所示。
3. 数据库双写无误后，找到程序架构中的缝隙，如图c所示。
4. 将拆分出来的程序模块和数据库组合在一起，形成微服务，如图d所示。