请选择 进入手机版 | 继续访问电脑版

登录  | 立即注册

游客您好!登录后享受更多精彩

查看: 8392|回复: 6

erueka

[复制链接]

23

主题

44

帖子

520

积分

高级会员

Rank: 4

积分
520
发表于 2020-1-27 14:58:33 | 显示全部楼层 |阅读模式
什么是微服务架构

一、微服务架构介绍

微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的
类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
**概念:**把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议。
**定义:**围绕业务领域组件来创建应用,这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能,使产品交付变得更加简单。
**本质:**用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
二、出现和发展

微服务(Microservice)这个概念是2012年出现的,作为加快Web和移动应用程序开发进程的一种方法,2014年开始受到各方的关注,而2015年,可以说是微服务的元年;
越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践,可以说这样更近一步推动了微服务的发展和创新。而微服务的流行,Martin Fowler功不可没。
这老头是个奇人,特别擅长抽象归纳和制造概念。特别是微服务这种新生的名词,都有一个特点:一解释就懂,一问就不知,一讨论就打架。
Martin Fowler是国际著名的OO专家,敏捷开发方法的创始人之一,现为ThoughtWorks公司的首
席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面,都是世界顶级的
专家,现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集
成的公司。早在20世纪80年代,Fowler就是使用对象技术构建多层企业应用的倡导者,他著有几
本经典书籍: 《企业应用架构模式》、《UML精粹》和《重构》等。
​                                                                                              ———— 百度百科
三、传统开发模式和微服务的区别

先来看看传统的web开发方式,通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的,这种方式一般被称为Monolithic(单体式开发)。
所有的功能打包在一个 WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了 DO/DAO,Service,UI等所有逻辑。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mPiLOhxd-1579926999313)(img/4726153-009f725b57357698.webp)]
优点:

①开发简单,集中式管理
②基本不会重复开发
③功能都在本地,没有分布式的管理和调用消耗
缺点:

1、效率低:开发都在同一个项目改代码,相互等待,冲突不断
2、维护难:代码功功能耦合在一起,新人不知道何从下手
3、不灵活:构建时间长,任何小修改都要重构整个项目,耗时
4、稳定性差:一个微小的问题,都可能导致整个应用挂掉
5、扩展性不够:无法满足高并发下的业务需求
常见的系统架构遵循的三个标准和业务驱动力:
1、提高敏捷性:及时响应业务需求,促进企业发展
2、提升用户体验:提升用户体验,减少用户流失
3、降低成本:降低增加产品、客户或业务方案的成本
基于微服务架构的设计:
**目的:**有效的拆分应用,实现敏捷开发和部署
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YzciAr3c-1579926999314)(img/4726153-b47826c5bbc45cba.webp)]
四、微服务的具体特征

官方的定义:
1、一些列的独立的服务共同组成系统
2、单独部署,跑在自己的进程中
3、每个服务为独立的业务开发
4、分布式管理
5、非常强调隔离性
大概的标准:
1、分布式服务组成的系统
2、按照业务,而不是技术来划分组织
3、做有生命的产品而不是项目
4、强服务个体和弱通信( Smart endpoints and dumb pipes )
5、自动化运维( DevOps )
6、高度容错性
7、快速演化和迭代
五、怎么具体实践微服务

要实际的应用微服务,需要解决一下四点问题:
1、客户端如何访问这些服务
2、每个服务之间如何通信
3、如此多的服务,如何实现?
4、服务挂了,如何解决?(备份方案,应急处理机制)
1、客户端如何访问这些服务

