【分享】一次单体架构改造成微服务架构的拆分实践

qiaohhgz 2019-04-18 14:38:03 ⋅ 131 阅读

上周更新了一篇【揭秘】一个小团队真正能落地的微服务架构实践,很多网友私信询问在落地微服务的时候服务是如何拆分的?有没有具体的方法?可不可以一劳永逸?

额......好吧,针对大家比较关注的问题今天来分享一下之前在做电商的时候对公司产品做架构改造升级,以及跟其他同行一起聊过比较公认、适和小团队比较快速落地的微服务拆分方法。

备注:文章中提供的拆分方法不一定全部得到大家的认可,如果有更好的可以留言分享哦~~~

一、项目拆分背景

团队组成
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下来用。这里只想说洗洗睡吧


关注我们

优质文章推荐

贡献者

  • IT实战联盟-Line

---------------END----------------

后续的内容同样精彩

长按关注“IT实战联盟”哦




全部评论: 0

    我有话说:

    架构实战篇:认识服务架构

    服务是一个新兴软件架构,就是把一个大型单个应用程序和服务分为数十个支持服务

    架构实战篇:一个可供中小团队参考服务架构技术栈

    作者近年一直在一线互联网公司(携程,拍拍贷等)开展服务架构实践,根据我个人一线实践经验和我平时对Spring Cloud调研,我认为Spring Cloud技术栈中有些组件离生产级开发尚有

    服务架构若干常用设计模式

    在我们选择了用服务架构来设计、交付数字化应用后,因服务架构本身所带来一些共性问题。

    服务架构学习笔记():重新认识服务

    服务(Microservice)是服务化思路种最佳实践方向,遵循SOA思路,各个企业在服务化治理道路上走时间长了,踩坑多了,整个软件交付链路上各个环节基础设施逐渐成熟了,服务

    SpringBoot+zk+dubbo架构实践):本地部署zookeeper

    SpringBoot+zk+dubbo架构实践系列实现目标:自己动手搭建服务架构

    服务架构:搭建网站扫码登录功能设计

    信扫码登录大家都是应用比较多登录方式了,现在大购物网站像京东、淘宝等都支持使用APP扫码登录网站了。今天就用APP扫码登录网站实例来举例说明服务架构搭建过程。

    SpringBoot+zk+dubbo架构实践(三):部署Dubbo-admin管理平台

    本系列架构实践不做深入探讨,主旨是带领大家能够快速踏入服务架构门槛,能够轻松搭建套属于自己服务架构。——写代码我们是认真滴!

    精品推荐:服务架构下静态数据通用缓存机制

    在分布式系统中,特别是最近很火服务架构下,有没有或者能不能总结出一个业务静态数据通用缓存处理机制或方案,这篇文章将结合一些实际研发经验,尝试理清其中存在关键问题以及探寻通用解决之道。

    WeCube 2.7.1 发布,站式 IT 架构管理和运维管理工具

    WeCube简介 众银行在分布式架构实践过程中,发现将银行核心系统构建于分布式架构之上,会遇到一些与传统单体应用不同痛点(例如,服务器增多,部署难度大;调用链长,全链路跟踪困难; 系统复杂

    什么是服务?什么是中台?阿里中台战略?

    服务架构单体应用,按照业务领域分为多个高内聚低耦合小型服务

    码云推荐:一个优秀分布式spring boot/Spring Cloud API限流框架,特别适合服务架构

    一个优秀分布式spring boot/Spring Cloud API限流框架,特别适合服务架构.

    SpringBoot+zk+dubbo架构实践(五):搭建服务电商架构(内附GitHub地址)

    了mybatis和swagger让接口可视化并完成了一些增删改查基础业务,对了还有个页查询!

    阿里技术:聊聊从单机至亿级流量大型网站系统架构演进过程

    网站初期,我们经常会在单机上跑我们所有程序和软件。此时我们使用一个容器,如tomcat、jetty、jboos,然后直接使用JSP/servlet技术......

    「转载」服务分布式架构中,如何实现日志链路跟踪?

    背景 开发排查系统问题用得最多手段就是查看系统日志,在分布式环境中一般使用ELK来统一收集日志,但是在并发大时使用日志定位问题还是比较麻烦,我们来看下面图     上图

    京东技术:京东系统架构师如何让笨重架构变得灵巧

    京东系统架构师,从事架构设计与开发工作,熟悉各种开源软件架构。在Web开发、架构优化上有较丰富实战经历。

    Java Web架构实战篇:聊聊前后端分离架构

    RESTful思想和Json数据标准出现,使得这种交互日益便利。Vue.js 用于构建用户界面渐进式框架

    架构设计原则 - 高并发

    高并发设计可以从以下几方面考虑:无状态服务化消息队列数据异构缓存并发化1. 无状态无状态应用容易进行水......

    老板逼你上服务了吗?

    “ 这些年软件设计规模越来越庞大,业务需求也越来越复杂,针对系统性能、高吞吐率、高稳定性、高扩展等特性提出了更高要求。   图片来自 Pexels可以说业务需求是软件架构能力

    【开源资讯】JWCloud 专业版 v1.0.0 发布,基于 SpringCloud 研发服务框架

    简介 JavaWeb_Cloud 服务平台是款基于 SpringCloud 框架研发分布式微服务框架,主要使用技术栈包括: SpringCloud、Vue、ElementUI