Springboot+SpringCloud实战 07-第七章电子课件.ppt

《Springboot+SpringCloud实战 07-第七章电子课件.ppt》由会员分享，可在线阅读，更多相关《Springboot+SpringCloud实战 07-第七章电子课件.ppt（25页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Springboot+SpringCloud实战 07-第七章电子课件第七章 微服务架构介绍学习目标l了解单体架构、SOA以及微服务架构设计特点。l了解微服务架构的功能特点和优势。l熟悉微服务开发和传统开发的不同以及微服务数据库的挑战。随着互联网技术的迅速发展，人们对互联网产品的业务需求也不断也增加，传统的互联网产品已经无法满足广大使用者的要求与面对市场激烈的竞争压力，互联网产品往往需要更多、更琐碎复杂的业务才能满足人们多元化的互联网体验。而传统架构下的互联网产品在面对复杂烦琐的业务、项目快速部署、项目的低成本维护性以及可扩展创新性时显得力不从心。在这样的情况下，微服务架构应运而生。本章将通过

2、多方位的介绍和分析，带领读者认识微服务架构。单体架构12SOA架构3微服务架构4微服务架构的优势5微服务开发vs传统开发6微服务对数据库的挑战单体架构l单体架构介绍在互联网应用发展的早期，大部分的程序都是将Web应用所有的功能模块的表示层、业务层、数据访问层放到一起，最后通过Mevan等工具进行统一打包，并将其部署在同一台服务器上。这样的应用就是单体应用。例如，我们现在要做一个商城的项目，经过考虑和分析后我们使用Spring Boot框架来做这个项目，并且在项目初期就已经设计好了模块。单体架构上图中所示的应用，尽管也是采用模块化逻辑，但是最终它还是会被打包并部署为单体应用。例如，一些Java应

3、用会被打包为war格式，部署在Tomcat或者Jetty上；而另外一些Java应用则会被打包成jar格式并使用JDK运行。这种应用开发风格很常见，因为常见的IDE（Integrated Development Environment，集成开发环境）开发工具几乎都可以开发和打包这类单体应用。单体应用也容易部署，我们只需把要部署的war包或者jar包复制到服务器上使用Tomcat或者JDK就可以运行。在之前这类方式很受欢迎，甚至到目前也有很多这样的开发方式。单体架构l单体架构的缺陷 随着业务需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地“膨胀”。慢慢地，单体架构的应用变得越来越“臃肿”

4、，可维护性、灵活性逐渐降低，维护成本也越来越高。下面是单体架构的一些缺陷。1复杂性高 随着业务的发展、需求的变更和开发人员的更迭，整个项目包含的模块非常多，导致模块和模块的边界变得越来越模糊，依赖关系不清晰；又因为开发人员的更迭，每个人水平不一样，导致代码质量参差不齐，让有些代码变得非常混乱，使得整个项目变得非常复杂。开发人员在这样的项目中添加一个新功能或者修改代码时会小心翼翼，害怕修改之后影响其他功能模块的使用或者导致核心业务出现问题。2代码重构难度大 采用单体架构的项目往往会有很多隐藏的小问题，并且随着时间的推移会越来越多。新的开发人员可能发现了原有设计的缺陷，但是因为整个项目太大且涉及的

5、业务太多，所以也不敢轻易地修改，整个项目进行重构的代价也变得非常大。3部署效率低 单体架构虽然部署步骤简单，但是随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用，不仅耗时长、影响范围大，而且风险高。4稳定性差 应用的某个模块出现bug，如死循环、OOM（Out Of Memory，内存溢出）等，可能会导致整个应用的崩溃。5性能提升受限 单体应用都是整体部署运行的，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，需要强大的CPU（Central Processing Unit，中央处理器）处理能力；有的模块则是I

6、/O（Input/Output，输入输出）密集型的，需要更大的内存。由于这些模块部署在一起，因此不得不在硬件的选择上做出妥协。6技术创新能力低 业务复杂和庞大的单体应用，主要追求业务的正常运转，对于性能好、敏捷的新型框架不敢轻易尝试替换，替换的成本和代价也非常大。单体架构单体架构12SOA架构3微服务架构4微服务架构的优势5微服务开发vs传统开发6微服务对数据库的挑战SOA架构针对单体架构的不足，为了满足大型web应用开发和业务的需要，一些公司设计出SOA（Service-Oriented Architecture，面向服务的架构）以便于支撑软件稳定运行。SOA是一个组件模型，它将大型Web应

7、用的不同业务功能单元拆分成服务，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。SOA架构SOA将Web应用拆分成了不同的应用系统，并且通过服务中间件实现对服务的管理，可以一个服务使用独立的数据库，也可以多个服务共同使用一个数据库。可以看到，使用SOA在一定程度上弥补了一些单体架构的缺陷。下面是使用SOA的一些优势：（1）将重复的功能抽取为服务，可提高开发效率和系统的可重用性；（2）每个服务模块可以独立测试、部署，并且运行在独立的进程中；（3）可

8、以针对不同服务的特点制定集群及优化方案；（4）采用ESB（Enterprise Service Bus，企业服务总线），可以减少系统中的接口耦合等。同样地，SOA也存在一些缺陷，在SOA中系统与服务的界限依然模糊，服务接口协议不固定且种类繁多，不利于系统运营、维护；并且SOA在消息传送过程中也无法保证可靠性。单体架构12SOA架构3微服务架构4微服务架构的优势5微服务开发vs传统开发6微服务对数据库的挑战微服务架构了解了单体架构和SOA之后，我们知道了不管是单体架构还是SOA，对于模块之间的相互访问都存在一定的问题，都有可能某个模块出现问题进而影响整个系统的使用。在大数据和高并发的环境下，系统

