微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如 Dubbo 和 Spring Cloud。
目前微服务实现方式主要有两种Dubbo和SpringCloud：
一、Dubbo：(https://www.cnblogs.com/liangblog/p/6165070.html）
Dubbo是一个分布式服务框架，致力于提供高性能透明化RPC远程调用方案，提供SOA服务治理解决方案。
Dubbo使用 RPC 通讯协议。
架构原理：（http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html）
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
zookeeper注册中心：
- 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
- 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
- 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
- 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
- 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
- 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
- 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
- 服务提供者无状态，任意一台宕掉后，不影响使用
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
流程说明：
- 服务提供者启动时: 向
/dubbo/com.foo.BarService/providers目录下写入自己的 URL 地址 - 服务消费者启动时: 订阅
/dubbo/com.foo.BarService/providers目录下的提供者 URL 地址。并向/dubbo/com.foo.BarService/consumers目录下写入自己的 URL 地址 - 监控中心启动时: 订阅
/dubbo/com.foo.BarService目录下的所有提供者和消费者 URL 地址。
支持以下功能：
- 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
- 当注册中心重启时，能自动恢复注册数据，以及订阅请求
- 当会话过期时，能自动恢复注册数据，以及订阅请求
- 当设置
<dubbo:registry check="false" />时，记录失败注册和订阅请求，后台定时重试 - 可通过
<dubbo:registry username="admin" password="1234" />设置 zookeeper 登录信息 - 可通过
<dubbo:registry group="dubbo" />设置 zookeeper 的根节点，不设置将使用无根树 - 支持
*号通配符<dubbo:reference group="*" version="*" />，可订阅服务的所有分组和所有版本的提供者
dubbo服务治理：
服务治理主要作用是改变运行时服务的行为和选址逻辑，达到限流，权重配置等目的；主要配置有：条件路由(包括黑白名单)，动态配置(包括权重，负载均衡）
动态配置是和路由规则平行的一类服务治理治理功能，主要作用是在不重启服务的情况下，动态改变调用行为。
权重调节是动态配置的子功能，主要作用是改变服务端的权重，更大的权重会有更大的几率被客户端选中作为服务提供者，从而达到流量分配的目的：
负载均衡也是动态配置的子功能，主要作用是调整客户端的选址逻辑，目前可选的负载均衡策略有随机，轮训和最小活跃；
二、SpringCloud: （https://www.cnblogs.com/liangblog/p/9566525.html）
Spring Cloud 是一套完整的微服务解决方案，基于 Spring Boot 框架，准确的说，它不是一个框架，而是一个大的容器，是一系列框架的有序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路由、链路追踪等。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。
Spring Cloud 使用 HTTP 协议的 REST API。
总体架构：
- Service Provider： 暴露服务的提供方。
- Service Consumer：调用远程服务的服务消费方。
- EureKa Server： 服务注册中心和服务发现中心。
Spring Cloud运行基础组件：
服务治理： Spring Cloud Eureka
Eureka是微服务架构中的注册中心，专门负责服务的注册与发现
客户端负载均衡： Spring Cloud Ribbon
Ribbon作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上。默认使用的最经典的Round Robin轮询算法。
服务容错保护： Spring Cloud Hystrix
Hystrix是隔离、熔断以及降级的一个框架。通过Hystrix的线程池来发起请求，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
声明式服务调用： Spring Cloud Feign
Feign的一个关键机制就是使用了动态代理：
- 首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
- 接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
- Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
- 最后针对这个地址，发起请求、解析响应
API 网关服务：Spring Cloud Zuul
如果前端、移动端要调用后端系统，统一从Zuul网关进入，网关会根据请求中的一些特征，将请求转发给后端的各个服务。
好处是可以做统一的降级、限流、认证授权、安全，
大致流程如下：
- 所有请求都统一通过 API 网关（Zuul）来访问内部服务。
- 网关接收到请求后，从注册中心（Eureka）获取可用服务。
- 由 Ribbon 进行均衡负载后，分发到后端的具体实例。
- 微服务之间通过 Feign 进行通信处理业务。
- Hystrix负责处理服务超时熔断
SpringCloud相较于Dubbo来说更为全面，拥有服务治理，配置服务，网关路由，异常处理等，比Dubbo更全面，尤其是在结合SpringBoot框架时只需添加依赖，使用方便，简化配置文件。在集群中各功能组件协调工作时使用SpringCloud架构项目能承受更高并发量，具有更强大的容错高可用性。
三、服务降级：（服务治理时配置服务降级，或代码级别设置）
服务降级就是当服务响应超时或连接请求超时，不用继续等下去，而采用降级措施，意思就是返回一个planB，返回一个我们自己定义好的提示。
而为什么要使用服务降级，这是防止分布式服务发生雪崩效应，什么是雪崩？就是蝴蝶效应，当一个请求发生超时，一直等待着服务响应，那么在高并发情况下，很多请求都是因为这样一直等着响应，直到服务资源耗尽产生宕机，而宕机之后会导致分布式其他服务调用该宕机的服务也会出现资源耗尽宕机，这样下去将导致整个分布式服务都瘫痪，这就是雪崩。如果你要问为什么不做集群？集群当然做，但是一台服务宕机之后，其他流量分发到其他集群机器上，压力也会随之加大，时间久了整个集群也会垮了，这只是个时间问题。为了防止产生了雪崩效应那么就该对服务配置降级，一旦请求超过规定时间立即返回自定义好的提示，无需继续等待。
几种服务降级方式：
- 服务接口拒绝服务：无用户特定信息，页面能访问，但是添加删除提示服务器繁忙。页面内容也可在CDN内获取。
- 页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到nginx的一个静态页面。
- 延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
- 随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
