1.微服务和微服务架构
1.1.微服务架构定义：目前业界还没有统一的定义，但通常而言，它是一种架构模式或者是架构风格，它提倡将单一应用划分为一组小的服务，每个服务运行在自己独立的进程中，服务间采用轻量级的通信机制（通常是基于HTTP的RESTful API）
从技术角度理解：微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动
或销毁，拥有自己独立的数据库。
微服务：强调的是服务的大小，关注的是一个点，是具体解决某一个问题/提供落地服务的一个服务应用，可以看作Eclipse中的一个个微服务工程/或者Module。
1.2.微服务的优点：1）每个服务足够小，代码容易理解，容易聚焦到特定的业务功能和需求
2）开发简单且效率高，一个服务可能就专门干一件事。
3）能够被小团队单独开发
4）它是松耦合的，是有功能意义的服务，无论是在开发还是部署阶段都是独立的
5）能够使用不同的语言开发
6）易于和第三方集成
7）易于被一个开发人员理解和修护，这样小团队能够更加关注自己的工作成果，无需通过合作才能体现价值
8）允许融合最新技术
9）只是业务逻辑的代码，不会和HTML、CSS或其他界面组件混合
10） 每个微服务都有自己的存储能力，可以有自己的独立数据库，也可以有统一数据库
1.3.微服务的缺点：1）开发人员要处理分布式系统的复杂性
2）多服务运维难度增加
3）系统部署依赖
4）服务间通信成本增加
5）数据一致性、系统集成测试、性能检测等等
2.SpringCloud概述
2.1 概念：SpringCloud=分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶
2.2 与Springboot的关系：Springboot专注于快速、方便地开发一个个微服务，而SpringCloud关注全局的服务治理框架，SpringCloud是基于Springboot的使用来开发的。
2.3 与Dubbo区别：
最大区别：Dubbo采用的是基于RPC的通信机制，而SpringCloud采用的是基于HTTP的REST方式。（二者各有优势，但是REST方式相比RPC更灵活，服务提供方和调用方不存在代码级别的强依赖，这在强调快速演化的为服务下，更为合适）
其他区别：1）SpringCloud包含所有的微服务，且都是自己原生供应的；而Dubbo则是依赖了第三方，且有一些没有。（可参考品牌机与租装机的区别）
2）SpringCloud的社区支持和更新力度>Dubbo
2.4 参考资料：1）官网 2）https://springcloud.cc/spring-cloud-netflix.html 3）http://cloud.spring.io/spring-cloud-static/Dalston.SR1/ 4）http://springcloud.cn/
3.Eruka概述
3.1 概念：它是一个基于REST的用于定位的服务，以实现云端中间层发现服务和故障转移。有了服务的注册和发现，只需要使用服务的标识符，就可以访问到服务。而不需要修改服务调用的配置文件了。功能类似于Dubbo的zookeeper。
3.2 基本架构： 采用C-S的设计架构。（与Dubbo的注册中心架构对比非常相似）
3.3 包含组件：Eruka Server 和 Eruka Client，Server提供组件注册服务，Client用于简化Server的交互。
3.4 使用注意问题：在使用时可能会出现无法启动的问题，这是因为Springboot和SpringCloud版本不兼容的原因。还有微服务引入的版本号也要与对应的SpringCloud版本兼容。另外还要注意端口号是可用的。
可参考下列帖子：
3.5 eureka的自我保护机制：
3.5.1 现象：
3.5.2 原理：在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新回到阙值以上时，该Eureka Server就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的注册信息，也不盲目注销任何可能健康的服务实例。（有可能该服务实例只是由于网络故障而无法正常通信，并不是真正地挂了）。一句话：好死不如赖活着。使用它可以使Eureka集群更加的健康、稳定。
3.6：Eureka与Zookeeper比较（Eureka优于zookeeper）
1.在CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A（可用性）、和P（分区容错性）。由于分区容错性在分布式系统中是必须要保证的，因此我们只能在A和C中权衡。Zookeeper保证的是C，而Eureka保证的是A。服务注册功能对可用性的要求高于一致性，因此，Eureka可以很好地应对因为网络故障而导致部分节点失去联系的情况，而不是像zookeeper那样导致整个注册服务瘫痪。
4.Ribbon概述
4.1 概念：它是基于Netflix Ribbon实现的一套客户端负载均衡工具，主要功能是提供客户端的负载均衡算法。它是一套软负载均衡的客户端组件，它可以和其他所需请求的客户端结合使用，和eureka只是其中的一个实例。
4.2 负载均衡（Load Balance）：在微服务和分布式集群中常用的一种应用。简单地说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（ 高可用）。常见的负载均衡有软件Nginx，LVS，硬件F5等。相应的在中间件：例如，dubbo和sprngcloud中给我们提供了负载均衡，Springcloud的负载均衡算法可以自定义。它分为集中式和进程内LB。Ribblon属于后者。
4.3：工作步骤：分为两步，第一步先选择EurekaServer，它优先选择在同一个区域内负载较少的Server；第二步，根据用户的策略，从server取到的服务注册中选择一个地址。
4.4：核心组件IRule：里面有Ribbon自定义的各种负载均衡算法，用户可进行切换。Ribbon默认的是轮询算法。
5.Feign概述
5.1 概念：Feign是一个声明式的Web服务客户端，使得编写Web服务客户端非常容易，只需要创建一个接口，然后在上面添加注解即可。
5.2 作用：旨在使编写Java Http 客户端变得简单。在实际开发中，往往一个接口会被多处调用，所以通常会针对微服务自定封装一些客户端类来包装这些微服务的调用。而Feign能帮助我们定义和实现依赖接口的定义，简化了使用Spring cloud Ribbon时，自动封装服务调用客户端的工作量。（即面向接口调用微服务）
5.3与Ribbon的不同：Feign继承了Ribbon，并且通过轮询实现了客户端的负载均衡。与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而见到那地实现了服务调用。（其实就是接口调用接口）
6.Histrix（豪猪）
6.1 分布式系统面临的问题：复杂分布式体系中的应用结构有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。
6.2 服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他微服务，这就是”扇出“。如果扇出的链路上某个微服务不可用或者是调用时间过长，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的”雪崩效应“。
6.3 Hystrix是什么：它是一个用于分布式系统的延迟和容错的开源库，它能够保证在一个依赖出问题的情况下，向调用方返回一个符合预期的，可处理的备选响应。（FallBack）不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
6.4 服务熔断（类比保险丝的熔断）：熔断机制是应对雪崩效应的一种微服务保护机制。当扇出链路的某个微服务不可用或者响应时间太长时（即服务故障或出异常），直接熔断该服务，再进行服务的降级。当检测到正常后恢复响应。在Hystrix中熔断机制的注解为@HystrixCommand。
6.5 服务降级：就是当服务熔断之后，服务将不再被调用，此时客户端可以准备一个本地的fallback回调，返回一个缺省值。它是在客户端完成的，与服务端没有关系。这样做虽然服务水平下降，但总比服务器直接挂掉强。
6.6 服务监控HystrixDashboard：Hystrix是持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展现给用户，包括每秒请求多少成功，多少失败等等。
7.zuul路由网关（小区保卫处）
7.1 功能（代理+路由+过滤）：zuul包含了对请求的路由和过滤两个最主要的功能：其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础；过滤器功能则负责对请求的过程进行干预，是实现请求校验，服务聚合的功能的基础。zuul与Eureka整合，将它自身注册为Eureka服务治理下的应用（zuul最终还是会注册进Eureka的服务中），同时从Eureka中获取其他微服务的信息，也即以后的微服务都是通过zuul跳转后获得的。（Zuul最终还是会注册到Eureka中）
8.SpringCloud Config 分布式配置中心
8.1 概述
1）微服务面临的配置问题：系统中有大量服务，每个服务都需要必要的配置信息才能运行。所以一套集中式的，动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题。
2）是什么：SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
3）怎么用：SpringCloud Config分为服务端和客户端两部分。
服务端：也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。
客户端：通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并可以通过git客户端来方便地管理和访问配置内容。
