文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

如何更深入的给女朋友解释什么是微服务?

2024-12-03 10:14

关注

之前的一篇文章给大家介绍过了何为微服务:图文详解:如何给女朋友解释什么是微服务?但是身为一名积极好学的前端女朋友还是会经常问我,微服务那么多理念,你跟我讲完,我就忘了,可以再给我讲讲它的思想到底是啷个回事嘛~看在她这么刻苦奋进的情况下,加之我们公司也做了许多微服务的项目,对此还算有所研究。今天就继续为大家带来深层次的关于微服务架构的讲解:

在学习微服务之前,我们先来回顾下单体架构的模式。

单体架构

概念

单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。

特点

单体架构的特点主要有:

打包成一个独立的单元(导成一个唯一的jar包或者是war包)

以一个进程的方式来运行


单体架构

优点

缺点

维护成本大: 当应用程序的功能越来越多、团队越来越大时,沟通成本、管理成本显著增加;当出现 bug 时,可能引起 bug 的原因组合越来越多,导致分析、定位和修复的成本增加;并且在对全局功能缺乏深度理解的情况下,容易在修复 bug 时引入新的 bug。

采用过时的单体架构的话,就会使得公司雇佣有潜力的开发者很困难,应用无法扩展,可靠性很低,那么我们再来看看微服务架构是怎样的呢?

微服务架构

概念

微服务是一种架构风格。一个大型的复杂软件应用,由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并且能够很好的完成该任务。

架构核心

核心部分

架构

常见的架构有:

客户端与服务端的

基于组件模型的架构(EJB)

分层架构(MVC)

面向服务架构(SOA)

特点

系统是由多个服务构成

每个服务可以单独独立部署

每个服务之间是松耦合的。服务内部是高内聚的,外部是低耦合的。高内聚就是每个服务只关注完成一个功能。

优点

缺点

架构区别

MVC架构

MVC 架构就是一个单体架构。我们常使用的技术:Struts2、SpringMVC、Spring、Mybatis等等。

RPC 架构

RPC(RemoteProcedureCall):远程过程调用。他一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。我们常使用的技术:Thrift、Hessian等等

实现原理:首先需要有处理网络连接通讯的模块,负责连接建立、管理和消息的传输。其次需要有编解码的模块,因为网络通讯都是传输的字节码,需要将我们使用的对象序列化和反序列化。剩下的就是客户端和服务器端的部分,服务器端暴露要开放的服务接口,客户调用服务接口的一个代理实现,这个代理实现负责收集数据、编码并传输给服务器然后等待结果返回。

SOA 架构

SOA(ServiceorientedArchitecture):面向服务架构

ESB(EnterpariseServceBus):企业服务总线,服务中介。主要是提供了一个服务于服务之间的交互。ESB 包含的功能如:负载均衡,流量控制,加密处理,服务的监控,异常处理,监控告急等等。我们常使用的技术:Mule、WSO2

微服务架构

微服务就是一个轻量级的服务治理方案。我们常使用的技术:SpringCloud、dubbo等等。


架构区别

微服务原则

AKF拆分原则

业界对于可扩展的系统架构设计有一个朴素的理念,就是:通过加机器就可以解决容量和可用性问题。

这一理念在“云计算”概念疯狂流行的今天,得到了广泛的认可!对于一个规模迅速增长的系统而言,容量和性能问题当然是首当其冲的。但是随着时间的向前,系统规模的增长,除了面对性能与容量的问题外,还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。而许多系统,在架构设计时并未充分考虑到这些问题,导致系统的重构成为常态,从而影响业务交付能力,还浪费人力财力!对此,《可扩展的艺术》一书提出了一个更加系统的可扩展模型——AKF 可扩展立方(ScalabilityCube)。这个立方体中沿着三个坐标轴设置分别为:X、Y、Z。

Y 轴(功能)——关注应用中功能划分,基于不同的业务拆分

Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能,如订单管理、客户管理等。在工程上常见的方案是服务化架构(SOA)。比如对于一个电子商务平台,我们可以拆分成不同的服务,组成下面这样的架构:


