• [云原生]微服务架构是什么?


    ✅作者简介:大家好,我是Philosophy7?让我们一起共同进步吧!🏆 📃个人主页:Philosophy7的csdn博客
    🔥系列专栏: 数据结构与算法
    👑哲学语录: 承认自己的无知,乃是开启智慧的大门
    💖如果觉得博主的文章还不错的话,请点赞👍+收藏⭐️+留言📝支持一下博>主哦🤞

    在这里插入图片描述

    一、为什么需要微服务架构

    新事物的产生必将会与旧事物发送冲突,而一个新事物的生命力,就是看有无发展空间,那么微服务架构也不例外。随着互联网技术的发展,传统的应用架构已经无法满足实际需求,微服务架构就随之产生。那么传统应用架构到底有什么问题呢?又如何解决呢?

    ①传统单体应用架构的问题

    通常我们使用的传统单体应用架构都是模块化的设计,程序在编写完之后会被打包并部署称一个具体的应用,而应用的格式依赖于相应的应用语言和框架。例如: 某电商项目,Web工程会被打成WAR包的形式部署在Web服务器上,而普通的Java程序则被打成一个Jar包的形式包含在WAR中。

    如图,这种是我们常见的开发风格,这样做的好处利于开发和调试,并且容易部署。在客户量不多的情况下,这种架构方式(单体应用架构)完全满足需求,但随着用户量的增加,一台服务器就满足不了,此时我们就会考虑系统的水平扩展,通常我们的解决方案就是增加服务器的数量,并将打包好的应用拷贝到不同的服务器(例如:Tomcat),通过负载均衡器(Apache、Nginx)轻松实现水平扩展。

    在这里插入图片描述

    这种架构的存在的问题如下:

    • 应用复杂度增加,更新、维护困难
      • 简单的应用随着多次更新、维护会变的庞大,应用将会变的复杂,开发团队面临多种问题,其中最主要的问题就是应用太复杂,以至于单个开发者很难进行二次开发或维护
    • 易造成系统资源浪费
      • 虽然使用负载均衡的方式跨域对项目中的服务容量进行水平扩展,但由于单体应用架构的代码中只有一个包含所有功能的WAR包,所以在对服务容量扩容的同时,只能选中重复地部署这个WAR包来扩展服务能力,而不仅仅是扩展了所需服务。
    • 影响开发效率
      • 当一个应用越大时,启动的速度会大大降低。在开发和调试中,如果有大部分的时间花费在启动上,那么会大大影响开发效率。
    • 应用可靠性低
      • 单体应用架构的可靠性较低,当某个模块产生BUG时,很可能导致整个进程崩溃,从而影响到整个应用。
    • 不利于技术的更新
      • 传统单体应用架构一旦选定了某些技术,后期的开发和扩展将在这些技术的基础上进行实现。如果需要更改某种技术,那么则很有可能会将整个应用重新开发。

    ②解决传统应用架构的问题

    针对传统单体架构的问题,大部分企业通过SOA(Service-Oritend Architecture) 面向服务的架构解决上述问题。SOA的思路就是将应用相近的功能聚合到一起,以服务的形式提供出去,因此SOA架构的应用跨域简单理解为一批服务的组合。

    • 整体的一个项目拆分成若干个子项目,不同的开发团队负责不同的子项目,提高开发效率
    • 将模块拆分,使用接口通信,降低模块间的耦合度
    • 使客户或服务消费者免于服务实现的改变所带来的影响

    虽然使用SOA解决了传统单体架构中的问题,但多数情况下,SOA中相互独立的服务仍会被部署到同一个Tomcat实例下,和单体应用架构相似,随着业务功能的增多,SOA的服务也会变的复杂。透过现象看本质,单体架构的问题仍没有得到解决。

    针对这种问题,微服务架构的架构思想也随之产生,也就是将应用分解为小的、互相连接的微服务。

    二、微服务架构是什么?

    微服务架构是一种架构风格和架构思想,它倡导我们在传统软件应用架构的基础上,将系统业务按照功能进行更加细粒度的拆分,所拆分的每一个服务都是一个独立的应用,这些应用对外提供公共的API,跨域独立承担对外服务的职责,通过这种思想开发的软件服务实体就是微服务,而围绕着微服务思想构建的一系列体系结构(开发、测试、部署等)我们将它称之为微服务架构

    ①微服务架构的优点

    • 复杂度可控
      • 更细粒度的应用拆分,不会随着时间的演变而变的复杂,每一个服务只专注于一个小功能。
    • 可独立部署
      • 由于微服务具备独立的运行进程,所以每个微服务都可以独立部署。
    • 技术选型灵活
      • 微服务架构下,技术的选型是多样化的。每个团队根据不同的需求选择最适合的技术。
    • 易于容错
      • 当某一个组件发送故障时,只会影响在一个细小的服务中,通过重试即可重新上线使用。
    • 易于扩展
      • 单个服务应用也可以实现水平扩展,这种扩展可以将整个应用完整的复杂到不同的节点中实现。
    • 功能稳定
      • 每个微服务都有自己的业务逻辑和适配器,并且只完成某个特定的功能,例如商品服务只管理商品等。

    ②微服务架构的不足

    • 开发者必须处理创建分布式系统的复杂性
      • 开发工具是面向构建传统的单体应用程序的,不为开发分布式应用程序提供全面功能上的支持(典型开发工具:Eclipse)
    • 测试更加困难。在微服务架构中,服务数量众多,每个服务都是独立的业务单元,服务之间需要通过接口进行交互。
    • 实现跨多个服务用例,需要团队之间进行仔细的协调。
    • 部署的复杂性将会大大增加,这也就意味着开发、测试、运维人员需要账务更扎实的技术
    • 增加内存消耗,微服务架构用多个服务实例取代了1个单体应用程序实例,若每个服务都运行在增加的JVM中,那么有多少个服务实例,就会有多少个实例在运行时的内存开销。

    ③微服务架构和SOA的区别

    微服务架构SOA
    一个系统被拆分成多个服务,细粒度服务由多个子系统组成,粗粒度
    团队级,自下向上开展实施企业级,自上向下开展实施
    无集中式总线,松散的服务架构企业服务总线,集中式的服务架构
    集成方式鸡蛋集成方式复杂
    服务能够独立部署服务相互依赖,无法独立部署

    三、如何构建微服务架构

    ①、微服务实例的开发

    微服务的开发可以选用Spring Boot

    ②、服务的注册和发现

    架构中服务的注册与发现功能,可选用Spring Cloud Eureka、Apache Zookeeper、Consul(国内停用)、Dubbo等

    ③、负载均衡

    负载均衡可以使用Spring Cloud Ribbon和Dubbo等

    ④、服务容错

    服务容错的技术可以使用豪猪哥(Hystrix) 在SpringCloud的子项目中包含

    ⑤、API网关

    架构中的API网关服务,使用Spring Cloud Zuul、Spring Reactor、Netty等

    ⑥、分布式配置中心

    可以使用Spring Cloud Config

    ⑦调试

    微服务应用的测试工作一般使用Swagger。Swagger是目前最受欢迎的REST API文档生成工具之一,提供了强大的页面测试功能来调试每个RESTful API

    ⑧部署

    微服务官方建议使用Docker来打包和部署微服务。Docker是一个开源的应用容器引擎,可移植性强、启动速度快,适合轻量级的应用

    在这里插入图片描述

  • 相关阅读:
    计算机毕业设计Java校园跑腿平台演示录像2020(源码+系统+mysql数据库+Lw文档)
    【校招VIP】产品项目分析之系统策划
    jQuery 遍历-后代深入解析分析【前端jQuery框架】
    MongoDB常用的比较符号和一些功能符号
    Axure学习记录(菜单下拉/收起效果)
    Ali MaxCompute SDK
    存储过程与触发器
    304-314Coderwhy-JavaScript学习教程变量的定义命名规则,练习
    会话和守护进程
    Kendo UI Grid 批量编辑使用总结
  • 原文地址:https://blog.csdn.net/ChengXuTeng/article/details/125629129