点餐业务服务拆分分析
2024-06-10 04:19:58
我们有两种方式可以拆分服务,第一种我们的系统分为买家端和卖家端,你可以把vue放到app上,用来做买家端需要的接口,卖家端呢,也就是PC端,由freemark做的html页面作为另外一个边缘服务,两端同时向后端的通用服务请求数据,等同于就是手机端和PC端,直接来划分,第二种你可以把订单UI,边缘服务里面,商品和支付你可以把它单独放到一个边缘服务里面,等于UI是按照业务来,不是按照终端来划分了,那么这两种拆分的方式,哪一种才是正确的呢,大家赶紧选一个,心理面想一个,第一种还是第二种,正确是这两种都不对,可能最长的路就是师兄的套路了,那我们来看一下为什么说不对,如果点餐项目就是我自己的小店,BOSS是我,开发人员是我,小二还是我,我上线了自己的微信点餐,每天卖个100、80万,月入几万块,小日子过得挺滋润,这个时候有个人跑过来跟我说,你这个小餐系统可以微服务化,要微服务拆分,那我肯定会当场拒绝他,没拆分的必要,团队迭代变化也不大,搞成微服务,部署上就麻烦很多,果断拒绝,现在我们是一个快速发展的IT点餐部门了,业务现在快速增长,需求不断提出,确实需要微服务化了,我们应该审视一下,比如当前公司技术人员的技术栈,看看前端技术人员的水平,是不是适合将UI这一部分,单独拆成一个微服务,由2前端的同志们,单独维护,比如前端团队精通Node.js,但是团队人数也不是那么多,那就可能倾向于单独奖Vue APP,接口部分拆分成一个单独的服务,倾向于第一种方案,那如果是服务增长异常迅速,不论是订单,支付,广告商品,各种业务增长都特别特别的快,前后端开发人员,在公司里面也特别充足,那就可能根据业务分成多个小组,一个小组负责一个微服务,有自己单独的前端人员,那么第二种拆分方法,可能会是个更好的选择,所以起点和团队结构,沟通方式,是真的会影响你在软件上的趋势
我们来聊聊具体的方法论,首先这是我比较喜欢的扩展立方模型,他出自一本书,叫做可扩展的艺术,大家有兴趣的话可以去看看,讲的是三维伸缩性模型,X轴水平复制,就是通过副本扩展,将应用程序水平复制,通过负载均衡复制一样的应用的方式,来实现应用程序的伸缩性,提高应用程序的容量,和可用度,Z轴呢,是将按数据分区,简单点说,就是每个服务器,负责一个数据子集,每个服务器运行的代码是一样的,伸缩性的第三个维度,是针对功能性分解的,Y轴伸缩,就是将不同职责的模块,分成不同的服务,通过这个模型,我们很自然的能够理解,服务拆分的两个关键地方,功能和数据
先来聊聊拆功能,拆功能的首要原则就是,贯彻单一职责,每一个服务只负责单独的一个部分,要让服务松耦合,高内聚,松耦合就是服务之间耦合度低,修改一个服务不要导致另外一个服务跟着修改,高内聚指的是服务内部,相关的行为都聚集在一个服务内,而不是分散在不同的服务中,这样修改一个行为时,只要修改一个微服务即可,划分服务的时候,用这个条件去验证,服务划分是否合理,如果修改了一个行为,多个服务都要动,就是应该当初划分不合理导致的,第二点,是关注点分离,讲到关注点分离,可能很多人听说过界限上下文,界限上下文呢,是来自领域驱动设计一书,是微服务火起来后的一个复苏经典理论,他完全值得一个专题去学习,我个人对领域驱动设计理解的不是特别深,所以这里只聊聊关注点分离,关注点分离的基本方法有,按职责分离关注点,按通用性分离关注点,按粒度级别分离关注点,按职责分离可以理解成,比如我们的服务,进行分类,比如明显的,按业务领域可以划分出来的服务,职责比较单一,比如订单,商品,还有比如网站的前端服务,APP的服务接口,这些很明显可以,按通用性分离,是指一些基础组件,与具体的业务无关的,也可以划分出来做为一个单独的服务,比如消息服务,用户服务,同时前面说的业务划分出来的服务,我们也应该将其不同模块,或者组件进行拆分,比如把公共组件,拆分成独立的原子服务,形成相对独立的原子服务层,最后我们要考虑服务的粒度,微服务并不是越小越好,他的粒度不是一个好把握的点,比如我点单里面有一个订单服务,初期他比较合适,后来随着业务增大,他的功能增加,会导致他变得非常胖,很有可能需要我们再次拆分,拆分成订单服务,和支付服务,两个服务,拆分功能和拆分数据,是有先后顺序的,应该先考虑拆分其业务功能,再考虑拆分业务功能对应的数据,第二点,是无状态服务
先说一下什么是状态,如果一个数据需要被多个服务共享,才能完成一个请求,那么这个数据就可以称为状态,进而依赖这个状态数据的服务,被称为有状态服务,反之称为无状态服务,无状态服务并不是说,在微服务架构里面,不允许这种状态,而是要把有状态的业务服务,改变成为无状态的服务
比如我们以前在本地内存中,建立的数据缓存,Session缓存,到现在微服务架构中,就应该把这些数据,迁移到分布式缓存中,让业务服务,变成一个无状态的Session节点,就可以按需动态伸缩,在运行时,动态增删节点,不用再考虑缓存数据如何同步的问题
基于以上我们先整体来分析一下,点餐业务的功能,原始的点餐业务,买家部分的前端UI,是Vue APP,他通过API接口,向后端SpringBoot服务,请求数据,数据对应的功能,有以下一些,有商品的,订单的,可以下单和查询订单,广告的,有店铺的介绍之类,还有用户的,买家用户注册之类,还有支付,原始的是微信支付,根据业务发展,会很自然的想到,支付你以后会接入其他的支付,比如像支付宝,银联,卖家部分的前端UI,原始是freemarker提供的模板引擎,渲染而成,后端功能部分,包括以下几个方面,有商品的,对商品更细粒度的查询,同时还有增删改查,用户的卖家登陆,还有支付,各种支付渠道的后端逻辑,如果要改成微服务架构呢,比如这门课的讲师是我,我就以自身的特点,假设我公司的这个组,都是4个到6个,我这个水平的人,这个水平有什么特点呢,就是JAVA后端比较熟悉,在业务方面掌握的马马虎虎,那我倾向的方法是,业务APP作为一个单独的服务,放到Nginx上,原始卖家端UI,就是除去支付UI以外,单独成为一个单独服务,而订单用户,商品等等,成为独立的后端服务,就是商品服务和订单服务,放置在Nginx上的Vue APP,所需要的接口提供数据,也能提供卖家端UI,边缘服务提供数据,而支付服务由于他的特点,他还包含UI,当前UI和原始业务,建在一起还是一个服务,这有利于他增加支付渠道,如果是放在另外一个环境下呢,比如是在一个业务高速发展的背景下,点餐服务目测的业务扩展,很可能新增的功能,可以来分析一下,比如短信服务,日志服务,积分服务,优惠券服务,那其中比如短信这种,很明显是和具体的业务无关的,这种服务通常会作为基础服务,单独抽取出来,供其他服务调用,同样类似的比如消息系统,用户这些是很合适称为基础服务,还有比如Redis缓存这一块,很多公司会对Redis抽取作为一个单独的服务,在现实中,一个公司的一个小组,不可能去负责所有微服务的实现,让你去实现的微服务,肯定是有限的,在开展微服务的时候呢,不要妄图一步到位,我前面强调过,好的架构不是设计出来的,是演进而来的,而且演进一直在持续,很多小伙伴看书看微服务案例,只看到微服务架构的演进结果,主观或者客观的忽略了,演进过程,所以正确的做法应该是,快速出一个微服务,微服务就是要低成本,低风险的渐进式演进,所以要一直看一直设计,要用于面对失败,快速的放到生产环境中,去面对真实的问题,在这个点餐业务中,我们快速选定一到两个有联系的服务,确定他的场景,要解决的问题,以及要达到的效果,然后就应该速度开发,快速试错,不要企图服务划分一次就能正确,他就是一个持续权衡取舍的过程,在这里我们先选定商品服务和订单服务,因为这两个服务是点餐的核心服务,同时他们之间有调用关系,可以很好地实践,同时它也应用于我们后面要讲的服务间的通信,接下来我们将商品和订单业务,实现起来,在后续讲API网关的章节里,我们会引入另外一个用户服务,希望对SpringBoot的基本使用是熟练的,我会快速的实现基本功能,对咬实现的业务有一定的了解
点餐业务服务拆分分析相关推荐
- 微服务 - 业务服务拆分分析
X轴就是水平扩展就是集群就是负载均很. Z轴就是说代码一样但是数据分区了,存在不同的范围内. Y轴自然就是把不同功能的代码分服务了. 如何拆数据? 1.每个微服务都有单独的数据存储,达到松耦合,其它服 ...
- SpringCloud微服务实战(四)-微服务中的服务拆分
订单服务源码 https://github.com/Wasabi1234/SpringCloud_OrderDemo 商品服务源码 https://github.com/Wasabi1234/Spri ...
- 学习笔记：带你十天轻松完成 Go 微服务系列（二）- 服务拆分
学习笔记:带你十天轻松搞定 Go 微服务系列(二) 1.学习课程 2.服务拆分 2.1 按业务服务拆分 2.2 按调用方式拆分 3.创建项目目录 3.1 在 code 中新建项目 3.2 创建 mal ...
- 7：第三章：电商工程分析：2：电商工程业务解读与微服务拆分；
说明: (1)本篇博客内容:[先了解一下,电商系统应该包含哪些业务]→[然后,结合微服务架构思想和原则,对电商系统的业务进行拆分]: (2)在实际中,这部分工作一般都是大佬干的,一般人hold不住: ...
- 微服务拆分：业务横向拆分和纵向拆分
大规模系统架构的设计一般原则就是尽可能地拆分,以达到更好的独立扩展与伸缩.更灵活的部署.更好的隔离和容错.更好的开发效率. 具体的拆分策略大体上可以分为横向拆分和纵向拆分. 总结: 纵向拆分主要从业务 ...
- 【秒杀购物商城业务服务】「分布式架构服务」盘点中间件服务的高可用模式及集群技术的方案分析
秒杀购物商城业务服务-分布式架构介绍 基于MySQL数据库集群技术实现服务的高可用 基于Tomcat的集群负载机制实现Tomcat服务器的高可用 基于Nginx负载均衡机制实现负载均衡(介绍和配置) ...
- ARKit：增强现实技术在美团到餐业务的实践
前言 增强现实(Augmented Reality)是一种在视觉上呈现虚拟物体与现实场景结合的技术.Apple 公司在 2017 年 6 月正式推出了 ARKit,iOS 开发者可以在这个平台上使用简 ...
- webservice入参是一个对象_程序员技术精进：面向对象与服务的分析与设计
面向对象分析与设计 面向对象分析与设计是指根据面向对象方法学对软件系统进行分析与设计.在面向对象分析与设计的定义中有三个关键词:面向对象.分析.设计.所以,为了更好地理解面向对象分析与设计的作用,我们 ...
- 如何使用 DDD 指导微服务拆分？
点击上方肉眼品世界, 右上角选择"设为星标 深度价值体系传递 开发者在刚开始尝试实现自己的微服务架构时往往会产生一系列问题 : 微服务到底应该怎么划分? 一个典型的微服务到底应该有多微? 如 ...
最新文章
- 第六篇：基于朴素贝叶斯分类算法的邮件过滤系统
- vb趣味编程弹球小游戏_最好玩的微信小游戏集合，总有一款是你没玩过的
- 成功案例_APP成功推广案例
- 【Objective-C】java中的interface与Objective-C中的interface的区别
- 武汉理工大学合肥工业大学 计算机,合工大为什么从985降到211？附合肥工业大学211地位（合工大不是985）...
- 创业失败的内因分析及避免办法
- 信息系统项目管理师学习笔记16-项目变更管理
- MySQL 全文索引 FULLTEXT INDEX
- Cython简单demo
- 大数据时代，IT行业的热门岗位有哪些？9大前景分析
- python爬取js_Python爬取javascript(js)动态网页
- 风险投资VC对ESG指标的影响
- Single Threaded Execution模式
- 信奥一本通2071题
- 企业级LNMP环境搭建
- HTTPS请求方式工具类
- beyond compare 用法
- 分布式操作系统,批处理,分时,实时操作系统
- C语言判断一个五位数是不是回文数
- 思维导图一定要用计算机来完成吗,计算机绘制思维导图的优势和趋势