【CHRIS RICHARDSON 微服务系列】使用微服务重构单体应用-7

编者的话 |本文来自 Nginx 官方博客,是「Chris Richardson 微服务」系列的最后一篇。第一篇介绍了微服务架构模块,并且讨论了使用微服务的优缺点。随后的文章讨论了微服务的不同方面,包括使用 API 网关、进程间通讯、服务发现、事件驱动的数据管理,以及部署微服务。本篇将讨论从单体应用迁移到微服务的策略。

作者介绍:Chris Richardson,是世界著名的软件大师,经典技术著作《POJOS IN ACTION》一书的作者,也是 cloudfoundry.com 最初的创始人,Chris Richardson 与 Martin Fowler、Sam Newman、Adrian Cockcroft 等并称为世界十大软件架构师。

Chris Richardson 微服务系列全 7 篇:

1. 微服务架构概念解析

2. 构建微服务架构:使用 API Gateway

3. 深入微服务架构的进程间通信(本篇文章)

4. 服务发现的可行方案以及实践案例

5. 微服务的事件驱动数据管理

6. 选择微服务部署策略

7. 将单体应用改造为微服务(本篇文章)

使用微服务重构概述

将单体应用转变为微服务的过程也是将应用现代化的过程,数十年来开发者们一直致力于此。因此,当把应用重构为微服务的时候,我们可以借鉴其中的理念。

首先不要大规模地重写代码。大规模重写代码意味着你需要集中全部开发力量、从头构建全新的基于微服务的应用;听起来吸引人,但是充满风险,有可能以失败告终。正如 Martin Fowler 所言,“大规模重写唯一能够保证的只有大规模!”

相反,应当采取逐步重构单体应用的策略。逐步构建一个由微服务构成的应用,与单体应用并行运行;随着时间推移,原先由单体应用实现的功能不断收缩,最后或者完全消失,或者转变为微服务。这一方法虽然充满挑战,但风险远小于大规模重写代码。

Martin Fowler 将这一应用现代化的策略称为“杀手应用”。这一名称源自热带雨林中的杀手藤。杀手藤附生于树,直达树冠上方;树死后,留下树状的藤蔓。应用的现代化也是遵循这一模式。微服务构成的新应用围绕着遗留应用,后者最终完全不复存在。

接下来了解不同的实现策略。

策略一:停止挖坑

挖坑第一法则指出,如果发现自己掉坑里,马上停止。这一忠告也适用于难以管理的单体应用。换句话说,应该停止让单体应用继续变大,也就是在实现新功能的时候,不应该再增加代码。相反,这一策略的理念在于,把这部分新代码开发称为独立的微服务。下图展示了采用此方法的系统架构。

除了新服务和遗留应用,这个系统还包括另外两个组件。其一是请求路由,处理传入(HTTP)请求,与之前文章中描述的 API 网关类似。路由将与新功能对应的请求发送到新服务,将遗留请求发送到已有的单体应用。

另一组件是胶水代码(glue code),负责集成微服务与单体应用。微服务很少孤立存在,通常需要访问单体应用拥有的数据。胶水代码存在于单体应用或微服务中,或者两者兼有,负责数据集成。微服务使用胶水代码来读取和写入单体应用拥有的数据。

微服务可以通过以下三种方式访问单体应用的数据:

  • 调用由单体应用提供的远程 API
  • 直接访问单体应用的数据
  • 维护一份数据拷贝,与单体应用的数据库保持同步

胶水代码也被称作防崩溃层(anti-corruption layer)。对于拥有自己全新领域模型的微服务,胶水代码能够阻止其受到遗留单体应用的领域模型的污染,并且为这两种模型提供转换。防崩溃层这一术语最早出现于 Eric Evans 撰写的必读书 Domain Driven Design 中,并被提炼成为白皮书。开发防崩溃层是项不平凡的工作,要想远离单体应用的泥淖,创建防崩溃层必不可少。

以轻量级微服务的方式实现新功能有诸多优点。它能够防止单体应用变得不可管理。微服务能够独立于单体服务进行开发、部署和扩展。采用微服务能让开发者切身感受其好处。

然而,这一方法并没有解决单体应用的问题。要想解决这些问题,需要分解单体应用。

策略二:拆分前端和后端

缩小单体应用的策略之一是将表示层(presentation layer)与业务逻辑和数据访问层分离。典型的企业应用包括至少三类组件:

  • 表示层:处理 HTTP 请求并实现 (REST)API 或基于 HTML 的 Web UI。对于包含复杂用户接口的应用,表示层往往是代码的实体部分。
  • 业务逻辑层:应用的核心,实现业务逻辑
  • 数据访问层:访问诸如数据库和消息代理这样的基础架构组件

