微服务学习笔记(共12页)

1、微服务学习笔记和SpringCloud学习笔记简介：微服务架构风格是一种将一个单一应用程序开发为一小组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用http资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。微服务在一定程度上是为了解决伸缩性问题、运行效率问题和开发效率问题应运而生的。微服务的基本原理：让一个小型应用专注的做好一件事情。一个微服务就是一个小型应用，方便替换，可以独立开发和部署。微服务无法单独存在，所以不会出现微服务孤岛。微服务是大型系统的组

2、成为部分，他们与其他微服务一起工作，完成原先要在一个大型应用里才能完成的事情。微服务的目标：是要创建一组具备自治能力汇和自包含能力的独立应用。他们各自负责提供某一方面的功能。微服务架构：微服务架构每个微服务包含三个组件：一个前端，一个处理复杂逻辑的后端和一个存储或读取相关数据的存储引擎。这里所说的前端，是一套包含了固定端点的API,微服务生态系统微服务并不是孤立存在的他们存在于一个环境里面，在一个设计良好的微服务生态系统里，微服务与基础设施之间是分离的。微服务与硬件、网络、构建和部署管道、服务发现和负载均衡都是分离的。他们都是微服务生态系统基础设施的组成部分。微服务生态系统可以分为四层：第1层

3、：硬件层主要包含：物理服务器数据库操作系统资源隔离和资源抽象配置管理主机级别的监控主机级别的日志第2层：通信层一般包含网络/DNS/RPC和API端点，服务发现，服务注册以及负载均衡RPC端点和消息传递、微服务通过远程过程调用RPC或消息传送与其他微服务进行交互，这些调用通过网络发送到其他微服务的API端点。主要包含：网络DNS远程过程调用端点消息传递服务发现服务注册负载均衡第3层：应用平台层主要包含：内部自助开发工具开发环境测试、构建、打包和发布工具部署管道微服务级别的日志微服务级别的监控第4层：微服务层顶层主要内容：微服务，微服务相关配置特性：1. 每个服务可以独立运行在自己的进程里。2.

4、 一系列独立运行的微服务共同构建起整个系统3. 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，4. 微服务之间通过一些轻量的通信机制进行通信。5. 全自动部署机制。微服务架构的优点：1. 易于开发维护：一个微服务只会关注一个特定的业务功能，所以业务清晰，代码量较少。2. 单个微服务启动较快：单个微服务代码量较少，所以启动比较快。3. 技术栈不受限：4. 按需伸缩：可根据需求，实现细粒度的扩展。微服务架构面临的挑战1. 运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行，而在微服务中，需要保证几十甚至几百个服务的正常运行与协调。2. 分布式固有的

5、复杂性：使用微服务架构的是分布式系统。对于一个分布式系统，系统容错，网络延迟，分布式事务等都会带来巨大的挑战。3. 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。4. 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题，但共享库在多个语言环境下就不一定行的通了。微服务的设计原则1. 单一职责原则：一个单元(类，方法或者服务等)只应关注整个系统功能中单独、有界限的一部分。单一职责原则是SOLID原则之

6、一。2. 服务自治原则：服务自治是指单个微服务应该具备独立的业务功能、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个服务从开发、测试。构建、部署、都应当可以独立运行，而不应该依赖其他的服务。3. 轻量级通信机制：通过轻量级的通信机制进行交互。轻量级的通信机制应具备两点：首先是他是体量较轻；其次是他应该跨语言。例如REST协议；而例如java的RMI则协议就不大符合轻量级通信机制的要求，因为他绑定了java语言。微服务架构中常用的协议有REST，AMQP，STOMP，MQTT等。4. 微服务粒度：微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微

7、服务。技术选型：性对于单体应用的交付，微服务应用的交付要复杂很多，不仅需要开发框架的支持，还需要一些自动化部署工具，以及IaaS，PaaS或Caas的支持。开发框架的选择：可使用Spring Cloud作为微服务开发框架。为微服务架构提供了完整的解决方案。运行平台：微服务并不绑定运行平台，将微服务部署在PC Server，或者阿里云，AWS等云计算平台都是可以的。简介：Spring Cloud是在Spring Boot基础上构建的，用于快速构建分布式系统的通用模式的工具集。使用Spring Cloud开发的应用程序非常适合在Docker或者PaaS上部署，所以又叫做云原生应用。云原生可简单理解

8、为面向云环境的软件架构。Spring Cloud有以下特点：1. 约定优于配置。2. 适用于各种环境。开发，部署在PC Server或者各种云环境3. 隐藏了组件的复杂性，并提供申明式，无xml的配置方式。4. 开箱即用，快速启动5. 轻量级的组件。Spring Cloud整个的组件大多比较轻量。6. 组件丰富，功能齐全。7. 选型中立，丰富。例如Spring Cloud支持使用Eureka，zookeeper或者Consul实现服务发现。8. 灵活：Spring Cloud的组件部分是解耦的，开噶人员可按需灵活挑战技术选型。项目整合Spring Boot ActuatorSpring Boo

