Java生鲜电商平台-微服务架构概述

Java生鲜电商平台-微服务架构概述

单体架构存在的问题

在传统的软件技术架构系统中,基本上将业务功能集中在单一应用内,或者是单一进程中。尽管现代化的软件架构理论以及设计原则已推广多年,但实际技术衍化的速度迟缓并且变革动力不足。 其中的原因存在着复杂性以及多样性,我想主要的原因是没有一套整体的解决方案能够让工程师在面临稳定性风险下,毅然决然地实施系统重构。当系统应用规模随着业务的迅速发展时,系统的重要性愈发突出,开发人员将对系统的改造尤为敏感,从之前的徘徊犹豫,随之变得更加保守,只能延续过去的技术方案,将功能不断地累积在原有的系统架构上。这样的系统好比是豆腐叠罗汉,叠得越高越危险。因此,当面临巨大的服务压力时,系统不得不通过扩容的方式,来支撑应对。俗话说,“船小好调头”,“头病医头,脚病医脚”。臃肿的系统使得扩容变得毫无针对性,牵一发而动全身。由于服务运行情况存在差异性,具体哪个功能存在性能瓶颈,又因服务并非孤立而存在,使得评估结果存在着主观臆断性和不确定性,这种相互影响和作用下,使得扩容变得异常的困难,扩容无法量化,最终导致“水桶效应”。

当应用场景规模增大时,为了提高了开发以及执行的效率,并且使得更优雅或者合适的解决问题成为可能,开发人员将会评估和选择更先进的技术,推动演进。由于系统应用过分地集中了所有功能,其功能所需依赖服务以及执行库文件也随之变得庞大,当需要适配新的技术时,不仅依赖冲突难存在不确定性并且难以应付,进而使代码重构变得异常困难,增加了适配新技术的难度。

正因为功能集中于一身,让应用资源占用率变得越来越大,使得持续集成、回归测试、以及分发部署变得愈发困难。比如,应用部署包磁盘占变多,让编译、打包、分发以及启动时间变长,不确定性因素变得更大。当应用发布上线后,存在功能性缺陷,需要回滚时,这样的试错和时间成本变得更加昂贵。

越是功能集中式的系统架构,在开发工程中,越依赖于与执行环境。这种执行环境承载着数据、服务以及配置,如若其中那个环节出现问题,开发进程不得不被迫中断,而不断地诊断问题和调试环境,使得快速开发变得要不可及,更不要说在本地开发。由于对环境的过分依赖,使得系统的稳定性变得更不确定性。其一,由于服务相互依赖,而服务又依赖环境,开发人员对单元测试职业习惯以及依赖程度降低,使得测试环节减少,或者说更依赖于集成测试。其二,当测试人员在部署测试环境执行集成测试时,不但部署成功率不断地降低,而且执行过程时间不断地增加,压缩了开发时间,也可能导致项目滞后。不仅提高了系统风险,并且增加了心理负担。这么说来,无论是快速开发和测试都变得更加艰难。

以上分析还只是停留在那些熟悉业务和技术的成员,当业务快速发展时,其发展速度与开发效率比不断扩大,招募和发展新人是必不可少的手段。当面对如此巨大和复杂的系统应用时,业务和技术所需的知识变得特别杂糅,让新人有一种“独上高楼望,尽天涯路”之感,学习曲线陡峭。在实际的实施过程中,文档完整性以及指导的系统性皆存在不足。

如何解决单体架构存在的问题

单体应用给我们带来的现实问题:

  • 扩容困难(Problems in scalability )
  • 部署困难(Problems in deployment)
  • 发布回滚困难(Problems in release rollback)
  • 适配新技术困难( Problems in adopting new technologies )
  • 快速开发困难(Problems in RAD)
  • 测试困难(Problems in testing)
  • 学习困难(Problems in learning)

实际上,在解决单体应用的问题上,数年前,就出现了相应的解决方法,比如SOA的技术路线。

SOA解决一个现实的问题,那就是服务与服务之间解耦,将古老的进程内服务调用,通过网络协议转化成服务之间的调用。从早期发明了CORBA、RMI、COM+、XML-PPC等技术,不过问题也随之出现,由于这些技术绑定在某种技术或者平台,比如RMI属于Java 平台技术,COM+属于微软技术体系,XML=PRC没有统一的协议标准,因此对平台无关性的通讯需要的协议呼声强烈,这时一些典型的技术陆续出现,如WebServices以及MessageQueue。以及它们的集大成技术ESB。

其中的代表技术有:WSDL(Web Service Definition Language)、SOAP(Simple Object Access Prototol)等技术。由于这些通讯协议标准相对笨重,虽然目前仍在被广泛的使用,但逐步被淘汰是大势所趋。

为什么不选SOA而选微服务

面向服务架构(SOA) VS 微服务

