第2篇:微服务--技术生态

本文构建了微服务技术生态全景图,涵盖了接入层、服务网关、业务服务、治理服务、支撑平台、基础设施及工程交付规范。深入解析了服务网关、业务服务层、服务治理等关键组件,以及支撑平台和基础设施的角色。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

一、 微服务技术生态

接入层

服务网关

业务服务

治理服务

支撑平台

基础设施

工程交付规范


一、 微服务技术生态

 前面一篇文章,我们对微服务的基本概念,微服务带来的问题与挑战进行了描述。这篇文章我们来看看在微服务的技术生态中,用了哪些术与方案来解决这些问题

我画了一张微服务的计算生态圈地图,通过这张地图可以对微服务整体解决方案有个全局观,就像带孩子游玩动物园,如果手里拿着一张向导地图,那我们就不会错过重要的景点。当然,光凭一张图我们不可能讲明白设计原理、代码实现等这些细枝末节,针对这些每个技术细节,我们会在以后的每一篇文章中详细介绍。

我们来看下面这张图:

微服技术生态

从整体上来讲,可以将微服务体系分为几大部分,黄色部分表示的是负载均衡,绿色部分表示整个微服务,蓝色部分表示基础设施与支持平台,灰色部分表示工程交付规范。

接入层

接入层是整个系统的入口,一般都会使用到服务器负载均衡,服务器端负载均衡由包括DNS负载均衡,IP负载均衡,方向代理负载均衡,服务器端负载均衡技术并不是我们讨论的重点,我们会在其他系列的文章中介绍。

服务网关

服务网关可认为是微服务的看门人,对于服务的使用者,服务网关为其提供统一的访问地址与方式,为调用者封装了访问的细节。因此所有访问的流量都会汇聚到这里,服务网关天然成了微服务的咽喉要塞,统一服务治理等相关操作可以在这里进行处理,那真是一夫当关万夫莫开,比如限流、监控、日志,动态路由,异常处理,灰度发布,鉴权认证,也正是服务网关的重要性,服务网关有着举足轻重的地位。

业务服务

业务服务层中包含两种类型的服务,一种是基础服务,一种聚合服务,基础服务是根据业务功能进行拆分的一个独立服务组件或者公共服务,基础服务的粒度比较小,可认为是一个个的业务原子,每一个原子只关心自己的核心领域。聚合服务的作用主要是两个,第一是:聚合多个基础服务构成更复杂的业务,比如一个复杂的查询需要用的多个基础服务,第二是:适配不同的调用端,返回不同的数据,因为对于同一个业务在不同的调用端上需要的数据不一样,比如同样是商品信息PC端与App需要的数据肯定是不一样的,无论从页面大小,还是流量大小App端需要的数据更精简。

治理服务

服务治理是微服务的关键,如果没有服务治理,微服务只是一个个业务独立的远程接口,不可能构成一个稳定、可用的线上生产系统。在上面提出的那些微服务问题与挑战,通过服务治理大部分问题也都可以解决,服务治理技术构成了微服务的核心组件,这些组件包括:

服务注册与发现解决服务之间互相找到与发现的问题,隔离服务之间的IP依赖,实现服务的状态监测与管理等。

配置中心:用于管理集群中不同的环境(开发、测试、预生产、生产)配置信息,并实时动态推送配置更新到各个应  用。

熔断机制:解决服务调用链上的洪峰或异常情况,对问题进行必要的隔离,防止系统雪崩现象。

服务网关:为外部调用提供统一的入口,为微服务提供横切的功能,如:鉴权、监控、限流等。

服务监控:对于服务监控,有一个很好的比喻,在手术室或ICU病房都能看到各种各样的设备,它们把病人的各项指标数据,通过数字化的方式呈现在屏幕上,当指标发生异常还会出现警报声音,对病人状态全面的监控,让医生,家属实时了解病人的身体状况,来指导医生采取应对措施。微服务监控也是如此,无论是运维人员,开发人员,测试人员,产品经理,还是大boss,都希望通过服务监控获取他们关心的数据,所以服务监控就是他们的眼睛。

支撑平台

微服务作为一种新的架构风格,涉及的技术不仅仅是微服务组件本身,同时还需要依赖许多“衍生品”,如分布式事务、领域驱动设计,自动化,资源调度,容器化等。而支撑平台为微服务的实施提供某些基础的支撑服务,在某种意义上来说它们并不依赖与微服务而存在,但它们已脚手架的角色支撑着整个微服务大厦的构建。

基础设施