原来的Monolithic方式开发,所有的服务都是本地的,UI可以直接调用,现在按功能拆分成独立的服务,跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的?
后台有N个服务,前台就需要记住管理N个服务,一个服务下线/更新/升级,前台就要重新部署,这明显不服务我们 拆分的理念,特别当前台是移动应用的时候,通常业务变化的节奏更快。
另外,N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部,通常是无 状态的,用户登录信息和权限管理最好有一个统一的地方维护管理(OAuth)。
所以,一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway,他的作用包括:
① 提供统一服务入口,让微服务对前台透明
② 聚合后台的服务,节省流量,提升性能
③ 提供安全,过滤,流控等API管理功能
其实这个API Gateway可以有很多广义的实现办法,可以是一个软硬一体的盒子,也可以是一个简单的MVC框架,甚至是一个Node.js的服务端。他们最重要的作 用是为前台(通常是
移动应用)提供后台服务的聚合,提供一个统一的服务出口,解除他们之间的耦合,不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
用过Taobao Open Platform(淘宝开放平台)的就能很容易的体会,TAO就是这个API Gateway。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HMWYOmMR-1579926999315)(img/4726153-64fdf0da5ac64646.png)]
2、每个服务之间如何通信

所有的微服务都是独立的Java进程跑在独立的虚拟机上,所以服务间的通信就是IPC(inter process communication),已经有很多成熟的方案。现在基本最通用的有两种方式:
同步调用:
①REST(JAX-RS,Spring Boot)
②RPC(Thrift, Dubbo)
异步消息调用(Kafka, Notify, MetaQ)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m3phEYJP-1579926999315)(img/4726153-68e67df42a5d099e.webp)]
同步和异步的区别:
一般同步调用比较简单,一致性强,但是容易出调用问题,性能体验上也会差些,特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。
一般REST基于HTTP,更容易实现,更容易被接受,服务端实现技术也更灵活些,各个语言都能支持,同时能跨客户端,对客户端没有特殊的要求,只要封装了HTTP的
SDK就能调用,所以相对使用的广一些。RPC也有自己的优点,传输协议更高效,安全更可控,特别在一个公司内部,如果有统一个 的开发规范和统一的服务框架时,
他的开发效率优势更明显些。就看各自的技术积累实际条件,自己的选择了。
而异步消息的方式在分布式系统中有特别广泛的应用,他既能减低调用服务之间的耦合,又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方,同时能保证调用方的
服务体验,继续干自己该干的活,不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱,需要接受数据最终一致性;还有就是后台服务一般要 实现幂等性, 因为消息
发送出于性能的考虑一般会有重复(保证消息的被收到且仅收到一次对性能是很大的考验);最后就是必须引入一个独立的broker,如果公司内部没有技 术积累,
对broker分布式管理也是一个很大的挑战。
3、如此多的服务,如何实现?

在微服务架构中,一般每一个服务都是有多个拷贝,来做负载均衡。一个服务随时可能下线,也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知?服务如何管理?
这就是服务发现的问题了。一般有两类做法,也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时,服务提供者将自己的服务信息
注册到ZK(或类似框架),并通过心跳维持长链接,实时更新链接信息。服务调用者通过ZK寻址,根据可定制算法, 找到一个服务,还可以将服务信息缓存在本地以提高性能。
当服务下线时,ZK会发通知给服务客户端。
**客户端做:**优点是架构简单,扩展灵活,只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址,有技术难度,一般大公司都有成熟的内部框架支持,比如Dubbo。
**服务端做:**优点是简单,所有服务对于前台调用方透明,一般在小公司在云服务上部署的应用采用的比较多
4、服务挂了,如何解决

前面提到,Monolithic方式开发一个很大的风险是,把所有鸡蛋放在一个篮子里,一荣俱荣,一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险,
不过如果没有特别的保障,结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候,我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多:
①重试机制
②限流
③熔断机制
④负载均衡
⑤降级(本地缓存)
这些方法基本都很明确通用,比如Netflix的Hystrix
六、思考:意识的转变