9、架构面对更加严苛的挑战。面对这样的情况，微服务架构就诞生了。微服务的概念源于2014年3月Martin Fowler（马丁福勒）所写的一篇文章“Microservices”。他指出微服务架构是一种架构模式。他提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终功能。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的REST API，也可以采用消息队列来通信）。每个服务都围绕具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。微服务是一种架构风格，一个大型、复杂的软件的应用通常由一个或多个微服务组成。系统中的各个微

10、服务可被独立部署，各个微服务之间是低耦合的。每个微服务仅关注完成一个任务并很好地完成该任务。在所有情况下，每个任务代表一个小的业务功能。微服务架构如果我们之前的商城项目采用微服务架构设计开发的话，可以采用如图所示的微服务架构。微服务架构从图中可以看出，微服务架构中每一个模块都是单独的一个微服务，每个微服务都可以采用独立的数据库，微服务和微服务之间是低耦合的，可以通过API相互调用。开发新功能时我们只需要增加新的微服务即可，系统的可扩展性和维护性明显提高。同时微服务架构允许不同的微服务采用不同的编程语言开发，存储技术和部署方式也可以不同。当然，在企业中微服务通常使用同一种编程语言。单体架构12S

11、OA架构3微服务架构4微服务架构的优势5微服务开发vs传统开发6微服务对数据库的挑战微服务架构的优势通过对微服务架构的介绍我们发现了微服务架构的一些优势，但是微服务架构还有一些优势我们没有发现，下面我们介绍一下微服务架构的主要优势。1降低复杂度微服务架构将应用按照业务单元拆分为多个微服务，每个微服务功能单一、代码少、复杂度低。2维护性高微服务中新功能的增加或者原有功能的修改和更新不需要重新部署整个应用，只需要对单个微服务进行部署、维护即可，这样既可以保证其他模块的正常运行，也可以实现功能的添加和更新。3基础设施推进自动化业务粒度划分得越细，微服务架构拆分的微服务越多，但这样会导致其部署的次数增

12、多，增加部署的时间和难度，并且测试多个微服务也非常麻烦，因此也促进了自动化测试和自动化部署技术的发展，如Jenkins自动化部署测试技术的出现等。微服务架构的优势4稳定性好单体架构中局部出现的故障可能导致整个应用的崩溃；但是微服务系统中每个微服务都是独立的进程，如果单个微服务内部出现了问题，故障会隔离在单个微服务内不会影响其他微服务的运行。如果故障是因为微服务之间相互调用引起的，微服务提供了熔断机制，可实现服务的熔断和降级处理以保障系统的正常运行。5技术选择灵活微服务架构下，每个微服务都可以选择适合的技术栈进行开发，重构的代价也很低。6扩展能力强微服务架构可以根据应用的需求进行单一服务的功能扩

13、展。单体架构12SOA架构3微服务架构4微服务架构的优势5微服务开发vs传统开发6微服务对数据库的挑战微服务开发vs传统开发微服务开发因为与传统开发的架构体系本身的不同，所以也存在其他不同之处，如下。1分工不同传统开发是一人一个功能，微服务开发则是一人一个微服务。2架构不同传统架构技术选型少，架构一旦决定了就不容易更改。而微服务架构中，不同的微服务可以根据业务需要采用不同的架构，更加灵活。但是微服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响也很大3部署方式不同传统开发可能部署一个jar包或者war包即可。而进行微服务开发的时候，如果服务很多可能不能像传统开发那样部署，不然需要部

14、署很多次，所以脚本和自动化部署（例如，Jenkins自动部署）必不可少。4容灾不同传统开发可能因为出现一个小的问题影响整个系统的运行。微服务开发中故障屏蔽在一个微服务内，或者使用熔断机制解决微服务之间相互调用的问题，保证了系统的正常运行。5新模块开发不同传统开发中，新模块开发往往只是在项目中新创建包而已。而微服务开发中，新模块开发可以放到独立的新的微服务中。单体架构12SOA架构3微服务架构4微服务架构的优势5微服务开发vs传统开发6微服务对数据库的挑战微服务对数据库的挑战微服务设计的另外一个关键就是数据库的设计。以前的单体架构都是一个应用对应一个数据库，那么如果换成了微服务，数据库的设计应该

15、是怎么样的呢？现在主流的有3种方式。方式一：所有的微服务通用一个数据库。这种设计在微服务早期使用较多。这种设计的优点是单一数据库开发简单、开发速度快、维护操作简单；缺点是稳定性和效率都不高，并且多个微服务访问表时可能出现锁表等情况。如图展示了微服务通用一个数据库设计。微服务对数据库的挑战方式二：每一个微服务都有自己独立的数据库，并且这个数据库只能微服务自己访问，其他微服务想要访问需要调用该微服务提供的接口才可以。这种设计的优点是每个专用数据库服务于一个微服务，数据库之间互相不影响，服务简单，并且数据库可以根据微服务业务进行选型，如MySQL、Redis、MongoDB等；缺点是更多的微服务和数据库增加了运维的开销，难以实现多个微服务跨进程间的事务、异步处理和整体测试等。微服务对数据库的挑战方式三：将业务高度相关的表放到一个通用数据库中，将业务关系不是很紧密的表严格按照微服务模式来拆分并放到专用数据库中。这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现。这种设计的缺点是可能存在多个微服务调用通用数据库时可能导致锁表等缺陷。实际开发中要根据应用的实际业务去选择数据库的设计，尽可能选择最适合的数据库设计，然后使用一些其他的技术弥补缺陷。谢 谢