微服务实践(七):从单体式架构迁移到微服务架构 - DockOne.io
【编者的话】这是用微服务开发应用系列博客的第七篇也是最后一篇。第一篇中介绍了微服务架构模式,并且讨论了微服架构的优缺点;接续文章讨论了微服务架构不同方面:使用API网关,进程间通信,服务发现,事件驱动数据管理以及部署微服务。本篇,我们将探讨将应用从单体式架构迁移到微服务架构需要考虑的策略。
@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、数人云、点融网、华为、轻元科技、中兴通讯等公司的技术负责人将带来实践经验分享,5月7日之前购票只需438元,欢迎感兴趣的同学抢购。
希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构。也许微服务架构比较适合你的应用。也许你正在开发一个大型、复杂单体式应用,日常开发和部署经验非常缓慢和痛苦,而微服务看起来是远方一个极乐世界。幸运的是,有可以参考的脱离苦海的策略,本篇文章中,我将描述如何逐步将单体式应用迁移到微服务架构。
本系列七篇文章列表如下:
- 微服务实战(一):微服务架构的优势与不足
- 微服务实战(二):使用API Gateway
- 微服务实战(三):深入微服务架构的进程间通信
- 微服务实战(四):服务发现的可行方案以及实践案例
- 微服务实践(五):微服务的事件驱动数据管理
- 微服务实践(六):选择微服务部署策略
- 微服务实践(七):从单体式架构迁移到微服务架构
迁移到微服务综述
迁移单体式应用到微服务架构意味着一系列现代化过程,有点像这几代开发者一直在做的事情,实时上,当迁移时,我们可以重用一些想法。
一个策略是:不要大规模(big bang)重写代码(只有当你承担重建一套全新基于微服务的应用时候可以采用重写这种方法)。重写代码听起来很不错,但实际上充满了风险最终可能会失败,就如Martin Fowler所说:“the only thing a Big Bang rewrite guarantees is a Big Bang!”
相反,应该采取逐步迁移单体式应用的策略,通过逐步生成微服务新应用,与旧的单体式应用集成,随着时间推移,单体式应用在整个架构中比例逐渐下降直到消失或者成为微服务架构一部分。这个策略有点像在高速路上限速到70迈对车做维护,尽管有挑战,但是比起重写的风险小很多。
Martin Fowler将这种现代化策略成为绞杀(Strangler)应用,名字来源于雨林中的绞杀藤(strangler vine),也叫绞杀榕(strangler fig)。绞杀藤为了爬到森林顶端都要缠绕着大叔生长,一段时间后,树死了,留下树形藤。这种应用也使用同一种模式,围绕着传统应用开发了新型微服务应用,传统应用会渐渐退出舞台。
我们来看看其他可行策略。
策略1——停止挖掘
Law of Holes是说当自己进洞就应该停止挖掘。对于单体式应用不可管理时这是最佳建议。换句话说,应该停止让单体式应用继续变大,也就是说当开发新功能时不应该为旧单体应用添加新代码,最佳方法应该是将新功能开发成独立微服务。如下图所示:
除了新服务和传统应用,还有两个模块,其一是请求路由器,负责处理入口(http)请求,有点像之前提到的API网关。路由器将新功能请求发送给新开发的服务,而将传统请求还发给单体式应用。
另外一个是胶水代码(glue code),将微服务和单体应用集成起来,微服务很少能独立存在,经常会访问单体应用的数据。胶水代码,可能在单体应用或者为服务或者二者兼而有之,负责数据整合。微服务通过胶水代码从单体应用中读写数据。
微服务有三种方式访问单体应用数据:
- 换气单体应用提供的远程API
- 直接访问单体应用数据库
- 自己维护一份从单体应用中同步的数据
胶水代码也被称为容灾层(anti-corruption layer),这是因为胶水代码保护微服务全新域模型免受传统单体应用域模型污染。胶水代码在这两种模型间提供翻译功能。术语anti-corruption layer第一次出现在Eric Evans撰写的必读书Domain Driven Design,随后就被提炼为一篇白皮书。开发容灾层可能有点不是很重要,但却是避免单体式泥潭的必要部分。
将新功能以轻量级微服务方式实现由很多优点,例如可以阻止单体应用变的更加无法管理。微服务本身可以开发、部署和独立扩展。采用微服务架构会给开发者带来不同的切身感受。
然而,这方法并不解决任何单体式本身问题,为了解决单体式本身问题必须深入单体应用做出改变。我们来看看这么做的策略。
策略2——将前端和后端分离
减小单体式应用复杂度的策略是讲表现层和业务逻辑、数据访问层分开。典型的企业应用至少有三个不同元素构成:
- 表现层——处理HTTP请求,要么响应一个RESTAPI请求,要么是提供一个基于HTML的图形接口。对于一个复杂用户接口应用,表现层经常是代码重要的部分。
- 业务逻辑层——完成业务逻辑的应用核心
- 数据访问层——访问基础元素,例如数据库和消息代理
在表现层与业务数据访问层之间有清晰的隔离。业务层有由若干方面组成的粗粒度(coarse-grained)的API,内部包含了业务逻辑元素。API是可以将单体业务分割成两个更小应用的天然边界,其中一个应用是表现层,另外一个是业务和数据访问逻辑。分割后,表现逻辑应用远程调用业务逻辑应用,下图表示迁移前后架构不同:
单体应用这么分割有两个好处,其一使得应用两部分开发、部署和扩展各自独立,特别地,允许表现层开发者在用户界面上快速选择,进行A/B测试;其二,使得一些远程API可以被微服务调用。
然而,这种策略只是部分的解决方案。很可能应用的两部分之一或者全部都是不可管理的,因此需要使用第三种策略来消除剩余的单体架构。
策略3——抽出服务
第三种迁移策略就是从单体应用中抽取出某些模块成为独立微服务。每当抽取一个模块变成微服务,单体应用就变简单一些;一旦转换足够多的模块,单体应用本身已经不成为问题了,要么消失了,要么简单到成为一个服务。
排序那个模块应该被转成微服务
一个巨大的复杂单体应用由成十上百个模块构成,每个都是被抽取对象。决定第一个被抽取模块一般都是挑战,一般最好是从最容易抽取的模块开始,这会让开发者积累足够经验,这些经验可以为后续模块化工作带来巨大好处。
转换模块成为微服务一般很耗费时间,一般可以根据获益程度来排序,一般从经常变化模块开始会获益最大。一旦转换一个模块为微服务,就可以将其开发部署成独立模块,从而加速开发进程。
将资源消耗大户先抽取出来也是排序标准之一。例如,将内存数据库抽取出来成为一个微服务会非常有用,可以将其部署在大内存主机上。同样的,将对计算资源很敏感的算法应用抽取出来也是非常有益的,这种服务可以被部署在有很多CPU的主机上。通过将资源消耗模块转换成微服务,可以使得应用易于扩展。
查找现有粗粒度边界来决定哪个模块应该被抽取,也是很有益的,这使得移植工作更容易和简单。例如,只与其他应用异步同步消息的模块就是一个明显边界,可以很简单容易地将其转换为微服务。
如何抽取模块
抽取模块第一步就是定义好模块和单体应用之间粗粒度接口,由于单体应用需要微服务的数据,反之亦然,因此更像是一个双向API。因为必须在负责依赖关系和细粒度接口模式之间做好平衡,因此开发这种API很有挑战性,尤其对使用域模型模式的业务逻辑层来说更具有挑战,因此经常需要改变代码来解决依赖性问题,如图所示:
一旦完成粗粒度接口,也就将此模块转换成独立微服务。为了实现,必须写代码使得单体应用和微服务之间通过使用进程间通信(IPC)机制的API来交换信息。如图所示迁移前后对比:
此例中,正在使用Y模块的Z模块是备选抽取模块,其元素正在被X模块使用,迁移第一步就是定义一套粗粒度APIs,第一个接口应该是被X模块使用的内部接口,用于激活Z模块;第二个接口是被Z模块使用的外部接口,用于激活Y模块。
迁移第二步就是将模块转换成独立服务。内部和外部接口都使用基于IPC机制的代码,一般都会将Z模块整合成一个微服务基础框架,来出来割接过程中的问题,例如服务发现。
抽取完模块,也就可以开发、部署和扩展另外一个服务,此服务独立于单体应用和其它服务。可以从头写代码实现服务;这种情况下,将服务和单体应用整合的API代码成为容灾层,在两种域模型之间进行翻译工作。每抽取一个服务,就朝着微服务方向前进一步。随着时间推移,单体应用将会越来越简单,用户就可以增加更多独立的微服务。
总结
将现有应用迁移成微服务架构的现代化应用,不应该通过从头重写代码方式实现,相反,应该通过逐步迁移的方式。有三种策略可以考虑:将新功能以微服务方式实现;将表现层与业务数据访问层分离;将现存模块抽取变成微服务。随着时间推移,微服务数量会增加,开发团队的弹性和效率将会大大增加。
原文链接:Refactoring a Monolith into Microservices(翻译:杨峰)
转载于:https://www.cnblogs.com/lonelyxmas/p/10406207.html
微服务实践(七):从单体式架构迁移到微服务架构 - DockOne.io相关推荐
- 微服务实践(七):从单体式架构迁移到微服务架构
迁移到微服务综述 迁移单体式应用到微服务架构意味着一系列现代化过程,有点像这几代开发者一直在做的事情,实时上,当迁移时,我们可以重用一些想法. 一个策略是:不要大规模(big bang)重写代码(只有 ...
- 微服务实战(七):从单体式架构迁移到微服务架构
http://dockone.io/article/1266 希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构.也许微服务架构比较适合你的应用.也许你正在开发一个大型.复杂 ...
- 单体架构迁移到微服务,8个关键的思考、实践和经验
单体架构迁移到微服务,8个关键的思考.实践和经验 转自:http://www.open-open.com/lib/view/open1470917801705.html 随着微服务架构的持续火热,网络 ...
- 从单体架构迁移到微服务,8个关键的思考、实践和经验
随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多.去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上.毋庸置疑, ...
- 从单体架构迁移到微服务
随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多.去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上.毋庸置疑, ...
- 单体 soa 微服务 区别_漫谈何时从单体架构迁移到微服务?
面对微服务如火如荼的发展,很多人都在了解,学习希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了,到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些 ...
- 为何从单体架构迁移到微服务这么难?
点击上方蓝色"程序猿DD",选择"设为星标" 回复"资源"获取独家整理的学习资料! 面对微服务如火如荼的发展,很多人都在了解,学习希望能在自 ...
- 漫谈何时从单体架构迁移到微服务?
面对微服务如火如荼的发展,很多人都在了解,学习希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了,到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些 ...
- 微服务架构图_漫谈何时从单体架构迁移到微服务?
面对微服务如火如荼的发展,很多人都在了解,学习希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了,到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些 ...
- 微服务连载(二)漫谈何时从单体架构迁移到微服务?
面对微服务如火如荼的发展,很多人都在了解,学习希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了,到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些 ...
最新文章
- 对号入座,看看未来几年机器人是否会取代你的工作
- 简书python爬虫权威_python爬虫 --- 简书评论
- MySQL - mysqldump多种方式实现数据迁移
- SD-SD用到的文本对象列表
- MyBatis中动态sql的模糊搜索、foreach实现In集合的用法
- [Android]用架构师角度看插件化(1)-Replugin入门剖析
- 《人民日报》专访姚期智院士:AI是历史性的起跑线机遇
- keras添加正则化全连接_第16章 Keras使用Dropout正则化防止过拟合
- 王思聪、贾跃亭、罗永浩组成神奇的三角债?罗永浩回应...
- 位运算和sizeof运算符
- 添加内核驱动模块(4)(mydriver.c+ Konfig+Makefile )
- Android Studio中修改APP图标和APP名称
- 实验室服务器多人共用账号,搭建多人共用的GPU服务器
- 当你面临选择,所谓经验可能一文不值
- 漂流瓶php源码,微信小程序之仿微信漂流瓶
- node.js错误解决:Syntax Error: Error: No ESLint configuration found.
- windows7 x64系统 不能安装MTP驱动
- C语言实现音乐播放器 visual studio 2019
- 大型ICP正在重新激活海底光缆市场 2022年收入将超14亿美元
- 教你使用淘宝接口查询手机号码归属地
热门文章
- 最近邻搜索算法flann Marius Muja and David G. Lowe
- HTML——背景颜色设置
- 第一次模拟考试总结反思
- 软件工程——软科中国大学专业排名
- 此Apple ID尚未在iTunes Store Apple Id登录苹果商店(App Store)身份验证提示需要官网技术支持
- linux需要安装显卡驱动么,linux显卡驱动需要安装吗
- jsp中你必须记住的379
- 六、python实现日语单词索引:查询单词对应的课
- php 视频裁剪,视频画面大小裁剪 把视频画面多余部分裁剪掉,视频画面裁剪工具的使用方法...
- php编程怎样装数据库,php数据库管理工具phpmyadmin下载、安装、配置