9、t Actuator提供了很多监控端点。可使用http:/ip:port/endpoint的形式访问这些端点，从而了解应用程序的运行状况。常用端点及描述端点描述HTTP方法autoconfig显示自动配置的信息GETbeans显示应用程序上下文所有的Spring beanGETconfigprops显示所有ConfigurationProperties的配置属性列表GETdump显示线程活动的快照GETenv显示应用的环境变量GEThealth显示应用程度的健康指标，这些指标由HealthIndicator的实现类提供GETinfo显示应用的消息，可使用info.*属性自定义info端点公开的

10、数据GETmappings显示所有的URL路径GETmetrics显示应用的度量标准信息GETshutdown关闭应用(默认情况下不启用，如需启用，需设置endpoints.shutdown.enable=true)POSTtrace显示跟踪信息(默认情况下为最近100个HTTP请求)GETMaven配置：<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId></dep

11、endency>微服务注册与发现简介：硬编码提供者地址的方式有不少问题，要解决这些问题，服务消费者需要一个强大的服务发现机制，服务消费者使用这种机制获取服务提供者的网络信息。不仅如此，即使服务提供者的信息发生变化，服务消费者也无须修改配置文件。服务提供者，服务消费者，服务发现组件者三者之间的关系各个微服务在启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件会存储这些信息。服务消费者可以从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的接口。各个微服务与服务发现组件使用一定机制(例如心跳)通信。服务发现组件如长时间无法与某微服务实例通信，就会注销该实例。微服

12、务网络地址发生变更(例如实例增减或者IP端口发生变化等)时，会重新注册到服务发现组件。使用这种方式，服务消费者就无须人工修改提供者的网络地址了。综上，服务发现组件应具备以下功能1. 服务注册表：是服务发现组件的核心，它用来记录各个微服务的信息，例如微服务的名称，IP，端口等。服务注册表提供API和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册和注销。2. 服务注册于服务发现：服务注册是指微服务在启动时，将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及其网络地址的机制。3. 服务检查：服务发现组件使用一定机制定时监测已注册的服务，如发现某实例长时

13、间无法访问，就会从注册表中移除该实例。Spring Cloud提供了多种服务发现组件的支持，例如：Eureka，Consul和Zookeeper等。服务发现的方式可细分为服务器端发现和客户端发现，原理相同。Eureka简介Eureka是Netflix开源的服务发现组件，本身是一个基于REST的服务。它包含Server和Client两部分。Spring Cloud将它集成在子项目Spring Cloud Netflix中，从而实现微服务的注册与发现。Eureka原理Eureka的工作原理，Eureka 组件分为两部分：Eureka server和 Eureka client。而客户端又

14、分为Application Service 客户端和Application Client 客户端两种。Eureka 的工作机制每个 region 都有自己的 Eureka 服务器集群，每个 zone 至少要有一个 Eureka 服务器以应对 zone 瘫痪。概述名词解释1. Renew:我的理解是续约，为什么叫续约呢？Renew（服务续约）操作由Service Provider定期调用，类似于heartbeat。目的是隔一段时间Service Provider调用接口，告诉Eureka Server它还活着没挂，不要把它踢掉。通俗的说就是它们两之间的心跳检测，避免服务提供者被剔除掉。2. Ca

15、ncel（服务下线）一般在Service Provider挂了或shut down的时候调用，用来把自身的服务从Eureka Server中删除，以防客户端调用到不存在的服务。3. Fetch Registries(获取注册信息)，Fetch Registries由Service Consumer(服务消费者)调用，用来获取Eureka Server上注册的服务info。4. Eviction(剔除)Eviction（失效服务剔除）用来定期在Eureka Server检测失效的服务，检测标准就是超过一定时间没有Renew的服务。Eureka架构图从图中我们可以看出，Eureka 组件分为两部分

16、：Eureka server和Eureka client。而客户端又分为Application Service客户端和 Application Client客户端两种。Eureka 的工作机制每个 region 都有自己的 Eureka 服务器集群，每个 zone 至少要有一个 Eureka 服务器以应对 zone 瘫痪。Application Service 在启动时注册到 Eureka 服务器，之后每 30秒钟发送心跳以更新自身状态,即Renew(续约)。如果该客户端没能发送心跳更新，它将在 90秒之后被其注册的 Eureka 服务器剔除，即Eviction(

17、剔除)。来自任意 zone 的 Application Client 可以获取这些注册信息(每隔 30 秒查看一次)并依此定位到在任何区域可以给自己提供服务的提供者(即Fetch Registries)，进而进行远程调用。服务提供者本身携带的Eureka Client既能服务注册，服务续约，也能通过client定位服务和调用其它的服务。Renew(服务续约)服务续约Renew操作会在Service Provider端定期发起，用来通知Eureka Server自己还活着。 这里有两个比较重要的配置需要注意一下：1eureka.instance.leaseRenewalInt

