logo资料库

SpringCloud微服务架构技术分享.pptx

发布时间：2022-06-15 发布人：admin 分类：说明书 资料大小：7.81M 资料格式：pptx 举报 版权申诉
第1页 / 共109页
第2页 / 共109页
第3页 / 共109页
第4页 / 共109页
第5页 / 共109页
第6页 / 共109页
第7页 / 共109页
第8页 / 共109页
资料共109页，剩余部分请下载后查看
    SpringCloud微服务架构 技术分享
    CONTENTS 01 02 单体应用架构存在的问题 主 要 介 绍 目 前 传 统 项 目 的 单 体 应 用 架 构 的 问 题 和 局 限 性 微服务架构介绍 介 绍 微 服 务 架 构 的 来 源 和 应 用 场 景 ， 以 及 传 统 项 目 往 微 服 务 架 构 的 迁 移 03 SpringCloud简介 介 绍 S p r i n g C l o u d 起 源 ， 技 术 概 述 等 04 SpringCloud常用组件 培 训 的 主 要 内 容 ， 主 要 讲 解 S p r i n g C l o u d 的 几 大 常 用 组 件 和 介 绍 其 他 组 件
    01 单体应用架构存在 的问题
    单体架构应用的困境 • 在 Java 开发中，一个典型的单体架构应用就是将一个应用中所有的功能都打 包在一个 WAR 文件中，并部署在应用服务器（如 Tomcat）中运行，如图所 示。
    单体架构应用的问题 • 1 复杂性高：当一个项目达到百万级别，整个项目包含的模块非常多、模块的 边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。整个项 目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改 一个bug都会带来隐含的缺陷。 • 2 技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技 术债务，并且越积越多。“不坏不修”，这在软件开发中非常常见，在单体应 用中，这种思想更严重。已使用的系统设计或代码难以被修改，因为应用程序 中的其他模块可能会以意料之外的方式使用它。 • 3 部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用 中，每次功能的变更或缺陷的修复都会导致重新部署整个应用。全量部署的方 式耗时长、影响范围大、风险高，这使得单体应用项目部署的频率较低。而部 署频率低又导致两次发布之间会有大量功能的变更和缺陷修复，出错概率较高。
    单体架构应用的问题 • 4 可靠性差：某个应用Bug，例如死循环、OOM等，可能导致整个应用崩溃。 • 5 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的 需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU； 有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得 不在硬件的选择上做出妥协。 • 6 阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题， 团队中的每个成员必须使用相同的开发语言和框架，要想引入新框架或新技术 平台会非常困难。例如，一个使用Struts2构建的、有百万行代码的单体应用， 如果想要换用Spring MVC，毫无疑问切换的成本是非常高的。
    02 微服务架构介绍
    微服务架构 • 在开发大型、复杂应用时我们常采用的开发方式就是模块化。这种大型应用的 开发往往一个人是无法掌控全局的，通过模块化的方式可以将应用分解成多个 具有关联的模块，并交由不同开发团队来完成。模块通过开发语言本身的机制 进行构建，比如 Java 中我们会打包成一个 JAR 文件，模块之间的调用则是直 接使用接口，依赖关系则可以使用 Maven 等工具进行管理。微服务架构中的 服务其实和之前模块化开发很相似，但服务是有明确服务边界的，所以更易于 开发和管控，同时也更易于单独部署和扩展。
    分享到：
    赞 收藏

    相关推荐

    资料库

    后端

    共收录2142份资料，累计10个分类，关注成员有19位，主要包括：Perl,Docker,Delphi,VB,PHP,Java,C,C#,Python,C++

    热门标签

    Perl Docker Delphi VB PHP Java C C# Python C++

    最新资料