类同

  • 面向服务( Service-Oriented )
  • 松耦合(Loose-Coupling)
  • 自包含(Self-Contained)
  • 平台无关性(Independent Platform)

差异

  • 原子性(Atomic)
  • 自治性(Autonomous)
  • 开发运维体系(DevOps)
  • 轻量级(Lightweight)
  • 通讯协议(Communication Protocol)

微服务是粒度小的SOA,正由于SOA体系庞大,不可能实现更好的原子性,并且它采用了统一统治的方式,例如ESB那样的大型解决方案。这样技术选型,针对单一的服务无法实现自行管理,无形之中增加了团队运维成本。开发人员不能很好的实施DevOps技术手段。同时,SOA采用了WSDL、SOAP等重量级的通讯协议,增加了开发成本以及性能损耗。在微服务中,大多数服务API通过REST的方式暴露,这样大大地降低了适配的成本。

微服务是趋势

让我们看看google和百度统计的结果吧

图片.png

图(1)Google中spring boot的搜索热度

spring boot和spring cloud是做微服务的最佳搭档。从图(1)上,我们能够看到spring boot 2013年在全球开始流行,一直到2017年2月到了100的热度。

图片.png

图(2)google中spring cloud的搜索热度

从图(2)上,我们可以看到spring cloud从2012年开始热度都是比较平和,在2015年6月之后,也就是微服务开始兴起的时候,spring cloud开始迅速增长,在2017年2月达到了100的搜索热度。(地图上没有中国,估计是因为中国被墙掉了的原因)

图(3)百度搜索中spring boot的搜索热度

图(3)是百度地图统计的结果,我们可以看到spring boot在国内是2015年6月开始流行的,2017年增长尤为突出。

图(4)百度搜索中spring cloud的搜索热度

图(4)我们可以看到,spring cloud是从2016年6月开始在中国流行,往往新技术要在中国流行,都会落后硅谷一年,看看一年前的硅谷,就是现在的中国,所以大家也就能够判断到了spring cloud在中国的发展曲线了,也就是2018年2月spring cloud在中国的热度将达到顶峰。

虽然流行并不代表你需要。但是,既然流行就有他流行的原因,就有他优点。后面我们将回来认识下微服务。

什么是微服务

微服务是用一组小服务的方式来构建一个应用,服务独立运行在不同的进程中,服务之间通过轻量的通讯机制(如RESTful接口)来交互,并且服务可以通过自动化部署方式独立部署。正因为微服务架构中,服务之间是相互独立的,所以不同的服务可以使用不同的语言来开发,或者根据业务的需求使用不同类型的数据库。

微服务架构的优点与挑战

优势

  • 服务简单,只关注一个业务功能
    传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性,其服务端应用就像是一块铁板,笨重且不可拆分,系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展,而不能针对某一个功能模块进行扩展。 而微服务架构将系统以组件化的方式分解为多个服务,服务之间相对独立且松耦合,单一功能的改变只需要重新构建部署相应的服务即可。
  • 每个微服务可由不同团队开发
    传统的开发模式在分工时往往以技术为单位,比如UI团队、服务端团队和数据库团队,这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工,不同的服务可以采用不同的技术来实现,一个团队中应该包含开发所需的所有技能,比如用户体验、数据库、项目管理。
  • 微服务是松散耦合的
    微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能,微服务架构中服务是高内聚的,每个服务都会处理相应的业务,所有的业务逻辑应该尽量在服务内部处理,且服务间的通信尽可能的轻量化,比如使用Restful的方式。
  • 可用不同的编程语言与工具开发
    传统的软件开发中经常会使用同一个技术平台来解决所有的问题,而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性,我们可以使用Node.js来开发一个简单的报表页面,使用C++来编写一个实时聊天组件。

挑战

  • 运维开销
    更多的服务也就意味着更多的运维,产品团队需要保证所有的相关服务都有完善的监控等基础设施,传统的架构开发者只需要保证一个应用正常运行,而现在却需要保证几十甚至上百道工序高效运转,这是一个艰巨的任务。
  • DevOps要求
    使用微服务架构后,开发团队需要保证一个Tomcat集群可用,保证一个数据库可用,这就意味着团队需要高品质的DevOps和自动化技术。而现在,这样的全栈式人才很少。
  • 隐式接口
    服务和服务之间通过接口来“联系”,当某一个服务更改接口格式时,可能涉及到此接口的所有服务都需要做调整。
  • 重复劳动
    在很多服务中可能都会使用到同一个功能,而这一功能点没有足够大到提供一个服务的程度,这个时候可能不同的服务团队都会单独开发这一功能,重复的业务逻辑,这违背了良好的软件工程中的很多原则。
  • 分布式系统的复杂性
    微服务通过REST API或消息来将不同的服务联系起来,这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等,而面对如此多的微服务都需要分布式时,整个产品需要有一整套完整的机制来保证各个服务可以正常运转。
  • 事务、异步、测试面临挑战
    跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案,而现在看起来,这些技术并没有成熟。