微服务对我们的思考,更多的是思维上的转变。对于微服务架构:技术上不是问题,意识比工具重要。
关于微服务的几点设计出发点:
1、应用程序的核心是业务逻辑,按照业务或客户需求组织资源(这是最难的)
2、做有生命的产品,而不是项目
3、头狼战队,全栈化
4、后台服务贯彻Single Responsibility Principle(单一职责原则)
5、VM->Docker (to PE)
6、DevOps (to PE)
同时,对于开发同学,有这么多的中间件和强大的PE支持固然是好事,我们也需要深入去了解这些中间件背后的原理,知其然知其所以然,在有限的技术资源如何通过开源技术实施微服务?
最后,一般提到微服务都离不开DevOps和Docker,理解**微服务架构是核心,devops和docker是工具,是手段。
Eureka Feign 服务治理

创建Maven的父子结构
  1.                  org.springframework.boot        spring-boot-starter-parent        2.0.3.RELEASE                        UTF-8        UTF-8        1.8        1.8                                            org.springframework.cloud                spring-cloud-dependencies                Finchley.RELEASE                pom                import                                        org.projectlombok                lombok                1.16.22                provided                                        io.springfox                springfox-swagger2                2.9.2                                        io.springfox                springfox-swagger-ui                2.9.2                                        redis.clients                jedis                2.9.0                                        org.elasticsearch                elasticsearch                6.5.0                                        org.elasticsearch.client                elasticsearch-rest-high-level-client                6.5.1                                        com.alibaba                fastjson                1.2.54                                        org.mybatis.spring.boot                mybatis-spring-boot-starter                2.0.0                                        org.apache.shiro                shiro-spring                1.4.0                                        com.github.pagehelper                pagehelper-spring-boot-starter                1.2.10                                        com.sun.mail                javax.mail                1.5.4                                         org.quartz-scheduler                quartz                2.2.3                        
复制代码
1 Eureka注册中心

1.1 需求分析

​         在前后端分离架构中,服务层被拆分成了很多的微服务,微服务的信息如何管理?Spring Cloud中提供服务注册中心来管理微服务信息。
为什么 要用注册中心?
1、微服务数量众多,要进行远程调用就需要知道服务端的ip地址和端口,注册中心帮助我们管理这些服务的ip和端口。
2、微服务会实时上报自己的状态,注册中心统一管理这些微服务的状态,将存在问题的服务踢出服务列表,客户端获取到可用的服务进行调用。
1.3 Eureka注册中心

1.3.1 Eureka介绍

​        Spring Cloud Eureka 是对Netflix公司的Eureka的二次封装,它实现了服务治理的功能,Spring Cloud Eureka提供服务端与客户端,服务端即是Eureka服务注册中心,客户端完成微服务向Eureka服务的注册与发现。服务端和客户端均采用Java语言编写。下图显示了Eureka Server与Eureka Client的关系:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xKw6Jq5s-1579926999315)(img\1529906349402.png)]
1、Eureka Server是服务端,负责管理各各微服务结点的信息和状态。
2、在微服务上部署Eureka Client程序,远程访问Eureka Server将自己注册在Eureka Server。
3、微服务需要调用另一个微服务时从Eureka Server中获取服务调用地址,进行远程调用。
1.3.2 Eureka Server搭建

1、创建openapi-eureka工程:
包结构:com.qianfeng.openapi.eureka
2、添加依赖
  1.                            org.springframework.cloud   spring-cloud-starter-netflix-eureka-server        
复制代码
3、启动类
  1. @SpringBootApplication@EnableEurekaServer//开启eurekaserver,会自动帮我们配置public class EurekaApplication {    public static void main (String[] args){        SpringApplication.run(EurekaApplication.class,args);    }}
复制代码
4、@EnableEurekaServer
需要在启动类上用@EnableEurekaServer标识此服务为Eureka服务
5 application.yml的配置内容如下
  1. server:  port: 8000spring:  application:    name: eureka-servereureka:  client:    # 表示是否将自己注册到Eureka Server,默认为true。    register-with-eureka: false    # 表示是否从Eureka Server获取注册信息,默认为true。    fetch-registry: false    # 设置与Eureka Server交互的地址,查询服务和注册服务都需要依赖这个地址。默认是http://localhost:8000/eureka ;多个地址可使用,分隔    service-url:      defaultZone: http://localhost:8000/eureka/  server:    eviction-interval-timer-in-ms: 1000     # 续期时间,即扫描失效服务的间隔时间(单位毫秒,默认是60*1000)测试时关闭自我保护机制,保证不可用服务及时踢出    enableSelfPreservation: false    # 设为false,关闭自我保护
