微服务学习笔记

微服务学习笔记和SpringCloud学习笔记简介：微服务架构风格是一种将一个单一应用程序开发为一小组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用http资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。微服务在一定程度上是为了解决伸缩性问题、运行效率问题和开发效率问题应运而生的。微服务的基本原理：让一个小型应用专注的做好一件事情。一个微服务就是一个小型应用，方便替换，可以独立开发和部署。微服务无法单独存在，所以不会出现微服务孤岛。微服务是大型系统的组成为部分，他们与其他微服务一起工作，完成原先要在一个大型应用里才能完成的事情。微服务的目标：是要创建一组具备自治能力汇和自包含能力的独立应用。他们各自负责提供某一方面的功能。微服务架构：微服务架构每个微服务包含三个组件：一个前端，一个处理复杂逻辑的后端和一个存储或读取相关数据的存储引擎。这里所说的前端，是一套包含了固定端点的API,微服务生态系统微服务并不是孤立存在的他们存在于一个环境里面，在一个设计良好的微服务生态系统里，微服务与基础设施之间是分离的。微服务与硬件、网络、构建和部署管道、服务发现和负载均衡都是分离的。他们都是微服务生态系统基础设施的组成部分。微服务生态系统可以分为四层：第1层：硬件层主要包含：物理服务器数据库操作系统资源隔离和资源抽象配置管理主机级别的监控主机级别的日志第2层：通信层一般包含网络/DNS/RPC和API端点，服务发现，服务注册以及负载均衡RPC端点和消息传递、微服务通过远程过程调用RPC或消息传送与其他微服务进行交互，这些调用通过网络发送到其他微服务的API端点。主要包含：网络DNS远程过程调用端点消息传递服务发现服务注册负载均衡第3层：应用平台层主要包含：内部自助开发工具开发环境测试、构建、打包和发布工具部署管道微服务级别的日志微服务级别的监控第4层：微服务层顶层主要内容：微服务，微服务相关配置特性：1.每个服务可以独立运行在自己的进程里。2.一系列独立运行的微服务共同构建起整个系统3.每个服务为独立的业务开发，一个微服务只关注某个特定的功能，4.微服务之间通过一些轻量的通信机制进行通信。5.全自动部署机制。微服务架构的优点：1.易于开发维护：一个微服务只会关注一个特定的业务功能，所以业务清晰，代码量较少。2.单个微服务启动较快：单个微服务代码量较少，所以启动比较快。3.技术栈不受限：4.按需伸缩：可根据需求，实现细粒度的扩展。微服务架构面临的挑战1.运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行，而在微服务中，需要保证几十甚至几百个服务的正常运行与协调。2.分布式固有的复杂性：使用微服务架构的是分布式系统。对于一个分布式系统，系统容错，网络延迟，分布式事务等都会带来巨大的挑战。3.接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。4.重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题，但共享库在多个语言环境下就不一定行的通了。微服务的设计原则1.单一职责原则：一个单元(类，方法或者服务等)只应关注整个系统功能中单独、有界限的一部分。单一职责原则是SOLID原则之一。2.服务自治原则：服务自治是指单个微服务应该具备独立的业务功能、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个服务从开发、测试。构建、部署、都应当可以独立运行，而不应该依赖其他的服务。3.轻量级通信机制：通过轻量级的通信机制进行交互。轻量级的通信机制应具备两点：首先是他是体量较轻；其次是他应该跨语言。例如REST协议；而例如java的RMI则协议就不大符合轻量级通信机制的要求，因为他绑定了java语言。微服务架构中常用的协议有REST，AMQP，STOMP，MQTT等。4.微服务粒度：微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微服务。技术选型：性对于单体应用的交付，微服务应用的交付要复杂很多，不仅需要开发框架的支持，还需要一些自动化部署工具，以及IaaS，PaaS或Caas的支持。开发框架的选择：可使用SpringCloud作为微服务开发框架。为微服务架构提供了完整的解决方案。运行平台：微服务并不绑定运行平台，将微服务部署在PCServer，或者阿里云，AWS等云计算平台都是可以的。简介：SpringCloud是在SpringBoot基础上构建的，用于快速构建分布式系统的通用模式的工具集。使用SpringCloud开发的应用程序非常适合在Docker或者PaaS上部署，所以又叫做云原生应用。云原生可简单理解为面向云环境的软件架构。SpringCloud有以下特点：1.约定优于配置。2.适用于各种环境。开发，部署在PCServer或者各种云环境3.隐藏了组件的复杂性，并提供申明式，无xml的配置方式。4.开箱即用，快速启动5.轻量级的组件。SpringCloud整个的组件大多比较轻量。6.组件丰富，功能齐全。7.选型中立，丰富。例如SpringCloud支持使用Eureka，zookeeper或者Consul实现服务发现。8.灵活：SpringCloud的组件部分是解耦的，开噶人员可按需灵活挑战技术选型。项目整合SpringBootActuatorSpringBootActuator提供了很多监控端点。可使用http://{ip}:{port}/{endpoint}的形式访问这些端点，从而了解应用程序的运行状况。常用端点及描述端点描述HTTP方法autoconfig显示自动配置的信息GETbeans显示应用程序上下文所有的SpringbeanGETconfigprops显示所有@ConfigurationProperties的配置属性列表GETdump显示线程活动的快照GETenv显示应用的环境变量GEThealth显示应用程度的健康指标，这些指标由HealthIndicator的实现类提供GETinfo显示应用的消息，可使用info.*属性自定义info端点公开的数据GETmappings显示所有的URL路径GETmetrics显示应用的度量标准信息GETshutdown关闭应用(默认情况下不启用，如需启用，需设置endpoints.shutdown.enable=true)POSTtrace显示跟踪信息(默认情况下为最近100个HTTP请求)GETMaven配置：dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-actuator/artifactId/dependency微服务注册与发现简介：硬编码提供者地址的方式有不少问题，要解决这些问题，服务消费者需要一个强大的服务发现机制，服务消费者使用这种机制获取服务提供者的网络信息。不仅如此，即使服务提供者的信息发生变化，服务消费者也无须修改配置文件。服务提供者，服务消费者，服务发现组件者三者之间的关系各个微服务在启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件会存储这些信息。服务消费者可以从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的接口。各个微服务与服务发现组件使用一定机制(例如心跳)通信。服务发现组件如长时间无法与某微服务实例通信，就会注销该实例。微服务网络地址发生变更(例如实例增减或者IP端口发生变化等)时，会重新注册到服务发现组件。使用这种方式，服务消费者就无须人工修改提供者的网络地址了。综上，服务发现组件应具备以下功能1.服务注册表：是服务发现组件的核心，它用来记录各个微服务的信息，例如微服务的名称，IP，端口等。服务注册表提供API和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册和注销。2.服务注册于服务发现：服务注册是指微服务在启动时，将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及其网络地址的机制。3.服务检查：服务发现组件使用一定机制定时监测已注册的服务，如发现某实例长时间无法访问，就会从注册表中移除该实例。SpringCloud提供了多种服务发现组件的支持，例如：Eureka，Consul和Zookeeper等。服务发现的方式可细分为服务器端发现和客户端发现，原理相同。Eureka简介Eureka是Netflix开源的服务发现组件，本身是一个基于REST的服务。它包含Server和Client两部分。SpringCloud将它集成在子项目SpringCloudNetflix中，从而实现微服务的注册与发现。Eureka原理Eureka的工作原理，Eureka组件分为两部分：Eurekaserver和Eurekaclient。而客户端又分为ApplicationService客户端和ApplicationClient客户端两种。Eureka的工作机制每个region都有自己的Eureka服务器集群，每个zone至少要有一个Eureka服务器以应对zone瘫痪。概述名词解释1.Renew:我的理解是续约，为什么叫续约呢？Renew（服务续约）操作由ServiceProvider定期调用，类似于heartbeat。目的是隔一段时间ServiceProvider调用接口，告诉EurekaServer它还活着没挂，不要把它踢掉。通俗的说就是它们两之间的心跳检测，避免服务提供者被剔除掉。2.Cancel（服务下线）一般在ServiceProvider挂了或shutdown的时候调用，用来把自身的服务从EurekaServer中删除，以防客户端调用到不存在的服务。3.FetchRegistries(获取注册信息)，FetchRegistries由ServiceConsumer(服务消费者)调用，用来获取EurekaServer上注册的服务info。4.Eviction(剔除)Eviction（失效服务剔除）用来定期在EurekaServer检测失效的服务，检测标准就是超过一定时间没有Renew的服务。Eureka架构图从图中我们可以看出，Eureka组件分为两部分：Eurekaserver和Eurekaclient。而客户端又分为ApplicationService客户端和ApplicationClient客户端两种。Eureka的工作机制每个region都有自己的Eureka服务器集群，每个zone至少要有一个Eureka服务器以应对zone瘫痪。ApplicationService在启动时注册到Eureka服务器，之后每30秒钟发送心跳以更新自身状态,即Renew(续约)。如果该客户端没能发送心跳更新，它将在90秒之后被其注册的Eureka服务器剔除，即Eviction(剔除)。来自任意zone的ApplicationClient可以获取这些注册信息(每隔30秒查看一次)并依此定位到在任何区域可以给自己提供服务的提供者(即FetchRegistries)，进而进行远程调用。服务提供者本身携带的EurekaClient既能服务注册，服务续约，也能通过client定位服务和调用其它的服务。Renew(服务续约)服务续约Renew操作会在ServiceProvider端定期发起，用来通知EurekaServer自己还活着。这里有两个比较重要的配置需要注意一下：1eureka.instance.leaseRenewalIntervalInSecondsRenew频率。默认是30秒，也就是每30秒会向EurekaServer发起Renew操作。1eureka.instance