Spring-cloud微服务实战【一】:微服务的概念与演进过程

本文是一个系列文章,主要讲述使用spring-cloud进行微服务开发的实战。在开始之前,我们先说一下从传统的单一部署架构到微服务的发展过程,以便让童鞋们更好的理解微服务的概念与演进过程。

1.单体架构
  在互联网时代早期,彼时还没有微服务的概念,企业开发应用,将所有功能都集中到一个应用中,典型的特征是tomcat + servlet + jsp + mysql,然后将应用打包成一个war包发布。
![file](https://img2018.cnblogs.com/blog/1924225/202001/1924225-20200117235922641-1737768961.jpg)

2.集群架构
  随着时间的推移,用户数量越来越多,访问量越来越大,单体架构已经无法满足需求,此时,企业使用多台服务器集群部署的方式,通过横向复制来解决该问题。
![file](https://img2018.cnblogs.com/blog/1924225/202001/1924225-20200117235922865-1915869226.jpg)

3.分布式应用(垂直架构)
  随着业务量继续增大,集群部署带来的性能提升越来越小,集群架构已经无法满足需求,此时分布式应用应运而生:将单个应用拆分为几个互不相关独立运行的应用,但是应用之间可能会有数据冗余。比如商品应用中有用户模块,订单应用中也有用户模块,他们的用户数据和用户应用中的用户数据是相同的,导致了应用间的数据冗余。
![file](https://img2018.cnblogs.com/blog/1924225/202001/1924225-20200117235923112-748620340.jpg)

4.微服务架构(SOA)
  为了解决上面的分布式应用中数据冗余的问题,SOA架构应运而生:面向服务架构。所谓面向服务:即从服务的角度来拆分应用,比如一个完整的电商,可能会拆分为用户服务、商品服务、订单服务、库存服务、物流服务等等,每个服务的业务划分边界清晰,和其他服务没有重合,也就不存在数据冗余的情况,服务与服务之间采用RPC或者HTTP方式进行通信。SOA可以认为是一种设计思想,而微服务是一种将该思想落地的一种方式,比如spring cloud。具体什么是微服务?业界没有统一的定义,一般认为微服务架构是一种将单体应用拆分为一组互相独立运行的应用的方法,应用之间一般通过轻量级通讯机制进行通信(一般是HTTP方式)。

5.为什么需要微服务?
要回答这个问题,首先要了解单体架构的应用有什么问题。

单体应用的问题:
1.复杂性高,模块与模块之间的边界划分模糊,修改代码困难,每一行代码都可能以一种你意想不到的方式被其他代码引用。
2.代码可读性、可维护性差。由于所有代码都耦合到一起,模块众多,代码量大,对代码的可读性和可维护性带来的极大的困难。
3.技术替换成本高,假如想换其他的实现方式,或者换一种语言来实现,只能全部重来,无法局部替换。
4.部署风险高,每个小改动都会导致整个应用的重新部署,部署后的线上缺陷以及回滚操作都不可控。

针对以上缺点,即可总结我们为什么需要微服务:
1.微服务架构中的每一个应用都是独立的应用,应用的边界清晰,功能职责单一,不会出现应用间的模块或者数据冗余。
2.由于每个应用的职责单一,因此代码量相对较小,代码的可读性以及可维护性都会很好。
3.技术替换成本低,比如我的订单服务可以使用JAVA应用,我的库存服务可以是Python应用,而我的物流服务可能是Nodejs应用,应用间不需要保持开发语言一致,可灵活选型。
4.部署风险低,某一个应用挂掉不会导致整个应用挂掉(当然要求服务提供方和消费方都做好服务降级和熔断),一个应用的部署也不会影响其他应用,并且这种方式能满足现代互联网快速迭代的需求。

当然,微服务也不是没有缺点:
1.首先微服务的调用链路长,因此针对这种很长的链路调用排查线上问题就变得尤为困难,此时,对微服务中的每个应用的监控就显得尤为重要。
2.微服务众多,服务间的调用关系--即服务治理成本较高。
3.微服务的技术成本更高(分布式缓存,分布式事务,分布式一致性等问题)。

了解了微服务的一些概念,就让我们一起开始微服务的实战吧!下一篇,敬请期待!
> 本文由博客一文多发平台 [OpenWrite](https://openwrite.cn?from=article_bottom) 发布!

原文地址:https://www.cnblogs.com/wukongbubai/p/12207964.html

时间: 2024-11-10 01:57:34

Spring-cloud微服务实战【一】:微服务的概念与演进过程的相关文章

Spring Cloud微服务实战-服务治理(Spring Cloud Eureka)

1. Spring Cloud Eureka简介 Spring Cloud Eureka主要用来完成微服务中的服务治理.是基于Netflix Eureka做的二次封装,Spring Cloud通过为Eureka增加了Spring Boot风格的自动化配置,我们只需要通过引入依赖和注解配置就能让Spring Boot构建的微服务应用轻松地与Eureka服务治理体系进行整合. 2. 服务治理背景 在微服务开发工程中,整个系统微服务应用非常多,并且随着业务的发展,微服务的数量在不断增加.而微服务之间的

Spring Cloud(Dalston.SR5)--Zuul 网关-微服务集群

通过 url 映射的方式来实现 zuul 的转发有局限性,比如每增加一个服务就需要配置一条内容,另外后端的服务如果是动态来提供,就不能采用这种方案来配置了.实际上在实现微服务架构时,服务名与服务实例地址的关系在 eureka server 中已经存在了,所以只需要将Zuul注册到 eureka server上去发现其他服务,就可以实现对 serviceId 的映射,并且启用了 eureka server 同时也会启用 ribbon 对服务进行负载均衡调用,加入 Zuul 到微服务集群架构图如下:

PK1648-Spring Cloud微服务实战视频

对接真实数据 从0开发前后端分离企业级上线项目 新年伊始,学习要趁早,点滴记录,学习就是进步! 随笔背景:在很多时候,很多入门不久的朋友都会问我:我是从其他语言转到程序开发的,有没有一些基础性的资料给我们学习学习呢,你的框架感觉一下太大了,希望有个循序渐进的教程或者视频来学习就好了.对于学习有困难不知道如何提升自己可以加扣:1225462853  获取资料. 下载地址:https://pan.baidu.com/s/1hsZVk4c 课程目标 Spring Cloud实战微服务.国内第一个Spr

关于Spring Cloud大型互联网分布式企业微服务云架构

第一篇文章简单给大家介绍了Spring Cloud架构,我这边结合了当前大部分企业的通用需求,包括技术的选型比较严格.苛刻,不仅要用业界最流行的技术,还要和国际接轨,在未来的5~10年内不能out.作为公司的架构师,也要有一种放眼世界的眼光,不仅要给公司做好的技术选型,而且还要快速响应企业的业务需求,能够为企业快速定制化业务.以下是我为公司规划的大型互联网分布式企业微服务云架构:欢迎大家和我一同来搭建大型互联网分布式企业微服务云架构,我会把搭建架构的详细步骤记录下来,作为以后大家学习参考的资料,

SpringCloud(10)使用Spring Cloud OAuth2和JWT保护微服务

采用Spring Security AOuth2 和 JWT 的方式,避免每次请求都需要远程调度 Uaa 服务.采用Spring Security OAuth2 和 JWT 的方式,Uaa 服务只验证一次,返回JWT.返回的 JWT 包含了用户的所有信息,包括权限信息. 1.什么是JWT? JSON Web Token(JWT)是一种开放的标准(RFC 7519),JWT定义了一种紧凑且自包含的标准,该标准旨在将各个主体的信息包装为 JSON 对象.主体信息是通过数字签名进行加密和验证的.常使用

用Spring Cloud OAuth2和JWT保护微服务

采用Spring Security AOuth2 和 JWT 的方式,避免每次请求都需要远程调度 Uaa 服务.采用Spring Security OAuth2 和 JWT 的方式,Uaa 服务只验证一次,返回JWT.返回的 JWT 包含了用户的所有信息,包括权限信息. 1.什么是JWT?# JSON Web Token(JWT)是一种开放的标准(RFC 7519),JWT定义了一种紧凑且自包含的标准,该标准旨在将各个主体的信息包装为 JSON 对象.主体信息是通过数字签名进行加密和验证的.常使

你离 精通微服务 只差一个阿里资深架构师整理的微服务实战文档

前言 什么是微服务 在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是"微".什么是"服务", 微,狭义来讲就是体积小.著名的"2 pizza 团队"很好的诠释了这一解释(2 pizza 团队最早是亚马逊 CEO Bezos提出来的,意思是说单个服务的设计,所有参与人从设计.开发.测试.运维所有人加起来 只需要2个披萨就够了 ). 而所谓服务,一定要区别于系统,服务一个或者一组相对较小且独立的功能单元,是用户可以

微服务实战(二):落地微服务架构到直销系统(构建消息总线框架接口)

从上一篇文章大家可以看出,实现一个自己的消息总线框架是非常重要的内容,消息总线可以将界限上下文之间进行解耦,也可以为大并发访问提供必要的支持. 消息总线的作用: 1.界限上下文解耦:在DDD第一波文章中,当更新了订单信息后,我们通过调用经销商界限上下文的领域模型和仓储,进行了经销商信息的更新,这造成了耦合.通过一个消息总线,可以在订单界限上下文的WebApi服务(来源微服务-生产者)更新了订单信息后,发布一个事件消息到消息总线的某个队列中,经销商界限上下文的WebApi服务(消费者)订阅这个事件

微服务实战(四):落地微服务架构到直销系统(将生产者与消费者接入消息总线)

前一篇文章我们已经完成了基于RabbitMq实现的的消息总线,这篇文章就来看看生产者(订单微服务)与消费者(经销商微服务)如何接入消息总线实现消息的发送与消息的接收处理. 定义需要发送的消息: 下单消息要被发送到消息总线,并被经销商微服务的处理器处理.经销商微服务处理时,需要知道要对哪个经销商处理多少的PV值与电子币余额.这些信息就是事件消息需要承载的重要信息. public class OrderCreatedProcessDealerEvent:BaseEvent { public deci