复制代码
registerWithEureka:被其它服务调用时需向Eureka注册
fetchRegistry:需要从Eureka中查找要调用的目标服务时需要设置为true
serviceUrl.defaultZone 配置上报Eureka服务地址高可用状态配置对方的地址,单机状态配置自己
enable-self-preservation:自保护设置,下边有介绍。
eviction-interval-timer-in-ms:清理失效结点的间隔,在这个时间段内如果没有收到该结点的上报则将结点从服务列表中剔除。
5、启动Eureka Server
启动Eureka Server,浏览8000端口
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C86IVmfN-1579926999315)(img/1561683746128.png)]
1.3.3 服务注册

1.3.3.1 将 test-client1 注册到Eureka Server

下边实现test-client1向Eureka Server注册。
1、在test-client1 服务中添加依赖
  1.      org.springframework.cloud    spring-cloud-starter-netflix-eureka-client      org.springframework.boot     spring-boot-starter-web         org.springframework.boot      spring-boot-starter-test      test  
复制代码
2、在application.properties配置
  1. spring:  application:    name: test-client1eureka:  client:    serviceUrl:      defaultZone: http://localhost:8000/eureka/
复制代码
3、在启动类上添加注解
  1. 在启动类上添加注解 @EnableDiscoveryClient ,表示它是一个Eureka的客户端
复制代码
4、刷新Eureka Server查看注册情况
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RuGne7Fv-1579926999316)(C:\Users\54110\AppData\Roaming\Typora\typora-user-images\1561684185804.png)]
发现已经成功的将服务注册上去了
1.3.3.2 将test-client2注册到Eureka Server

方法同上。
1、在test-client2工程中添加spring-cloud-starter-eureka依赖:
2、在application.property配置eureka
3、在启动类上添加注解 @EnableDiscoveryClient
2 Feign远程调用

在前后端分离架构中,服务层被拆分成了很多的微服务,服务与服务之间难免发生交互
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5162FLxu-1579926999316)(img\1561689169147.png)]
工作流程如下:
1、client1服务将自己注册到注册中心。
2、client2从注册中心获取client1服务的地址。
3、client2远程调用client1服务
2.1 Ribbon

2.1.1 Ribbon介绍

​        Ribbon是Netflix公司开源的一个负载均衡的项目(https://github.com/Netflix/ribbon),它是一个基于HTTP、TCP的客户端负载均衡器。
1、什么是负载均衡?
负载均衡是微服务架构中必须使用的技术,通过负载均衡来实现系统的高可用、集群扩容等功能。负载均衡可通过硬件设备及软件来实现,硬件比如:F5、Array等,软件比如:LVS、Nginx等。
如下图是负载均衡的架构图:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4IxWvlXx-1579926999317)(img\1561689251784.png)]
用户请求先到达负载均衡器(也相当于一个服务),负载均衡器根据负载均衡算法将请求转发到微服务。负载均衡算法有:轮训、随机、加权轮训、加权随机、地址哈希等方法,负载均衡器维护一份服务列表,根据负载均衡算法将请求转发到相应的微服务上,所以负载均衡可以为微服务集群分担请求,降低系统的压力。
2、什么是客户端负载均衡?
上图是服务端负载均衡,客户端负载均衡与服务端负载均衡的区别在于客户端要维护一份服务列表,Ribbon从Eureka Server获取服务列表,Ribbon根据负载均衡算法直接请求到具体的微服务,中间省去了负载均衡服务。
如下图是Ribbon负载均衡的流程图:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MC2WDnnm-1579926999317)(img\1561689276309.png)]
1、在消费微服务中使用Ribbon实现负载均衡,Ribbon先从EurekaServer中获取服务列表。
2、Ribbon根据负载均衡的算法去调用微服务。
2.1.2 Ribbon测试

