微服务入门介绍
开发环境
基于：IntelliJ IDEA、Maven构建工具、SpringBoot 项目 、Spring4.3.28``JDK1.8、编写。
官人如需使用 IDEA 请阅读教程：IntelliJ IDEA
官人如需使用 Maven 请阅读教程：Maven 构建工具的下载与安装
更多干货
请参考：《穿越 Java 之 语法基础篇》 系列文章
请参考：《穿越 Java 之 Web基础篇 》系列文章
请参考：《穿越 Java 之 开发必备框架篇 》 系列文章
请阅读：《穿越 Java 之 SpringBoot》系列文章
请阅读：《穿越 Java 之 SpringCloud》 系列文章
发展历程
以前的开发模式：单体架构的方式
网站初期的架构越好，因为业务需要快速迭代和发布，单体架构开发和运维都很简单。
逐步发展为：垂直领域进行区分
垂直架构主要是用来解耦业务的复杂度，提高代码的维护性和可扩展性
负载均衡+集群化的部署
网站流量开始增加，服务器的性能出现瓶颈，通过集群架构进行横向扩容是最好的方式
抽取公共功能 或 模块 称为服务（SOA）架构，SOA架构主要解决服务的复用性问
题，它的核心目标是通过服务的抽象来实现业务功能的可复用性。
微服务，微服务架构是在SOA架构思想之上的提炼，它是服务化思想的最佳时间方
向和服务治理不断完善和交付链路逐步成熟后的自然产物。
服务注册发现
- 服务注册就是维护一个登记簿，它管理系统内所有的服务地址。当新的服务启动后，它会向登记簿交待自己的地址信息。服务的依赖方直接向登记簿要 Service Provider 地址就行了。
- 当下用于服务注册的工具非常多 ZooKeeper，Consul，Etcd, 还有 Netflix 家的 eureka 等。
服务注册有两种形式：客户端注册和第三方注册。
客户端注册（zookeeper）
- 客户端注册是服务自身要负责注册与注销的工作。
- 当服务启动后向注册中心注册自身，当服务下线时注销自己。
- 期间还需要和注册中心保持心跳。心跳不一定要客户端来做，也可以由注册中心负责（这个过程叫探活）。
- 这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一套注册逻辑
第三方注册（独立的服务 Registrar）
- 第三方注册由一个独立的服务Registrar负责注册与注销。
- 当服务启动后以某种方式通知Registrar， 然后 Registrar 负责向注册中心发起注册工作。
- 同时注册中心要维护与服务之间的心跳，当服务不可用时，向注册中心注销服务。
- 这种方式的缺点是 Registrar 必须是一个高可用的系统，否则注册工作没法进展。
服务端发现
- 服务端发现需要额外的 Router 服务，请求先打到 Router，然后 Router 负责查询服务与负载均衡。
- 这种方式虽然没有客户端发现的缺点，但是它的缺点是保证 Router 的高可用
Consul
Eureka
SmartStack
Etcd
API 网关
- API Gateway 是一个服务器，也可以说是进入系统的唯一节点。
- 这跟面向对象设计模式中的Facade 模式很像。
- API Gateway 封装内部系统的架构，并且提供 API 给各个客户端。
- 它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。
- 下图展示了一个适应当前架构的 API Gateway
请求转发
服务转发主要是对客户端的请求安装微服务的负载转发到不同的服务上
响应合并
把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务。
协议转换
重点是支持 SOAP，JMS，Rest 间的协议转换。
数据转换
重点是支持 XML 和 Json 之间的报文格式转换能力（可选）
安全认证
- 基于 Token 的客户端访问控制和安全策略
- 传输数据和报文加密，到服务端解密，需要在客户端有独立的 SDK 代理包
- 基于 Https 的传输加密，客户端和服务端数字证书支持
- 基于 OAuth2.0 的服务安全认证(授权码，客户端，密码模式等）
配置中心
- 配置中心一般用作系统的参数配置，它需要满足如下几个要求：高效获取、实时感知、分布式访问。
zookeeper 配置中心
- 实现的架构图如下所示，采取数据加载到内存方式解决高效获取的问题，借助 zookeeper 的节点监听机制来实现实时感知。
配置中心数据分类
事件调度（kafka）
- 消息服务和事件的统一调度，常用用 kafka ，activemq 等。
服务跟踪（starter-sleuth）
- 随着微服务数量不断增长，需要跟踪一个请求从一个微服务到下一个微服务的传播过程， Spring Cloud Sleuth 正是解决这个问题。
- 它在日志中引入唯一 ID，以保证微服务调用之间的一致性，这样你就能跟踪某个请求是如何从一个微服务传递到下一个。
-
为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的 Trace ID。通过 Trace ID 的记
录，我们就能将所有请求过程日志关联起来。 -
为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到的 Span ID，对于每个 Span 来说，它必须有开始和结束两个节点，通过记录开始 Span 和结束 Span 的时间戳，就能统计出该 Span 的时间延迟，除了时间戳记录之外，它还可以包含一些其他元数据，比如：事件名称、请求信息等。
-
在快速入门示例中，我们轻松实现了日志级别的跟踪信息接入，这完全归功于spring-cloud-starter-sleuth 组件的实现。在 Spring Boot 应用中，通过在工程中引入 spring-cloud-starter-sleuth 依赖之后， 它会自动的为当前应用构建起各通信通道的跟踪机制，比如：
通过诸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 绑定器实现的消息
中间件）传递的请求。通过 Zuul 代理传递的请求。 通过 RestTemplate 发起的请求。
服务熔断（Hystrix）
- 在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。
- 服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
- 熔断器的原理很简单，如同电力过载保护器。
- 它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU时间去等到长时间的超时产生。
- 熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
Hystrix 断路器机制
- 断路器很好理解, 当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务.
- 断路器保持在开路状态一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN).
- Hystrix 的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。
API 管理
- SwaggerAPI 管理工具。