在表示逻辑与业务和数据访问逻辑之间,有着清晰的间隔。业务层的粗粒度的 API 由若干方面组成,内部封装业务逻辑组件。这个 API 是一道天然分界线,将单体应用分割成两个较小的应用。一个应用包含表示层,另一个应用包含业务和数据访问逻辑。拆分后,表示逻辑应用对业务逻辑应用远程调用。下图展示了重构前后的构架。

以这种方式切割单体应用有两大好处。首先,它使得这两个应用的开发、部署和扩展用各自独立。尤其是,它使得表示层的开发人员能够快速迭代用户接口,轻松进行 A|B 测试。其次,它暴露了远程 API,能够被微服务调用。

这种策略也只是部分解决方案,很有可能其中一个应用或两个应用变成难以管理的单体应用。这时需要使用第三种策略来消除剩余的单体应用。

策略三:提取微服务

第三种重构策略是将单体应用内现有的模块转变为独立的微服务。每当提取模块并将其转化为服务,单体应用就会收缩。一旦转化了足够的模块,单体应用也不再是问题,它或者彻底消失,或者小到成为另一个微服务。

为需要转化为微服务的模块设置优先级

大型、复杂的单体应用由数十甚至数百个模块组成,每个都是提取的对象。要弄清楚哪些模块首先被转化,往往具有挑战性。从易于提取的模块开始是个好方法,它能让开发者熟悉微服务和提取过程。然后就应该转化能从中获益最多的模块。

鉴于把模块转变为微服务非常耗时,一般会根据获益程度来给模块排序。从频繁更改的模块开始会让用户收获不菲。一旦把模块转化为微服务,也就能独立开发和部署,从而加速开发进度。

将资源需求大不相同的模块优先转化,也颇有好处。例如,把内存数据库模块转化为微服务,能够被部署在大内存主机上。同样,将实现计算算法的模块提取出来也是非常值得,这一微服务能够部署在拥有大量 CPU 的主机上。通过将对资源有着特殊需求的模块转变为微服务,应用能够易于扩展。

找出哪些模块需要优先提取后,找出现有粗粒度的边界(即分界线)也大有裨益。这些边界让模块转变为微服务更加简单、省力。例如,通过异步消息与应用的其它部分通信的模块能够相对省力、简便地转化为微服务。

如何提取模块

模块提取的第一步是定义模块和单体应用间的粒度接口。由于单体应用和微服务互相需要对方拥有的数据,因此更像是双向 API。由于模块和应用其它部分之间存在着互相依赖和细粒度的交互模型,因此实现这样的 API 充满挑战。对于重构微服务,通过领域模型实现的业务逻辑尤为挑战,开发人员需要大刀阔斧地修改代码来打破这些依赖。

粗粒度接口一旦完成,模块也就变成了独立的微服务。要做到这一点,开发人员必须编写代码,能够让单体应用和微服务通过 API 通信,API 使用进程间通信(IPC)机制。 下图展示了重构前、重构中和重构后的不同架构。

在图片中,模块 Z 将要被重构,它用到了模块 Y 的组件,同时它的组件被模块 X 使用。重构的第一步就是定义一对粗粒度 API。第一个接口是模块 X 使用的对内接口,用来唤醒模块 Z。第二个接口是模块 Z 使用的对外接口,唤醒模块 Y。

重构的第二步则是把模块转变为独立的微服务。对内和对外接口通过 IPC 机制的代码实现,开发人员可能只需要将模块 Z 与微服务支撑框架(Microservice Chassis framework)组合起来构建微服务。微服务支撑框架处理与割接相关的问题,比如服务发现。

一旦将模块提取完毕,相当于得到一个微服务,能够独立于单体应用和其它微服务进行开发、部署和扩展。如果要从头重写微服务代码,集成微服务和单体应用的 API 代码会成为这两个领域模型之间的防崩溃层。每重构一个组件,就向着微服务的方向又迈进了一步。随着时间推移,单体应用逐渐消失,微服务则越来越多。

总结

将现有单体应用迁移到微服务架构是应用的现代化。实现这一结果并不需要从头重写代码,相反,只需要渐进式地将应用重构为一组微服务。其中有三种策略可以采纳:使用微服务实现新功能、将表示组件与业务和数据访问组件拆分、以及将现有应用内的模块转变为微服务。随着时间推移,大量微服务形成,团队的敏捷和效率也会提升。

文章转载自:http://blog.daocloud.io/microservices-7/

同转:http://www.gaoxuan1989.com/category/微服务/

查看英文原文

posted @ 2019-12-22 17:24  MichaelMaDragon  阅读(235)  评论(0编辑  收藏  举报