​        Spring Cloud引入Ribbon配合 restTemplate 实现客户端负载均衡。Java中远程调用的技术有很多,如:webservice、socket、rmi、Apache HttpClient、OkHttp等,互联网项目使用基于http的客户端较多,本项目使用OkHttp。
1、在客户端添加Ribbon依赖:
这里在client2配置ribbon依赖
  1.      org.springframework.cloud    spring-cloud-starter-ribbon     1.1.5.RELEASE      com.squareup.okhttp3     okhttp     3.9.1  
复制代码
2、配置Ribbon参数
这里在client2的application.propertyis中配置ribbon参数
  1. ribbon:  MaxAutoRetries: 2 #最大重试次数,当Eureka中可以找到服务,但是服务连不上时将会重试  MaxAutoRetriesNextServer: 3 #切换实例的重试次数  OkToRetryOnAllOperations: false  #对所有操作请求都进行重试,如果是get则可以,如果是post,put等操作没有实现幂等的情况下是很危险的,所以设置为false  ConnectTimeout: 5000  #请求连接的超时时间  ReadTimeout: 6000 #请求处理的超时时间
复制代码
3、负载均衡测试
1)启动两个client服务,注意端口要不一致
启动完成观察Eureka Server的服务列表
2)定义RestTemplate,使用@LoadBalanced注解
在client2的启动类中定义RestTemplate
  1. @Bean@LoadBalancedpublic RestTemplate restTemplate() {    return new RestTemplate(new OkHttp3ClientHttpRequestFactory());}
复制代码
3)测试代码
在client2工程创建单元测试代码,远程调用test-producer的查询页面接口:
[code]        @Autowired    RestTemplate restTemplate;   //负载均衡调用        String serviceId ="TEST-PRODUCER1";        for(int i=0;i




上一篇:《计算机网络:自顶向下方法(原书第七版)》 参考答案(英文版+中文版)
下一篇:计算机与操作系统与网络原理--1
回复

使用道具 举报

0

主题

16

帖子

346

积分

中级会员

Rank: 3Rank: 3

积分
346
发表于 2020-1-28 18:21:51 | 显示全部楼层
这个帖子不回对不起自己![www.12360.co]
回复

使用道具 举报

0

主题

21

帖子

451

积分

中级会员

Rank: 3Rank: 3

积分
451
发表于 2020-2-11 00:42:13 | 显示全部楼层
这东西我收了!谢谢楼主![www.12360.co]
回复

使用道具 举报

0

主题

31

帖子

661

积分

高级会员

Rank: 4

积分
661
发表于 2020-2-22 10:49:35 | 显示全部楼层
感谢楼主的无私分享![www.12360.co]
回复

使用道具 举报

0

主题

27

帖子

577

积分

高级会员

Rank: 4

积分
577
发表于 2020-2-23 05:41:00 | 显示全部楼层
其实我一直觉得楼主的品味不错!呵呵![www.12360.co]
回复

使用道具 举报

0

主题

42

帖子

892

积分

高级会员

Rank: 4

积分
892
发表于 2020-2-25 06:50:42 | 显示全部楼层
楼主,大恩不言谢了![www.12360.co]
回复

使用道具 举报

0

主题

23

帖子

493

积分

中级会员

Rank: 3Rank: 3

积分
493
发表于 2020-3-21 08:37:03 | 显示全部楼层
既然你诚信诚意的推荐了,那我就勉为其难的看看吧![www.12360.co]
回复

使用道具 举报

懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

动物之森

GMT+8, 2020-4-5 23:13 , Processed in 0.109645 second(s), 41 queries .

www.12360.co 集合吧!动物之森

Copyright © 2019-2020.

快速回复 返回顶部 返回列表