基础设施属于微服务部署运行的载体,我们可以认为是网络、存储、计算,也可以认为是实体机,虚拟机,容器等环境。对于基础设施,无论我们选择自建,托管、租用,还是使用云计算,都需综合考虑数据安全、技术风险,时间成本、投入产出比等诸多因素,同时还要考虑动态扩容,健康检查等问题。当然,基础设施的构建并不是我们要讨论的重点,我们暂且认为它就是一个黑盒子。

工程交付规范

微服务虽然强调敏捷、轻量,自治,但这并不代表我们每个人可以随心所欲,各自为政的去实施服务,必要的契约与规范是很有必要的,规范显著的减少团队沟通,协调成本,降低团队犯错的概率。所以在工程交付方面,团队遵循一套大家认同的规范尤为重要,工程交付规范自始至终贯串整个研发流程。

 

这一篇文章,我们对微服务整体技术生态做了走马观花式的介绍,目的是让我们先拿到一张关于微服务的地图,对微服务有一个整体的认识。从下篇文章开始,我们将针对这张图上的重要景点进行剖丁解牛式的分析。

内容概要:本文档详细介绍了在三台CentOS 7服务器(IP地址分别为192.168.0.157、192.168.0.158和192.168.0.159)上安装和配置Hadoop、Flink及其他大数据组件(如Hive、MySQL、Sqoop、Kafka、Zookeeper、HBase、Spark、Scala)的具体步骤。首先,文档说明了环境准备,包括配置主机名映射、SSH免密登录、JDK安装等。接着,详细描述了Hadoop集群的安装配置,包括SSH免密登录、JDK配置、Hadoop环境变量设置、HDFS和YARN配置文件修改、集群启动与测试。随后,依次介绍了MySQL、Hive、Sqoop、Kafka、Zookeeper、HBase、Spark、Scala和Flink的安装配置过程,包括解压、环境变量配置、配置文件修改、服务启动等关键步骤。最后,文档提供了每个组件的基本测试方法,确保安装成功。 适合人群:具备一定Linux基础和大数据组件基础知识的运维人员、大数据开发工程师以及系统管理员。 使用场景及目标:①为大数据平台建提供详细的安装指南,确保各组件能够顺利安装和配置;②帮助技术人员快速掌握Hadoop、Flink等大数据组件的安装与配置,提升工作效率;③适用于企业级大数据平台的建与维护,确保集群稳定运行。 其他说明:本文档不仅提供了详细的安装步骤,还涵盖了常见的配置项解释和故障排查建议。建议读者在安装过程中仔细阅读每一步骤,并根据实际情况调整配置参数。此外,文档中的命令和配置文件路径均为示例,实际操作时需根据具体环境进行适当修改。
在无线通信领域,天线阵列设计对于信号传播方向和覆盖范围的优化至关重要。本题要求设计一个广播电台的天线布局,形成特定的水平面波瓣图,即在东北方向实现最大辐射强度,在正东到正北的90°范围内辐射衰减最小且无零点;而在其余270°范围内允许出现零点,且正西和西南方向必须为零。为此,设计了一个由4个铅垂铁塔组成的阵列,各铁塔上的电流幅度相等,相位关系可自由调整,几何布置和间距不受限制。设计过程如下: 第一步:构建初级波瓣图 选取南北方向上的两个点源,间距为0.2λ(λ为电磁波波长),形成一个端射阵。通过调整相位差,使正南方向的辐射为零,计算得到初始相位差δ=252°。为了满足西南方向零辐射的要求,整体相位再偏移45°,得到初级波瓣图的表达式为E1=cos(36°cos(φ+45°)+126°)。 第二步:构建次级波瓣图 再选取一个点源位于正北方向,另一个点源位于西南方向,间距为0.4λ。调整相位差使西南方向的辐射为零,计算得到相位差δ=280°。同样整体偏移45°,得到次级波瓣图的表达式为E2=cos(72°cos(φ+45°)+140°)。 最终组合: 将初级波瓣图E1和次级波瓣图E2相乘,得到总阵的波瓣图E=E1×E2=cos(36°cos(φ+45°)+126°)×cos(72°cos(φ+45°)+140°)。通过编程实现计算并绘制波瓣图,可以看到三个阶段的波瓣图分别对应初级波瓣、次级波瓣和总波瓣,最终得到满足广播电台需求的总波瓣图。实验代码使用MATLAB编写,利用polar函数在极坐标下绘制波瓣图,并通过subplot分块显示不同阶段的波瓣图。这种设计方法体现了天线阵列设计的基本原理,即通过调整天线间的相对位置和相位关系,控制电磁波的辐射方向和强度,以满足特定的覆盖需求。这种设计在雷达、卫星通信和移动通信基站等无线通信系统中得到了广泛应用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值