服务化架构 SOA

但通过观察上图容易发现,当服务数量增多时,服务调用关系变得复杂。为系统添加一个新功能,要调用的服务数也变得不可控,由此引发了服务管理上的混乱。所以,一般情况下,需要采用服务注册的机制形成服务网关来进行服务治理。系统的架构将变成下图所示:


服务网关治理

X 轴(水平扩展)——关注水平扩展,也就是”加机器解决问题”

X 轴扩展与我们前面朴素理念是一致的,通过绝对平等地复制服务与数据,以解决容量和可用性的问题。其实就是将微服务运行多个实例,做集群加负载均衡的模式。为了提升单个服务的可用性和容量,对每一个服务进行X轴扩展划分。


X 轴(水平扩展)

Z 轴(数据分区)——关注服务和数据的优先级划分,如按地域划分

Z 轴扩展通常是指基于请求者或用户独特的需求,进行系统划分,并使得划分出来的子系统是相互隔离但又是完整的。工程领域常见的Z轴扩展有以下两种方案:

单元化架构:在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的Y轴扩展的SOA架构,客户端对服务端节点的选择一般是随机的,但是,如果在此加上Z轴扩展,那服务节点的选择将不再是随机的了,而是每个单元自成一体。如下图:


PC 用户


移动端用户

数据分区:为了性能数据安全上的考虑,我们将一个完整的数据集按一定的维度划分出不同的子集。一个分区(Shard),就是是整体数据集的一个子集。比如用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。数据分区为一般包括以下几种数据划分的方式:

前后端分离原则

何为前后端分离?前后端本来不就分离么?这要从尴尬的jsp讲起。分工精细化从来都是蛋糕做大的原则,多个领域工程师最好在不需要接触其他领域知识的情况下合作,才可能使效率越来越高,维护也会变得简单。jsp 的模板技术融合了 html 和 java 代码,使得传统 MVC 开发中的前后端在这里如胶似漆,前端做好页面,后端转成模板,发现问题再找前端,前端又看不懂 java 代码……前后端分离的目的就是将这尴尬局面打破。


前后端分离

前后端分离原则,简单来讲就是前端和后端的代码分离,我们推荐的模式是最好采用物理分离的方式部署,进一步促使更彻底的分离。如果继续直接使用服务端模板技术,如:jsp,把 java、js、html、css 都堆到一个页面里,稍微复杂一点的页面就无法维护了。


分离原则

这种分离方式有几个好处:

前后端技术分离,可以由各自的专家来对各自的领域进行优化,这样前端的用户体验优化效果更好。

分离模式下,前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了,更容易维护

前端多渠道集成场景更容易实现,后端服务无需变更,采用统一的数据和模型,可以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端

无状态服务

对于无状态服务,首先说一下什么是状态:如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务,反之称为无状态服务。


无状态服务

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态,表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务,那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明:例如我们以前在本地内存中建立的数据缓存、Session 缓存,到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点。迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。

RestFul 的通讯风格

原则来讲本来应该是个“无状态通信原则”


无状态通信

在这里我们直接推荐一个实践优选的 Restful 通信风格,因为他有很多好处:

无状态协议 HTTP,具备先天优势,扩展能力很强。例如需要安全加密,有现成的成熟方案HTTPS即可。

JSON 报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。

语言无关,各大热门语言都提供成熟的 RestfulAPI 框架,相对其他的一些 RPC 框架生态更完善。

通信

服务通信

WebService、WCF、WebAPI,以及 ASHX,ASPX。

进程通信


WebService

注册中心 Eureka

注册中心主要提供三个核心功能:

1. 服务注册

服务提供者启动时,会通过 Eureka Client 向 Eureka Server 注册信息,Eureka Server 会存储该服务的信息,Eureka Server 内部有二层缓存机制来维护整个注册表

2. 提供注册表

