当前位置: 首页 > news >正文

微服务及安全

一、微服务的原理

1.什么是微服务架构

微服务架构区别于传统的单体软件架构,是一种为了适应当前互联网后台服务的「三高需求:高并发、高性能、高可用」而产生的的软件架构。

单体式应用程序

与微服务相对的另一个概念是传统的单体式应用程序( Monolithic application ),单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性,也就是相互依赖彼此,很难拆分和扩容。

单体应用程序的优点

开发简洁,功能都在单个程序内部,便于软件设计和开发规划。

容易部署,程序单一不存在分布式集群的复杂部署环境,降低了部署难度。

容易测试,没有各种复杂的服务调用关系,都是内部调用方便测试。

单体应用程序的缺点

单体程序的缺点一开始不是特别明显,项目刚开始需求少,业务逻辑简单,写代码一时爽,一直爽。噩梦从业务迭代更新,系统日益庞大开始,前期的爽没有了,取而代之的是软件维护和迭代更新的无尽痛苦。

由于单体式应用程序就像一个大型容器一样,里面放置了许多服务,且他们都是密不可分的,这导致应用程序在扩展时必须以「应用程序」为单位。

当里面有个业务模块负载过高时,并不能够单独扩展该服务,必须扩展整个应用程序(就是这么霸道),这可能导致额外的资源浪费。

此外,单体式应用程序由于服务之间的紧密度、相依性过高,这将导致测试、升级有所困难,且开发曲线有可能会在后期大幅度地上升,令开发不易。相较之下「微服务架构」能够解决这个问题。

2.微服务特点

微服务 (Microservices) 就是一些协同工作小而自治的服务。

2014年,Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的行程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力,服务可以用不同的编程语言与数据库等组件实现

微服务的优点:

1)技术异构性

不同服务内部的开发技术可以不一致,你可以用java来开发helloworld服务A,用golang来开发helloworld服务B,大家再也不用为哪种语言是世界上最好的语言而争论不休。

隔离性

一个服务不可用不会导致另一个服务也瘫痪,因为各个服务是相互独立和自治的系统。这在单体应用程序中是做不到的,单体应用程序中某个模块瘫痪,必将导致整个系统不可用,当然,单体程序也可以在不同机器上部署同样的程序来实现备份,不过,同样存在上面说的资源浪费问题。

2)可扩展性

庞大的单体服务如果出现性能瓶颈只能对软件整体进行扩展,可能真正影响性能的只是其中一个很小的模块,我们也不得不付出升级整个应用的代价。这在微服务架构中得到了改善,你可以只对那些影响性能的服务做扩展升级,这样对症下药的效果是很好的。

3)简化部署

如果你的服务是一个超大的单体服务,有几百万行代码,即使修改了几行代码也要重新编译整个应用,这显然是非常繁琐的,而且软件变更带来的不确定性非常高,软件部署的影响也非常大。在微服务架构中,各个服务的部署是独立的,如果真出了问题也只是影响单个服务,可以快速回滚版本解决。

4)易优化

微服务架构中单个服务的代码量不会很大,这样当你需要重构或者优化这部分服务的时候,就会容易很多,毕竟,代码量越少意味着代码改动带来的影响越可控。

5)服务注册与发现

微服务之间相互调用完成整体业务功能,如何在众多微服务中找到正确的目标服务地址,这就是所谓「服务发现」功能。

常用的做法是服务提供方启动的时候把自己的地址上报给「服务注册中心」,这就是「服务注册」。服务调用方「订阅」服务变更「通知」,动态的接收服务注册中心推送的服务地址列表,以后想找哪个服务直接发给他就可以。

6)服务监控

单体程序的监控运维还好说,大型微服务架构的服务运维是一大挑战。服务运维人员需要实时的掌握服务运行中的各种状态,最好有个控制面板能看到服务的内存使用率、调用次数、健康状况等信息。

这就需要我们有一套完备的服务监控体系,包括拓扑关系、监控(Metrics)、日志监控(Logging)、调用追踪(Trace)、告警通知、健康检查等,防患于未然。

7)服务容错

任何服务都不能保证100%不出问题,生产环境复杂多变,服务运行过程中不可避免的发生各种故障(宕机、过载等等),工程师能够做的是在故障发生时尽可能降低影响范围、尽快恢复正常服务。

程序员为此避免被祭天,需要引入「熔断、隔离、限流和降级、超时机制」等「服务容错」机制来保证服务持续可用性。

8)服务安全

有些服务的敏感数据存在安全问题,「服务安全」就是对敏感服务采用安全鉴权机制,对服务的访问需要进行相应的身份验证和授权,防止数据泄露的风险,安全是一个长久的话题,在微服务中也有很多工作要做。

9)服务治理

说到「治理」一般都是有问题才需要治理,我们平常说环境治理、污染治理一个意思

http://www.lryc.cn/news/428940.html

相关文章:

  • 图文详解ThreadLocal:原理、结构与内存泄漏解析
  • 基于java的综合小区管理系统论文.doc
  • 如何合理设置PostgreSQL的`max_connections`参数
  • Kubectl 常用命令汇总大全
  • 【Linux】Linux环境基础开发工具使用之Linux调试器-gdb使用
  • clickhouse_driver
  • BI分析实操案例分享:零售企业如何利用BI工具对销售数据进行分析?
  • python : Requests请求库入门使用指南 + 简单爬取豆瓣影评
  • 宋红康JVM调优思维导图
  • linux 网卡配置
  • IEEE |第五届机器学习与计算机应用国际学术会议(ICMLCA 2024)
  • 【网络安全】漏洞挖掘:IDOR实例
  • vue项目执行 cnpm install 报错证书过期的解决方案
  • XGboost的安装与使用
  • 【AI趋势9】开源普惠
  • 【Spark集群部署系列一】Spark local模式介绍和搭建以及使用(内含Linux安装Anaconda)
  • 泛微OA 常用数据库表
  • 宜佰丰超市进销存管理系统
  • 生成Vue脚手架报错:npm error code ETIMEDOUT
  • Readiness Probe可以解决应用启动慢造成访问异常的问题。
  • 第一批AI原住民开始变现:9岁小学生,用大模型写书赚1个w
  • 电路笔记(PCB):串扰的原理与减少串扰的几种方法
  • QT-监测文件内容重复工具)
  • 振兴杯全国青年职业技能大赛信息通信网络线务员解决方案
  • Ai音频文件转文字工具 会议音频转文字 录音转文字提取工具 下载
  • 深入理解Spring Boot日志框架与配置
  • WPF——动态排名图表实现
  • reactive() 的局限性
  • stm32f407vet6驱动3.2寸lcd(9341 FSMC hal)
  • 替换后的最长重复字符(LeetCode)