【分享】一次单体架构改造成微服务架构的拆分实践
上周更新了一篇【揭秘】一个小团队真正能落地的微服务架构实践,很多网友私信询问在落地微服务的时候服务是如何拆分的?有没有具体的方法?可不可以一劳永逸?
额…好吧,针对大家比较关注的问题今天来分享一下之前在做电商的时候对公司产品做架构改造升级,以及跟其他同行一起聊过比较公认、适和小团队比较快速落地的微服务拆分方法。
备注:文章中提供的拆分方法不一定全部得到大家的认可,如果有更好的可以留言分享哦~~~
一、项目拆分背景
团队组成
UI设计:1人(其他专门做商品设计不算)
前端开发:2人
后端开发:5人(高、中、低搭配)
测试:2人
运维:由后端开发担任(你懂的…)
业务简介
和市场上大家经常用的的电商平台一样,用户可以通过PC端、APP和公众号H5等入口进入商城进行浏览商品、参加活动、下单、支付等业务,这里不做过多叙述!
系统模型
如下图所示:
二、设计拆分方案
1、基于业务逻辑拆分
遵从共同封闭原则,一个服务的开发和迭代不影响调用它API的消费端。特别是某个服务的改动会造成故障并影响其他服务。
将系统中的业务模块按照职责范围识别出来,每个单独的业务模块拆分为一个独立的服务,保证各个服务能够独立运行就可以了。
是不是很直观?很简单?大家都知道的事情但是实际操作为啥会出现问题呢?
这种基于业务逻辑的拆分虽然很直观但是由于团队成员对于各自的职责范围理解差异很大,往往会出现意见向左的事情,很难达到统一。
例如:把上图的电商平台第一种方案拆分为“商品”、“订单”和“用户” 3个服务,这样看也能把整个业务囊括进去。但是看看第二种方案,如下图所示:
如下图所示:
如图拆分为“商品”、“订单”、“用户”、“支付”、“广告”等6个服务,那么是不是更合理?那是否意味着拆分的越详细越好呢?
那就看一下“三个火枪手”原则!
2、服务拆分力度按照“三个火枪手”原则,1个微服务3个人负责开发。
就是说单纯的从业务逻辑角度拆分的话,很难判断服务的粒度。应该根据“三个火枪手”原则计算一下需要拆分的范围和数量,再确定合适的“职责范围”,避免出现拆分过粗或过细的情况。
并且3个人负责开发一个系统,系统的复杂度刚好达到每个人都能全面理解整个系统,又能够根据每个人的技术能力对开发任务进行合理分工。
这么分析来看这样的搭配非常完美,但是大家都懂的很少有人力资源很充足的情况出现,不然大家就不会集体抗议 996了。不管如何尽量避免出现一个人维护一个服务的情况出现,因为有两个方面的考虑,第一,微服务是相对封闭的,里面是一条垂直的线,需要有专人去跟踪。如果一个人维护有哪几点不好?第一是力度过细,第二个是万一这个人今天请假了或者是生病了,甚至离职了,那总要有一个人backup吧,避免出现系统性风险。
3、基于可扩展拆分
将系统中的业务模块按照稳定性排序,将已经成熟和改动不大的服务拆分为稳定服务,常变化和迭代的服务拆分为变动服务。
例如:系统中的用户服务、订单服务等不经常变化,跟业务关系不大,但又是整个系统最基础的功能可以划分为稳定服务。系统中的广告服务、商品服务等经常变更和迭代的服务划分为变动服务。
记住针对团队人力资源不充裕的情况,稳定服务可以拆分粒度粗一点,甚至可以放到一个子系统中。当然经常变动的服务业不要太细,不然维护不过来,会导致各个环节都可能出现问题。
4、基于性能拆分
这个不难理解,基于性能拆分就是将性能要求高的或者会发生高并发业务场景的模块拆分出来,避免发生压力过大影响其他服务的正常使用。这里不细说,因为和具体的性能瓶颈有关,影响因素过多,例如:服务器、数据库、缓存、网络等等。典型的业务场景就是电商的秒杀抢购功能,可以独立成一个服务 相应的资源可以多倾斜。
大家可以参考这篇:高并发服务器逻辑处理瓶颈,如何解决?
5、基于基础设施拆分
基础设施通常大家都忘记了吧,并且安排工作量的时候 很少写进工时里面的吧?领导也是看不见的工作量吧?但是可以说真正决定微服务成败的,恰恰是那个被大部分人都忽略的。系统落地后麻烦不断,简直就是坑中之坑,基础设施的建设也是考验整个团队的核心环节!
来看一下微服务的基础实施需要掌握哪些知识:
额。。。是不是懵了?这个小团队玩不转吧?!把这些搞完估计项目都黄了,哈哈哈!
虽然建设完善的微服务基础设施是一项庞大的工程,但是也不用看完后就放弃,或者认为自己是个小团队就不使用微服务了。虽然看起来很多但是目前市场上已经有成熟的开源框架直接拿来用的微服务基础设施。例如:SpringCloud,里面集成了服务发现、服务路由、网关、配置中心等常用的功能。再说了上面那么多基础设施并不是每个都是必须的,来来来我们划分个优先级:
1、服务发现、服务路由、服务容错:这是最基本的微服务基础设施。
2、接口框架、API 网关:主要是为了提升开发效率,接口框架是提升内部服务的开发效率,API 网关是为了提升与外部服务对接的效率。
3、自动化部署、自动化测试、配置中心:主要是为了提升测试和运维效率。
4、服务监控、服务跟踪、服务安全:主要是为了进一步提升运维效率。
根据优先级分析来看3和4两种是随着微服务节点数量的增加而越来越重要,前期拆分的服务较少并且团队对于微服务架构也在逐渐掌握中,可以暂时采用人工的方式,虽然效率低了点,但是不会因为某个环节熟悉程度不够而导致整体崩盘的情况。
三、经验总结
最后放上一张最终完成的系统访问交互流程图:
最后也写一下自己用微服务拆分改造后的一些经验吧,前期根据上面的拆分法则做架构改造还是比较舒服的,这里是真的舒服!因为业务更、代码、规范更清晰了,每个人的职责也更加明确了,特别是团队开发热情和积极性非常的高。因为从规划到落地的过程大家都成长了许多。但是这些还远远不够,由于职责、代码明确到个人,这样对于团队成员的学习能力也是很大的挑战。就拿学习能力来说吧,单体架构的时候可能只需要把自己开发的接口写好暴露出来就行了,但是微服务是从前到后的相关知识都需要学习,整体体系还是非常庞大的。
总之,微服务架构不再是一个人打天下的时代了,而是通过整个团队的技术综合水平来衡量了。发完搞 估计又有许多人私信说 只是理论罢了 没有一点实用价值,其实我也明白 现在很多人想要的就是 直接把源码地址贴出来就行了,直接down下来用。这里只想说洗洗睡吧!。
优质文章推荐
微服务架构学习笔记(一):重新认识微服务
【揭秘】一个小团队真正能落地的微服务架构实践
高并发服务器逻辑处理瓶颈,如何解决?
SpringBoot+zk+dubbo架构实践(一):本地部署zookeeper
SpringBoot+zk+dubbo架构实践(二):SpringBoot 集成 zookeeper
SpringBoot+zk+dubbo架构实践(三):部署Dubbo-admin管理平台
SpringBoot+zk+dubbo架构实践(四):sb+zk+dubbo框架搭建(内附源码Git地址)
SpringBoot+zk+dubbo架构实践(五):搭建微服务电商架构(内附GitHub地址)
贡献者
- IT实战联盟-Line
更多精彩内容可以关注“IT实战联盟”公众号哦~~~
【分享】一次单体架构改造成微服务架构的拆分实践相关推荐
- Java架构师-微服务:微服务架构【单体部署 --改造--> 微服务架构】【分布式:分散压力;微服务:分散能力】【RESTFul+Docker+K8S、SpringCloud】
一.微服务概述 微服务架构是团队面对互联网产品爆发式增长的最优选择,要解决的是快速迭代.高可靠和高可用等问题,把复杂度很高的产品拆分成一些较小的模块,并遵循康威定律,每一个模块用5-9个小团队来维护, ...
- 【转】应用架构一团糟?如何将单体应用改造为微服务
概述 将单体应用改造为微服务实际上是应用现代化的过程,这是开发者们在过去十年来一直在做的事情,所以已经有一些可以复用的经验. 全部重写是绝对不能用的策略,除非你要集中精力从头构建一个基于微服务的应用. ...
- 微服务系列(七):将单体应用改造为微服务
编者的话|本文来自 Nginx 官方博客,是「Chris Richardson 微服务」系列的第五篇文章.第一篇文章介绍了微服务架构模式,并且讨论了使用微服务的优缺点:第二和第三篇描述了微服务架构模块 ...
- “逃离”单体,GitHub的微服务架构实践
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取 后台回复"k8s",可领取k8s资料 本文介绍 Git ...
- dubbo协议_阿里P8架构师谈微服务架构:Dubbo+Docker+SpringBoot+Cloud
微服务架构 什么是微服务架构呢?简单说就是将一个完整的应用(单体应用) 按照一定的拆分规则(后文讲述)拆分成多个不同的服务,每个服务都能独立地进行开发.部署.扩展.服务于服务之间通过注入RESTful ...
- 微服务实战(七):从单体式架构迁移到微服务架构
http://dockone.io/article/1266 希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构.也许微服务架构比较适合你的应用.也许你正在开发一个大型.复杂 ...
- 微服务实践(七):从单体式架构迁移到微服务架构
迁移到微服务综述 迁移单体式应用到微服务架构意味着一系列现代化过程,有点像这几代开发者一直在做的事情,实时上,当迁移时,我们可以重用一些想法. 一个策略是:不要大规模(big bang)重写代码(只有 ...
- 架构探险-轻量级微服务架构_第3部分-单活动架构+一些时髦的Dagger
架构探险-轻量级微服务架构 This series takes a basic MVP app using Retrofit and RxJava to display a list of Githu ...
- python微服务架构设计模式_微服务架构设计模式 PDF 电子书 百度云 网盘下载
你还没有注册,无法下载本站所有资源,请立即注册! 您需要 登录 才可以下载或查看,没有帐号?立即注册 x java自学网(http://www.137zw.com)-java论坛,java电子书推荐: ...
- 我需要一个高并发的架构,我的系统要改造成微服务吗
摘要: 最近大家都在谈微服务,随着越来越多的在线业务需要提供更大并发的scale-up 和 scale out能力,微服务确实提供了比较好分布式服务的解决方案. 阿里云高级解决方案架构师 杨旭 世界最 ...
最新文章
- Xcode_7_GM_seed.dmg下载
- 网站降权可从两方面着手分析
- 读书笔记之Unix命令
- Social Media Modify case - still about attribute_ref
- Linux学习总结(24)——Linux查找文件命令
- linux 快捷matlab_ubuntu下Matlab_Linux添加工具包操作步骤
- QQ截图自动保存工具分享
- 【html----花瓣特效(附源代码)】
- [MFC] 绘制图像ROI区域(OpenCv库)
- webflux excel文件上传:java.io.IOException: Unable to read entire header; 0 bytes read; expected 512 byte
- 有效的运营技巧让中国卖家在跨境电商领域销量翻番
- word转换为html为什么图片显示不了,word插入html 转换为docx图片不显示问题
- 年货来咯:精选年度最受欢迎干货,覆盖客户端、服务端、前端、数据、算法……...
- 2018年——幻灭 2019年——重启
- android模拟遥控器home点击
- linux解压gz.gz文件,linux解压tar.gz并重命名_linux解压tar.gz文件
- linux网卡断流测试,RouterOS断流解决办法探讨
- 第15章_存储过程与函数(创建存储过程、调用存储过程、存储函数的使用、存储过程和函数的查看、修改、删除)
- linux虚拟机使用磁带机,在Linux下如何使用磁带机
- COGS732. [网络流24题] 试题库