服务消费者在调用服务时,如果 Eureka Client 没有缓存注册表的话,会从 Eureka Server 获取最新的注册表

3. 同步状态

Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。


Eureka 流程

网关 Zuul

API 网关是一个更为智能的应用服务器,它的存在就像是整个微服务架构系统的门面,所有的外部客户端访问都需要经过它来进行调度和过滤。除了需要实现请求路由,负载均衡及校验过滤等功能外还需要与服务治理框架的结合,请求转发时的熔断机制,服务的聚合等一系列高级功能。主要核心功能:


网关

认证&授权

现在的应用开发层出不穷,基于浏览器的网页应用,基于微信的公众号、小程序,基于 IOS、Android 的 App,基于 Windows 系统的桌面应用和 UWP 应用等等,这么多种类的应用,就给应用的开发带来的挑战,我们除了分别实现各个应用外,我们还要考虑各个应用之间的交互,通用模块的提炼,其中身份的认证和授权就是每个应用必不可少的的一部分。而现在的互联网,对于信息安全要求又十分苛刻,所以一套统一的身份认证和授权就至关重要。

IdentityServer4 就是这样一个框架,IdentityServer4 是为 ASP.NET CORE 量身定制的实现了 OpenId Connect 和 OAuth2.0 协议的认证授权中间件。


IdentityServer4

分布式日志

一般我们需要进行日志分析场景:直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大也就是日志量多而复杂的场景中,此方法效率低下,面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理,所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统,将所有节点上的日志统一收集,管理,访问。

大型系统通常都是一个分布式部署的架构,不同的服务模块部署在不同的服务器上,问题出现时,大部分情况需要根据问题暴露的关键信息,定位到具体的服务器和服务模块,构建一套集中式日志系统,可以提高定位问题的效率。

Exceptionless 是一个开源的实时的日志收集框架,它可以应用在基于 ASP.NET,ASP.NET Core,Web Api,Web Forms,WPF,Console,MVC 等技术栈的应用程序中,并且提供了 Rest 接口可以应用在 Javascript,Node.js 中。它将日志收集变得简单易用并且不需要了解太多的相关技术细节及配置。在以前,我们做日志收集大多使用 Log4net,Nlog 等框架,在应用程序变得复杂并且集群的时候,可能传统的方式已经不是很好的适用了,因为收集各个日志并且分析他们将变得麻烦而且浪费时间。

现在 Exceptionless 团队给我们提供了一个更好的框架来做这件事情,我认为这是非常伟大并且有意义的,感谢他们。

ELK是三个开源软件的缩写,分别为:Elasticsearch 、 Logstash 以及 Kibana , 它们都是开源软件。不过现在还新增了一个 Beats,它是一个轻量级的日志收集处理工具(Agent),Beats 占用资源少,适合于在各个服务器上搜集日志后传输给 Logstash,官方也推荐此工具,目前由于原本的 ELK Stack 成员中加入了 Beats 工具所以已改名为 Elastic Stack,推荐使用。


ELK

配置中心 ConfigSpring

Config 首推基于 git 的管理方式,提供了两个管理维度,一个是 label(即 branch),一个是 profile。主要核心功能:


Spring Config

异步队列 MQMQ

大家都熟悉,现在主流的MQ有rabbitMQ,rocketMQ,kafka。想要了解更多关于 rabbitMQ 和 kafka 的知识可以在这两篇文章里查看:

图文详解:阿里宠儿【小兔】RabbitMQ的养成攻略

图文详解:Kafka到底有哪些秘密让我对它情有独钟呢?

核心功能:削峰填谷


流量削峰

容错限流 Hystrix

它设计用来当分布式系统发生不可避免的异常的时候去隔离当前服务和远程服务、系统、三方包的联系,防止出现级联失败的情况,从而导致整个系统雪崩。主要核心功能:


容错限流

负载均衡、服务调用

ribbon是一个负载均衡客户端,可以很好的控制htt和tcp的一些行为。