微服务设计原则

  • 隔离
    服务必须设计为单独相互隔离工作。当你将一个整体单片系统分解成一组服务时,这些服务必须彼此解耦,这样才能更加连贯和自给自足。每个服务应该能够处理其自己的故障,而不会影响或破坏整个应用程序或系统。隔离和解耦特性使服务能够非常快速地从故障状态中恢复。服务的隔离特性具有以下优点:容易采用连续交付,更好的扩展,有效的监控和可测试性。
  • 自治性
    隔离为自治性铺平了道路。 服务必须设计为自主自治的。它必须具有凝聚力,能够独立地实现其职能。每个服务可以使用良好定义的API(URI)独立调用。API以某种方式标识服务功能。自主服务还必须处理自己的数据。更流行的术语是多语言持久性,其中每个服务都有自己的持久存储。 自主还确保弹性。自主服务具有以下优点:有效的服务编排和协调,更好的扩展,通过良好定义的API进行通信,更快速和可控的部署。
  • 单一责任
    服务必须设计为高度凝聚。单一的职责(责任)原则是服务只执行一个重要的功能。 单一责任与“微观”一词很好地结合。‘微’意味着小,细粒度,只与其责任范围内相关。单一责任功能具有以下优点:服务组合无缝,更好的扩展,可重用性,可扩展性和可维护性。
  • 有界上下文
    您的服务应该有多大或小? 答案就在于所谓有界上下文设计原则。这是一个关键模式,同时是领域驱动设计(DDD)建模方法。有界的上下文是关于微服务将提供其服务功能的上下文。它根据有关领域模型和识别离散边界,并相应地设计您的微服务,使其更具凝聚力和自主性。这也意味着跨边界的通信变得更有效率,在一个有界上下文中的服务不需要依赖于另外一个有限上下文中的太多的事情了。
  • 异步通信
    在设计离散边界和使用其自己的有界上下文设计服务时,跨边界的服务通信必须是异步的。异步通信模式自然导致服务之间的松耦合,并允许更好的缩放。使用同步通信,会阻止调用并等待响应。 处于阻塞状态的服务不能执行另一个任务,直到接收到响应并释放底层线程为止。它导致网络拥塞,并影响延迟和吞吐量。异步通信还可以带来实现良好定义的集成或通信模式的概念,以实现涉及不同服务的逻辑工作流。
  • 位置独立
    根据设计,微服务是在虚拟化环境或docker容器中部署。随着云计算的出现,我们可以拥有大量可以利用动态缩放环境的服务实例。服务可以在跨小型或大型集群的多个节点上运行。服务本身可以根据底层计算资源的可用性或效率来重新定位。必须能够以位置独立的方式来寻址或定位服务。通常,可以使用不同的查找发现模式来消费使用您的服务。服务的客户端或消费者不必烦恼部署或配置特定服务的位置。它只是使用某种逻辑或虚拟地址来定位服务。

原文地址:https://www.cnblogs.com/jurendage/p/11332538.html

时间: 2024-10-12 20:56:23

Java生鲜电商平台-微服务架构概述的相关文章

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析 说明:Java生鲜电商平台中,由于服务进行了拆分,很多的业务服务导致了请求的网络延迟与性能消耗,对应的这些问题,我们应该如何进行网络请求的优化与处理呢? 到底有没有一些好的建议与方案呢? 下面这个文章将揭晓上面的问题,让你对SpringCloud微服务网络请求性能有一个全新的认识. 目录简介 01.网络请求异常分类 02.开发中注意问题 03.原始的处理方式 04.如何减少代码耦合性 05.异常统一处理步骤 06

Java生鲜电商平台-电商支付流程架构实战

Java生鲜电商平台-电商支付流程架构实战 说明:我一直秉承的就是接地气的业务架构实战.我的文章都有一个这样的核心. 1. 业务场景 2. 解决问题. 3.代码实现. 4.代码重构. 5.总结与复盘. 6.缺点与防范 一.场景描述 想必大家都曾遇到过这个问题,在电商购物的过程中,已经走到了最后一步:去支付.这个时候突然意识到商品数量不对,或者收货信息选错. 除此之外,用户还存在之下返回的原因: 误点击,也就是说用户还是想买的: 犹豫中点了返回,想买的欲望不是十分坚决: 坚决不买了. 二.可选方案

Java生鲜电商平台-生鲜售后系统的退款架构设计与代码分享

