这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
1 微服务架构
1.1 背景由来
产生背景：随着数据时代的发展，高访问量高并发量越来越常见，数据量趋于海量，传统的单体应用架构有着难以理解和维护、开发效率低等缺点无法满足新时代的需求，为了更好地面对高并发海量数据的问题，所以产生了微服务架构、分布式系统来面对海量的数据访问处理。
把一个大的项目服务，拆分成多个小服务，共同组成一个应用系统；将一个项目以开发一组小服务的方法来进行开发，每个小服务都是一个独立的微型应用拥有自己独立的数据库等资源，每个小服务之间可以进行通信,而且可以通过全自动部署机制进行独立部署。
1.2 架构概览
接入网关层： 微服务面向的“用户”，一般是Web、移动端、PC端等。出于用户体验的考量，服务端提供给客户端的的接口应当尽量实现结果聚合，减少请求次数。因此，一般要设置一层接入网关，他负责调用业务微服务A B C等，完成结果聚合后，一并返回给客户端。
业务服务层： 在提供了微服务的基础设施后，我们可以放手开发各个微服务了。业务服务层是一些“基础微服务”或“业务微服务”，他们“各司其职”，服务之间的耦合应当做到最低。
微服务设施层
- 假设服务A需要调用服务B，那么A服务如何获取服务B的地址(例如IP和端口)呢？在传统的单块架构中，服务数量很少，尚可采用同在配置中写死IP、端口的方法来解决这个问题。但在微服务时代，面对动辄成百上千的微服务，这种做法将不再可行。因此，如何自动注册、发现微服务的多个实例，是架构必须解决的核心问题。
- 微服务拆分后，我们的系统从单机演化为分布式系统，为了防止分布式系统的雪崩效应2、微服务设施需要有的熔断和限流的能力。
- 面对众多的微服务，逐一修改配置的方式显得更加笨拙，我们需要有一个中央配置平台，快速完成微服务的配置修改。
- 前面已经提到，微服务的分布式架构，会加大调试难度，所以日志的收集和预警显得更加重要，同时，我们可以根据业务日志来进行一些监控预警，这和平台层的容器监控预警是不一样的。
- 微服务需要集成一些后端组件，如数据库、消息队列、缓存等。
运维平台层
- 对于后端服务的运维工作，持续交付是最重要的能力。由于微服务数量众多，一般需要构建一个持续交付系统，来完成微服务的自动运维，如微服务的初始化、发布、回滚、扩容。
- 采用微服务架构后，上线的次数、频率都会显著提升，这就需要一个上线的镜像版本管理系统，记录上线的镜像版本。在微服务架构中，一般采用容器技术来实现微服务的自动运维。
- 容器是轻量级资源，隔离能力相对较弱，我们需要对容器资源进行监控，调度和管理。举个例子：我们有三台物理机，现在物理机Ａ和C各运行了20个容器，物理机Ｂ运行了22个容器，假设每个容器的资源占用完全一致，那么资源调度系统会自动地，将B的两个的容器调整到物理机Ａ和Ｃ上。
1.3 基本组件
服务注册中心：注册系统中所有服务的地方。
服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
服务发现：服务调用方从服务注册中心找到自己需要调用服务的地址。
负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。
服务容错：通过断路器（也称熔断器）等一系列的服务保护机制，保证服务调用者在调用异常服务时快速地返回结果，避免大量的同步等待。
服务网关：也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。
分布式配置中心：将本地化的配置信息（properties、yml、yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
2 核心服务治理
2.1 流量治理
流量治理策略一:服务注册与发现
服务注册和发现是微服务时代最重要的内容，当注册中心出现问题的时候，整个服务集群就会不可用。如下图所示，众多的微服务都会注册到Kubernetes、Consul、Eureka、ZooKeeper中，通过Pilot实现服务发现，由Envoy提供数据支持。
流量治理策略二:负载均衡
支持负载均衡策略的算法有哪些?常见的算法有加权轮询、最少请求数、环形Hash、随机选择、优先级负载均衡、Locality加权。lstio的负载均衡策略APl主要是通过DestinaRule.TrafficPoliy属性设置，第一种是Simple，类型是SimpleLB (oneof)，一种简单的负载均衡策略(ROUND_ROBIN,LEAST——CONN,RANDOM,PASSTHROUGH)。第二种是consistentHash，类型是 ConsistentHashLB (oneof)，一致性Hash负载均衡算法(支持HTTP Header，HTTP Cookie，源地址，Query Param)。第三种是localityLbSetting，类型是LocalityLoadBalancerSetting，它是基于位置信息的负载均衡。
流量治理策略三:路由匹配
路由匹配条件，根据不同条件设置不同的权重。lstio的实现路由治理的API是通过VirtualService.HTTPRoute属性设置，主要有两种方式，第一种是Match，类型是HTTPMatchRequest]，HTTP匹配(uri,，header，scheme，method,query param等)第二种是Route，类型是HTTPRouteDestination[]，用来指定路由目的端，支持权重设置。
2.2 服务均衡
负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段之一。我们通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5 等; 而软件负载均衡则是通过在服务器上安装一些具有均衡负载功能或模块的软件来完成请求分发工作，比如Nginx 等。不论采用硬件负载均衡还是软件负载均衡，只要是服务端负载均衡都能以架构方式构建起来。
硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法(比如线性轮询、按权重负载、按流量负载等) 从维护的可用服务端清单中取出一台服务端的地址，然后进行转发。
而客户端负载均衡和服务端负我均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心，比如Eureka 服务端。同服务端负载均衡的架构类似，在客户端负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤需要与服务注册中心配合完成。