Feign默认集成了ribbon。ribbon主要功能是提供客户端的软件负载均衡算法。Ribbon就属于进程内负载均衡,它只是一个类库,集成于消费方进程,消费方通过它来获取到服务提供方的地址。主要核心功能:负载均衡


负载均衡

持续集成 Jenkins

在项目多的时候,重复操作极大的浪费时间。如果遇到同一时间不同项目组打包项目,打包和部署服务器就要排队使用,测试人员只能在等待中浪费时间。为了解决这些问题,选择寻找合适的持续集成方案。来自动化完成重复的步骤。jenkins 还包含了很多插件,比如代码校验等等。是 CI/CD 的基本技术。核心功能:


持续集成

分布式缓存 RedisRedis

是一款基于 ANSI C 语言编写的,BSD 许可的,日志型 key-value 存储组件,它的所有数据结构都存在内存中,可以用作缓存、数据库和消息中间件。核心功能:


分布式缓存 Redis

分布式事务

分布式事务的实现方式主要有:

本地消息表:MQ分布式事务—本地消息表—基于消息的一致性。


消息队列异步

分库分表 sharding jdbc

Sharding-JDBC定位为轻量级 Java 框架,在 Java 的 JDBC 层提供额外的服务,以 jar 包形式提供服务,无需额外部署和依赖,可以理解为增强版的 JDBC 驱动,完全兼容 JDBC 和各种 ORM 框架。核心功能:


Sharding-JDBC

SpringCloud

SpringCloud,从命名我们就可以知道,Spring Cloud 是大名鼎鼎的 Spring家族的产品, 专注于企业级开源框架的研发。

Spring Cloud 自从发布到现在,仍然在不断的高速发展,几乎考虑了服务治理的方方面面,开发起来非常的便利和简单。

Spring Cloud 架构

 

Spring Cloud 架构

支持协议

Spring Cloud 使用 HTTP 协议的 REST API。

Spring Cloud 组件运行

所有请求都统一通过 API 网关(Zuul)来访问内部服务。

网关接收到请求后,从注册中心(Eureka)获取可用服务。

由 Ribbon 进行均衡负载后,分发到后端的具体实例。

微服务之间通过 Feign 进行通信处理业务。


Spring Cloud 组件运行

Dubbo

Dubbo 出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过 Spring 配置的方式即可完成服务化,对于应用无入侵,设计的目的还是服务于自身的业务为主。

虽然阿里内部原因 Dubbo 曾经一度暂停维护版本,但是框架本身的成熟度以及文档的完善程度,完全能满足各大互联网公司的业务需求

Dubbo 架构


Dubbo 架构

支持协议

Dubbo 使用 RPC 通讯协议,提供序列化方式如下:

Dubbo:Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。

RMI:RMI 协议采用 JDK 标准的 java.rmi.* 实现,采用阻塞式短连接和 JDK 标准序列化方式。

Hessian:Hessian 协议用于集成 Hessian 的服务,Hessian 底层采用 HTTP 通讯,采用 Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现。

HTTP:采用 Spring 的 Http Invoker 实现。

Webservice:基于 CXF 的 frontend-simple 和 transports-http 实现。

Dubbo 组件运行

每个组件都是需要部署在单独的服务器上,Gateway 用来接受前端请求、聚合服务,并批量调用后台原子服务。每个 Service 层和单独的 DB 交互。


Dubbo 组件运行储

Gateway:前置网关,具体业务操作,Gateway 通过 Dubbo 提供的负载均衡机制自动完成。

Service:原子服务,只提供该业务相关的原子服务。

Zookeeper:原子服务注册到 ZK 上。

最后

以上就是关于微服务的一些核心知识点了,暂时就写到这里了,也是为自己做一下相关技术栈的记录,后续有时间会针对每一项技术进行仔细研究,或者通过实际项目来展示,尽量通过一个完整的项目来帮助大家更好的了解这些技术的落地应用。

 

来源:浅羽的IT小屋内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