掘金日本电商市场 促销择时很重要
1130
2023-03-18
本文目录一览:
微服务与SOA架构
微服务
维基上对其定义为:一种软件开发技术- 面向服务的体系结构(SOA)架构样式的一种变体,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据上下文,选择合适的语言、工具对其进行构建。
微服务概念的由来是怎么样的呢,参考维基百科英文版,简单梳理后的微服务出现的 历史 :
顺便说一句,这几个人都是大名鼎鼎的,名字可能陌生,但是摆出他们的作品,相信多少是有些了解的。 Martin Flower是《重构》、《UML 精粹》的作者;Robert Martin,人称 Bob 大叔,敏捷专家,《代码整洁之道》、《架构整洁之道》的作者。 既然微服务是SOA架构的一种变体,那么,谈微服务,SOA就是一个跨不过去的一个话题。
SOA
SOA的全称是“Service Oriented Architecture”,中文翻译是“面向服务架构”,1996年,由Gartner公司最早提出SOA概念。它的诞生是有其 历史 背景的。
同时,基于这样的背景,Gartner公司提出了SOA的概念,并且还给了一个预言,它预言在2008年,SOA会成为一种最流行的、且占有绝对优势的软件工程实践办法。
SOA架构很多时候,我们认为SOA已经消失在江湖,实际上并非如此,许多传统行业,比如物流、仓储行业的系统都是采用SOA架构来构建的。
对于SOA,从图中可以看到,它的每一项业务功能都是一个服务,都需要对外提供服务的能力,来完成企业所需的各项业务功能,也就意味着它具有对外提供开放的能力,这些能力无需定制化就可以实现。为什么无需定制化呢,核心就在于ESB。
看到ESB的功能,是不是觉得它的功能有点似曾相识?是的,它就是微服务所需要的基础服务。
微服务架构简而言之,微服务架构风格 ,是一种 将单个应用程序开发为一组小服务 的方法,每个小服务都 在自己的进程中运行并与轻量级机制(通常是 HTTP 资源 API)进行通信 。 这些服务是围绕业务能力构建的,并且 可以通过全自动部署机制独立部署 。 这些服务的集中管理最少,可以用不同的编程语言编写并使用不同的数据存储技术。
上面一段话是Martin Fowler关于微服务架构论文中的核心片段,从上述片段中,我们提炼出微服务架构的核心有三点:
其一是“ 小服务 ”,将应用拆分为一组小服务;
其二是“ 在自己的进程中运行并与轻量级机制(通常是 HTTP 资源 API)进行通信 ”,微服务是由独立进程且进程之间通过轻量级机制进行通信;
其三是“ 可以通过全自动部署机制独立部署 ”,也就是说每个微服务可以快速独立部署。
其实这已经非常精确、精准的描述出了微服务的基本特征。完全可以作为在微服务架构实践中落地的三个参考依据与检验标准。
微服务与SOA对比对比维度
微服务
SOA
举例
技术本质
Smart endpoints and dumb pipes
Smart pipes and dumb endpoints
应用场景
互联网行业
传统行业或企业内部
SOA,企业OA;微服务,电商平台
服务粒度
细
较粗
服务通信
标准化,轻量级
重量级
SOA,ESB;微服务,HTTP,RCP
服务交付
快速
较慢
微服务,服务小容易升级;SOA功能集中,较难升级
最初的应用都是单体架构,所谓单体架构就是将一系列功能全部集中在一个大的应用中,比如传统行业一般整个财务就做一个系统,将费用管理、账务管理、薪资结算等等都集中在一起,这种架构的局限性非常明显,不适合大规模项目的建设。
随着软件架构的发展,出现SOA架构,SOA将单体架构做了拆分,拆分成粗粒度的服务,同时将部分公共功能独立出来形成ESB,它的优点是
但是由于SOA架构需要一个统一的通信交互(ESB), 导致了接口开发增加工作量。
更进一步发展,微服务架构出现,对服务进一步的拆分,拆分成更细粒度的服务;进一步提供了架构选择的多样性,微服务架构主要优点是
正是因为微服务将服务拆分的更小,它同样也带来了一些挑战,比如多服务运维难度增大、服务通信成本变高、数据一致性保持更难、性能监控要求提升等等。
所以业务在选择架构的时候,应从多方面考量选择更合适的架构。
顺便说一句,这里的架构演化是指整个架构的发展 历史 ,并不是说你的服务就一定要经过这个演化过程,只是更多的架构模式提供更多的选择。我们在做架构演进的时候,更多的是将单体应用演进到SOA架构或者演进到微服务架构。
面向中小企业的微服务产品提供自动应答菜单、微网站生成与管理、***CRM系统服务、***公众平台客服服务等综合性的运营管理标准化服务,是多功能的***运营管理平台。
***管家是将企业***公众账号通过技术平台接入、运营管理等方式,帮助企业向***用户提供更完备服务信息、用户互动体验、营销效果等企业应用解决方案。
为企业客户提供基于***平台的客户服务、产品推介、互动营销、市场调查、产品订单等运营与系统功能
你好,很开心收到邀请来回答你的问题。
除了云计算、大数据和人工智能三大热门技术之外,Java被称为“编程开发的灵魂”,而微服务架构作为以Java为基础的高阶技能,同样不可忽视。
按照传统的软件开发模式,在开发项目时,通常我们会把项目创造成一个庞然大物,这个庞然大物包括一系列的小模块,比如“用户模块、订单模块、商品模块、支付模块”,一旦有模块掉了链子,整个项目都将Game Over!
为了解决这个问题,我们将一个大项目拆分成许多独立的小项目,每一个独立的小项目被称为服务。服务之间通过接口互相访问。即使某些服务挂掉,也不会影响其它服务的运行。这种项目架构称为微服务架构。
微服架构是整个互联网的框架核心,掌控了整个互联网的主心骨,一个好的架构就能搭建一个完美的互联网平台。因此,具有微服专业能力的架构师人才备受重视。
今年上半年,猎聘发布了《猎聘 2019 上半年中高端人才就业现状大数据报告》,在分领域热招数据统计中,架构师平均达到惊人的 4.28 万元,成为热门领域岗位薪资之最。
微服务架构系统灵活性,健壮性,扩展性好,特别适合需求变化迅速的场景。但系统复杂度高,部署,管理难度大。微服务除了开发期框架之外,还有需要一系列的运行期中间件支撑,如API网关,服务注册中心,统一配置中心等。 目前国内比较成熟的吧,东软有一支团队在做,他们网站是 https://platform.neusoft.com/
国内商业级RestCloud微服务架构1、作为企业API调用的统一出口和权限认证中心2、作为轻量级的企业级服务总线替换企业原有的ESB系统3、实现所有API接口的标准化、可视化、统一化管控4、作为微服务架构的核心API网关,集成到企业微服务架构中5、作为企业与供应链及合作伙伴的能力输出接口构建OpenAPI门户6、作为企业调用第三方API(京东、淘宝)等的统一API接入平台7、打通企业内部业务系统与外部业务系统之间的通道8、实现企业已有RestAPI、WebService、Dubbo、Kafka、MQTT等接口的注册和协议转换
BFF(Backend for Frontend)和网关Gateway是微服务架构中的两个重要概念电商微服务架构,这两个概念相对比较新,有些开发人员甚至是架构师都不甚理解。(伟哥一直是做前端的,第一次听师父说BFF这个问题,还以为他说错了,前端没有BFF,BFC倒是有一个🤦♂️)
本文用假想的公司案例+图示的方式,解释BFF和网关是什么,它们是怎么演化出来的。希望对架构师设计和落地微服务架构有所启发。
电商微服务架构我们先把时间推回到大致2011年左右。假设有一家有一定业务体量的电商公司CoolShop,在这个时间点它已经完成单块应用的解构拆分,内部SOA服务化已经初步完成。这个时候它的无线应用还没有起步,前端用户体验层主要是传统的服务端Web应用,总体服务化架构V1如下图所示。
时间转眼来到2012年初,国内的无线应用开始起风,CoolShop公司也紧跟市场趋势,研发自己的无线原生App。为了能尽快上线,公司的架构师提出如下V2架构,让App直接调用内部的服务:
这个架构有如下问题:
V2架构问题太多,没有开发实施。为解决上述问题,架构师经过思考决定在外部设备和内部微服务之间引入一个新的角色~Mobile BFF。
所谓BFF其实是Backend for Frontend的简称,中文翻译是为前端而开发的后端,它主要由前端团队开发(后端微服务一般由后端团队开发)。BFF可以认为是一种适配服务,将后端的微服务进行适配(主要包括聚合裁剪和格式适配等逻辑),向无线端设备暴露友好和统一的API,方便无线设备接入访问后端服务。
新的V2.1架构如下图所以:
这个架构的优势是:
V2.1架构比较成功,实施落地以后支持了CoolShop公司早期无线业务的成长。随着业务量进一步增长,投入无线研发的团队也不断增加,V2.1架构也逐渐暴露出如下问题:
为了解决上述问题,架构师经过思考决定在外部设备和内部BFF之间再引入一个新的角色~API Gateway,新的架构V3如下图所示:
新的架构V3有如下调整:
在新的V3架构中,网关承担了重要的角色,它是解耦拆分和后续升级迁移的利器。在网关的配合下,单块BFF实现了解耦拆分,各业务线团队可以独立开发和交付各自的微服务,研发效率大大提升。另外,把跨横切面逻辑从BFF剥离到网关上去以后,BFF的开发人员可以更加专注业务逻辑交付,实现了架构上的关注分离(Separation of Concerns)。
业务在不断发展,技术架构也需要不断的调整来应对需求的变化。近年,CoolShop公司技术团队又迎来了新的业务和技术需求,主要是:
为满足业务需求,架构师对服务化架构又进行了拓展升级,新的V4新架构如下图所示:
V4整体思路和V3类似,只是拓展了新的接入渠道:
V4是一个比较完整的现代微服务架构,从外到内依次分为:端用户体验层-网关层-BFF层-微服务层。整个架构层次清晰,职责分明,是一种灵活的能够支持业务不断创新的演化式架构。
原文地址: https://www.cnblogs.com/dadadechengzi/p/9373069.html
发表评论
暂时没有评论,来抢沙发吧~