18、ervalInSecondsRenew频率。默认是30秒，也就是每30秒会向Eureka Server发起Renew操作。1eureka.instance.leaseExpirationDurationInSeconds服务失效时间。默认是90秒，也就是如果Eureka Server在90秒内没有接收到来自Service Provider的Renew操作，就会把Service Provider剔除。此定位到在任何区域可以给自己提供服务的提供者(即Fetch Registries)，进而进行远程调用。Eureka Server的高可用有分布式应用开发经验的读者应该能够看出，在单节点Eureka

19、Server并不适合线上生产环境。Eureka Client会定时链接Eureka Server，获取服务注册表中的信息并缓存在本地。微服务在消费远程API时总是使用本地缓存中的数据。因此一般来说，即使Eureka Server发生宕机，也不会影响到服务之间的调用。单如果Eureka Server宕机时，某些微服务也出现了不可用的情况，Eureka Client中的缓存若不被更新，就可能会影响到微服务的调用，甚至影响到整个应用系统的高可用性，因此，在生产环境中，通常会部署一个高可用的Eureka Server集群。Eureka Server可以通过运行多个实例并相互注册的方式实现高可用部署，E

20、ureka Server实例会彼此增量地同步信息，从而确保所有节点数据一致。事实上节点之间相互注册时Eureka Server的默认行为。Eureka的元数据Eureka的元数据有两种，分别是标准的语言数据和自定义元数据。标准元数据指的是主机名，IP地址，端口号，状态页和健康检查等信息，这些信息都会被发布在服务注册表中，用于服务之间的调用。自定义元数据可以使用eureka.instance.metadata-map配置。这些元数据可以在远程客户端中访问，但一般不会改变客户端的行为。除非客户端知道该元数据的含义。Eureka Server的REST端点Eureka Server提供了一些REST

21、端点。非JVM的微服务可使用这些REST端点操作Eureka，从而实现注册与发现。事实上，前文所讲的Eureka Client就是一个使用java编写的，操作这些REST端点的类库。也可以分析这些REST端点，编写其他语言的Eureka Client。下表是Eureka提供的REST端点，可以使用XML或者json与这些端点通信，默认是XML。Eureka的健康检查说明：在Status栏显示着UP，表示应用程序状态正常。其它取值DOWN、OUT_OF_SERVICE、UNKNOWN等，只有UP的微服务会被请求。由于Eureka Server与Eureka Client之间使用心跳机制来确定Eu

22、reka Client的状态，默认情况下，服务器端与客户端的心跳保持正常，应用程序就会始终保持“UP”状态，所以微服务的UP并不能完全反应应用程序的状态。Spring Boot Actuator提供了/health端点，该端点可展示应用程序的健康信息，只有将该端点中的健康状态传播到Eureka Server就可以了，实现这点很简单，只需为微服务配置如下内容：#开启健康检查（需要spring-boot-starter-actuator依赖） eureka.client.healthcheck.enabled = true如果需要更细粒度健康检查，可实现flix.appinfo

23、.HealthCheckHandler接口Eureka的自我保护模式进入自我保护模式最直观的体现，是Eureka Server首页输出的警告。 默认情况下，如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，这就可能变得非常危险了-因为微服务本身是健康的，此时本不应该注销这个微服务。  Eureka Server通过“自我保护模式”来解决这个问题-当Eureka Server节点在短时间内丢失过多客户端时（可能发生了网络

24、分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，Eureka Server就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。  自我保护模式是一种对网络异常的安全保护措施。使用自我保护模式，而已让Eureka集群更加的健壮、稳定。在Spring Cloud中，可以使用eureka.server.enable-self-preservation=false来禁用自我保护模式，当然也可以使用显示指定IP地址来解决：eureka.instance.instance-id

25、: $spring.cloud.client.ipAddress:$server.port多网卡环境下的IP选择2.1、简介指定IP在某些场景下很有用，如某台服务器有eth0、eth1和eth2三块网卡，但是eth1可以被其它的服务器访问；如果Eureka Client将eth0或者eth2注册到Eureka Server上，其它微服务就无法通过这个IP调用该微服务的接口。Spring Cloud提供了按需选择IP的能力，从而避免以上的问题。2.2、操作方案1、忽略指定名称的网卡#忽略eth0,支持正则表达式 spring.cloud.inetutils.ignored-interfaces0=eth0 #注册时使用ip而不是主机名 eureka.instance.prefer-ip-address=true方案2、只使