说明:任何一个电商行业都涉及到退货与退款的问题,但是生鲜电商行业还设有一个显著的特点,那就是换货.在人性面前,各种各样的退货,退款,换货的售后问题,层出不穷,那么应该如何架构与设计呢?请看下文. 由于涉及到的东西比较多,目前只讲退款的架构设计与代码分享. 退款,是一个易造成负体验的业务产品.原因是商户对于退款的要求务必退款成功.高效.快,而且又得很好地支撑业务,否则就容易招来吐槽. 退款,一个看似简单,但充满复杂性的产品. 要想做好退款系统,我们必须深入的了解业务发展趋势,将客户诉求与现状业务结

Java生鲜电商平台-电商中"再来一单"功能架构与详细设计(APP/小程序)

Java生鲜电商平台-电商中"再来一单"功能架构与详细设计(APP/小程序) 说明:在实际的业务场景中(无论是TO B还是TO C)不管是休闲食品.餐饮.水果.日用百货.母婴等高频购买行业,还是其他行业,“再来一单”都能够大大缩短买家再次下单的流程,促进转化. 于是就有了针对生鲜电商平台的“再来一单”功能,买家只要在订单列表.订单详情或者支付成功中点击“再来一单”,就可以把订单中的商品再次加入购物车,方便快捷,高效. 上面的话可以总结出来"再来一单“以下几个信息.      

Java生鲜电商平台-缓存架构实战

Java生鲜电商平台-缓存架构实战 说明:在Java生鲜电商中,缓存起到了非常重要的作用,目前整个项目中才用的是redis做分布式缓存. 缓存集群 缓存集群存在的问题 1.热key 缓存集群中的某个key瞬间被数万甚至十万的并发请求打爆. 2.大value 某个key对应的value可能有GB级的大小,导致查询value的时候导致网络相关的故障问题. 缓存集群作用 在缓存里放一些平时不怎么变动的数据,然后用户在查询大量的平时不怎么变动的数据的时候,可以直接从缓存里走了.缓存集群的并发能力是很强的

Java生鲜电商平台-电商中海量搜索ElasticSearch架构设计实战与源码解析

Java生鲜电商平台-电商中海量搜索ElasticSearch架构设计实战与源码解析 生鲜电商搜索引擎的特点 众所周知,标准的搜索引擎主要分成三个大的部分,第一步是爬虫系统,第二步是数据分析,第三步才是检索结果.首先,电商的搜索引擎并没有爬虫系统,因为所有的数据都是结构化的,一般都是微软的数据库或者 Oracle 的数据库,所以不用像百度一样用「爬虫」去不断去别的网站找内容,当然,电商其实也有自己的「爬虫」系统,一般都是抓取友商的价格,再对自己进行调整. 第二点,就是电商搜索引擎的过滤功能其实比

Java生鲜电商平台-生鲜供应链(采购管理)

Java生鲜电商平台-生鲜供应链(采购管理) 在生鲜供应链系统中采购中心这一模块,它是电商公司管理采购的模块,包含供应商管理,采购订单管理,采购商品管理,在该模块中采购订单是采购中心的核心模块.在其他的比如供应商的管理,采购商品的管理,都始终围绕着订单管理为中心进行.本文将围绕电商后台中采购中心的供应商管理,采购订单管理,采购商品管理三个模块进行讲解. 在设计电商后台尤其需考虑公司的组织架构,考虑公司的个部门之间的业务流转,在设计后台尤其需要结合公司自身的组织架构和自身的业务需求,尽量精简业务流

Java生鲜电商平台-电商订单系统全解析

Java生鲜电商平台-电商订单系统全解析 今天分享将会分为以下三个环节来阐述: 1.订单系统的介绍 2.订单系统的解构 3.垂直电商订单系统设计思路 一.什么是订单系统? 订单管理系统(OMS)是物流管理系统的一部分,通过对客户下达的订单进行管理及跟踪,动态掌握订单的进展和完成情况,提升物流过程中的作业效率,从而节省运作时间和作业成本,提高物流企业的市场竞争力.顾名思义,电商系统就是用户.平台.商户等对于订单的管控.跟踪的系统,衔接着商品中心.wms.促销系统.物流系统等,是电子商务的基础模块:

Java生鲜电商平台-电商虚拟币的充值与消费思考

Java生鲜电商平台-电商虚拟币的充值与消费思考 项目背景 最近由于项目业务原因,需要为系统设计虚拟币的充值及消费功能.公司内已经有成熟的支付网关服务,所以重点变成了如何设计项目内虚拟币的充值流程,让整个充值流程都实现幂等,确保用户的虚拟币余额不会重复增加或扣减. 商品购买及支付流程 微信支付时序图 (1)用户购买商品,商户后台请求生成支付订单并返回相关信息到客户端. (2)客户端根据返回的信息唤起支付SDK,用户确认支付. (3)用户完成支付后,支付系统会异步通知商户后台支付结果. (4)商户