我的那些年(13)~主推微服务架构

回到目录

我的那些年(13)~主推微服务架构

  • 整个系统走向微服务架构
  • 网关
  • 服务注册与发现
  • 配置中心
  • 熔断器
  • 链路跟踪
  • 授权与鉴权
  • 服务间的通讯-同步feign
  • 服务间的通讯-异步消息
  • 日志收集
个系统走向微服务架构

公司系统比较多,耦合度比较大,将这些模块进行拆分,各个负责自己的模块,减少相互之间的直接依赖,版本迭代互不影响,做到最小粒度的部署,这就是微服务,也是未来软件架构与设计的一个趋势!

典型的微服务架构图

graph TD
client-->gateway
gateway-->gateway1
gateway-->gateway2
gateway1-->user
gateway1-->product
gateway1-->order

网关

网关作为整个系统的门面存在,当然一个超级大系统可能出现多个网关,而把关系比较紧密的系统通过一个网关对外提供服务,这是一种比较好的作法,对前端和用户来说,它还是一个系统,而对于后端来说,它是由多个子服务组成,我们选择的网关产品是比较流行的zuul,而springcloud2.0出来后,也推出了新的gateway组件,当然无论是使用哪个网关产品,功能都是相同的!

网关主要起到了路由,请求过滤,统一授权,限流等功能

    zuul.routes.userinfo.path=/getuser/**
    zuul.routes.userinfo.serviceId=userinfo-consumer
    zuul.ratelimit.enabled=true
    zuul.ratelimit.policies.userinfo.limit=3
    zuul.ratelimit.policies.userinfo.refresh-interval=60
    zuul.ratelimit.policies.userinfo.type=origin
    # 测试客户端如果60s内请求超过三次,服务端就抛出异常,一分钟后又可以正常请求
    # 某个IP的客户端被限流并不影响其他客户端,即API网关对每个客户端限流是相互独立的
服务注册与发现

让多个子服务进行通讯,要求这些服务在一个网络里,它们之间是可以互通的,而当服务越来越多,每个服务的端口,IP地址也会越来越繁琐,而这时服务注册组件就派上用场了,它将服务的IP和端口与一个服务名称进行映射,让开发人员只关注名称,application.name即可,而名称与真实服务的链路过程由服务注册组件实现,我们在选择服务注册组件时,选择了eureka。
eureka服务端

server:
  port: ${PORT:8761}
management:
  port: ${BG_PORT:8762}
application:
  name: ${NAME:eurekaserver}
spring:
  profiles:
    active: dev
---
eureka:
  profile: dev
  instance:
    hostname: ${application.name}
    perferIpAddress: true #基于IP地址注册
  client:
    registerWithEureka: false #false表示不向注册中心注册自己。
    fetchRegistry: false #false表示自己端就是注册中心,我的职责就是维护服务实例,并不需要去检索服务
    serviceUrl:
      defaultZone: ${URL:http://${eureka.instance.hostname}:${server.port}/eureka/}

eureka客户端注册到服务端

spring:
  application:
    name: gateway
  profiles:
    active: ${SPRING_PROFILES_ACTIVE:dev}
server:
  port: 8003

eureka:
  client:
    service-url:
      defaultZone: http://${eureka.host:localhost}:${eureka.port:6761}/eureka/,
                   http://${eureka.host:localhost}:${eureka.port:5761}/eureka/
配置中心

将所有服务的配置都集中管理,这是一个不错的想法,当配置更新后,不需要启动服务,而通过消息广播的方法通讯服务即可,这就是配置中心的作用。之前的单体应用时,每个应用都有自己的配置文件,而当项目多了之后,这些配置文件不容易管理,要修改其中一些配置时,需要分别进入对应的服务里,而且这些配置也无法实现继承,重复的代码很多,比如很多服务都用了rabbitmq,redis等,单体应用里,你需要复制这些配置到每个服务里,而有了配置中心,你只需要在application.yml里进行公用配置即可,而其它服务的配置会自动继承。

配置中心使用了加密算法保存了配置文件中的敏感信息

server.port: ${PORT:8888}
management.port: ${BG_PORT:8889}
spring:
  application.name: lind-configserver
  profiles.active: development

encrypt:
  key-store:
    location: file:///Users/lind.zhang/github/dockerDeploy/swarm/server.jks
    password: changeit
    alias: config-server-key
    secret: changeit

---
spring:
  profiles: svt
  cloud:
    config:
      server:
        git:
          uri: /config_repo

---
spring:
  profiles: development
  cloud:
    config:
      server:
        git:
uri: /config_repo
熔断器

熔断在微服务中表现非常突出,在多个服务进行并行式调用时,这个熔断功能就显得非常重要了,比如A调用B,A再调用C,A再调用D,而在这个并行调用过程中,当B出现问题时,后面的C,D将不会执行,而默认情况下A会等到B达到超时后才会做出响应,而影响A调用其它服务,从而导致A这个接口整体变慢;而有了熔断之后,当请求B接口出现问题时,你可以有很多能策略,如重试机制,快速返回等。

hystrix的基本配置,主要是对请求超时时间的配置

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
      isolation:
        strategy: SEMAPHORE #hystrix策略为thread时,threadlocal为空
        thread:
          #目前有两个容器实例,单个请求超时5s,+重试>10s,超15s则熔断
          timeoutInMilliseconds: 15000

链路跟踪

当一个服务A调用服务B时,服务B也可能会调用服务C,这就形成了一个链表,在响应时的顺序是相反的,所以这是一个双向的链表,在这个链表里,我们希望对它进行跟踪,因为在一个请求出现问题时,你很难找到问题出现在哪个环节,所以我们的请求需要有一个traceId在各个服务链表间进行传递,这就是链路跟踪的原理。

下面是链路跟踪组件sleuth和日志收集分析工具zipkin的配置

spring:
  application:
    name: user
  sleuth:
    web:
      client:
        enabled: true
    sampler:
      probability: 1.0 # 将采样比例设置为 1.0,也就是全部都需要。默认是 0.1
    zipkin:
      base-url: http://localhost:9411/ # 指定了 Zipkin 服务器的地址

下次有时间再说一下剩下的内容

  • 授权与鉴权
  • 服务间的通讯-同步feign
  • 服务间的通讯-异步消息
  • 日志收集
    回到目录

原文地址:https://www.cnblogs.com/lori/p/11199473.html

时间: 2024-11-06 22:12:09

我的那些年(13)~主推微服务架构的相关文章

个推微服务网关架构实践

作者:个推应用平台基础架构高级研发工程师 阿飞 在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求.因此,在客户端和服务端之间增加一个API网关成为多数微服务架构的必然选择. 在个推的微服务实践中,API网关也起着至关重要的作用.一方面,API网关是个推微服务体系对外的唯一入口:另一方面,API网关中实现了很多后端服务的共性需求,避免了重复建设. 个推微服务网关的设计与实现 个推微服务主要是基于Docker

开发者最佳实践日·第 13 期-实践微服务架构

随着Docker及以移动化浪潮的冲击,系统的架构与设计成为系统构建中重要环节,微服务架构这一全新的企业架构模式也越来越受到关注,使用容器技术实施微服务架构转变,如何更好的利用计算资源,以及更方便的维护越来越复杂的应用程序,微服务作为一种更灵活.可靠.开放的架构的应用实践也越来越多. 微服务架构如何让应用程序的代码库更加敏捷?如何快速迭代和扩充一个代码库并大幅提升开发者生产效率?微服务架构可以让开发团队在研发过程中更加的敏捷和灵活.想要知道更多关于微服务架构的知识,这一场沙龙你不可错过. 开发者最

个推首席架构师Qcon分享 |微服务架构的那些事儿

微服务架构需要注意哪些问题? 微服务架构,首先考虑客户端与服务端之间的通信问题.有两种解决办法,一是客户端与多个服务端直接进行通信,但存在对外暴露接口细节.众多接口协议无法统一.客户端的代码复杂.服务端升级相对困难等问题.二是客户端访问统一的API网关,由API网关调用众多服务接口,易实现统一通信协议,降低客户端和服务端代码耦合,也可以达到统一的鉴权和流控,然而此方式存在延时增加的风险,可能使API网关成为系统发展的瓶颈. 微服务架构是分布式服务架构,如何进行服务的注册和发现也是需要解决的问题.

最热门的13个Java微服务框架(内附java学习教程分享)

曾经的服务器领域有许多不同的芯片架构和操作系统,经过长期发展,Java的"一次编译,到处运行"使得它在服务器领域找到一席之地,成为程序员们的最爱 本文,我们将和大家分享13个可靠的Java微服务架构最后,如果大家如果在自学遇到困难,想找一个java的学习环境,可以加入我们的java学习圈,点击我加入吧,会节约很多时间,减少很多在学习中遇到的难题. 1.Spring Boot Java构建Spring应用程序已经有很长一段时间了,Spring Boot是Spring的一个特定版本,它通过

微服务架构实践

目录 业务背景 微服务概念 微服务技术选型 微服务架构设计 微服务架构设计落地 微服务架构设计过程中积累的心得 总结 一.业务背景 1.1 产品现状 1.各产品系统独立开发,代码复用率低,系统之间互相调用,耦合严重,系统解耦独立部署困难. 2.传统的单体架构,规模越来越大也越来越笨重:当新功能的开发.功能的重构变得不再敏捷可控:测试者的回归测试边界难以琢磨:系统的上线部署也变的艰难 3.高并发访问下无法提供可靠性服务 4.持续集成.持续部署.持续交付等工程效率化工具严重缺失 5.监控系统.日志分

微服务架构:动态配置中心搭建

版权声明:本文为博主原创文章,转载请注明出处,欢迎交流学习! 在微服务架构中,服务之间有着错综复杂的依赖关系,每个服务都有自己的依赖配置,在运行期间很多配置会根据访问流量等因素进行调整,传统的配置信息处理方式是将配置信息写入xml..properties等配置文件中,和应用一起打包,每次修改配置信息,都需要重新进行打包,效率极低,动态配置中心就是为了解决这一问题.动态配置中心也是一个微服务,我们把微服务中需要动态配置的配置文件存放在远程git私有仓库上,微服务会去服务器读取配置信息,当我们在本地

Atitit.架构设计趋势 设计模式 ---微服务架构  soa

Atitit.架构设计趋势 设计模式 ---微服务架构  soa 什么是微服务架构?1 .微服务与SOA的关系 :微服务架架构师面向服务架构(SOA)的一种特定实现1 微服务与康威定律2 微服务的一些设计 断路器 幂等2 <微服务设计>([英] 纽曼(Sam Newman))3 微服务架构与实践4 什么是微服务架构? Martin Fowler认为,微服务架构是一种独立部署的软件应用设计方式.这种架构方式没有准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上有着共性.

软件架构设计学习总结(22):软件架构——分层架构、事件驱动架构、微内核架构、微服务架构、基于空间的架构

分层架构 (Layered Architecture) 分层架构是最常见的架构,也被称为n层架构.多年以来,许多企业和公司都在他们的项目中使用这种架构,它已经几乎成为事实标准,因此被大多数架构师.开发者和软件设计者所熟知.比如MVC. 分层架构的一个特性就是 关注分离(separation of concerns) .在层中的组件只负责本层的逻辑.组件的划分很容易让它们实现自己的角色和职责,也比较容易地开发,测试管理和维护. 我们需要这样的冗余,即使业务层没有处理业务规则,也要通过业务层来调用数

《Spring Cloud与Docker微服务架构实战》配套代码

不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将代码放出. 本次放出的代码: 共计70+个DEMO 覆盖Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Bus.Spring Cloud Sleuth.Docker.Docker Compose等. 1-11章代码地址: ht