前言
学知识最忌讳“东一榔头，西一棒子”，除非你有学霸的意志力，孜孜不倦的学习态度。学霸和学渣总是倍受关注，然而大多数人都是介于学霸与学渣之间。
有多少能坚持不懈地埋在书海里抗住寂寞呢？同样地也没有人真正的愿意荒废人生，飘渺度日。谁不想努力呢？
为什么用微服务？解耦！不要管什么多语言开发、独立部署、可拓展性、独立数据库、团队拆分敏捷开发，就两字：解耦！！！！！再问割JJ
举个例子？ 缴费和积分作为例子，如果积分服务挂了，缴费可以正常用，因为他们部署在不同的主机上。
微服务概念？ 微服务架构是一种架构模式，它单一应用程序划分成一组小的服务，每个服务是一个独立的进程，服务之间互相协调、互相配合。服务之间采用轻量级的通信机制相互协作（通常是基于HTTP协议的restful api）。
单体架构到微服务的演变过程：业务少---》单体架构美滋滋
--》业务增多应用性能差---》读写分离、加缓存、加负载均衡服务器、应用集群化部署
---》管理混乱，治理难度大，头疼 ----》考虑分布式系统，微服务架构。（后续不分先后）--》注册中心统一管理各个服务
---》配置太多了烦死了---》加个配置中心
---》部署那么多机器有些机器访问大吃不消，有些机器又长期空闲---》搞个负载均衡
----》服务跑着跑着发现有一个服务B主机挂了，服务A调用了B，导致A出现大量线程阻塞，最后A也挂了，最后就是大量微服务挂了“雪崩效应”-----》加个熔断器
----》什么阿猫阿狗都调我的服务，我不想让他们调，得加个权限控制和路由转发功能----》增加网关
---》今天被投诉了，有一个客户缴费了，一个星期过去了没有看到积分增加。原来是之前积分微服务挂了，缴费成功了积分却没涨。------》谈谈分布式事务解决方案（两阶段、TCC等）
---》生产出现一个问题，中间调用了N个微服务，不知道是哪个环节出问题，我还不知道具体的调用链路，查个鬼，怎么甩锅------》调用链路跟踪（Zipkin）
---》美滋滋，运行的稳稳地，突然领导说：你看下我们有多少个接口，调用量如何 ----》mmp....
微服务有哪些核心组件？ 注册中心、负载均衡、服务熔断/降级、网关、配置中心、远程调用等。
微服务开发的方式主要有一下三种：
1、dubbo+zookeeper
2、spring boot+spring cloud
3、ServiceComb
dubbo ：是一个RPC框架，底层是netty（netty是什么？是对NIO一种封装改进，简单来说是一种高性能网络通讯框架。什么是NIO？哥屋恩！），微服务间调用、负载均衡、服务注册。
zookeeper：服务注册中心
spring boot：spring全家桶的封装，不是新技术。
spring cloud：基于springboot一套微服务框架，一种解决方案。
servicecomb：也是apache开源框架。兼容springcloud的微服务框架，使用Saga提供一站式解决方案，服务部署治理监控。
微服务间的通信方式：REST协议(http-文本)、RPC（二进制）。
RPC：本质是将对象转为二进制，然后通过socket进行网络通信的过程。被调用方拿到二进制数据后，再转为java对象，调用具体的接口。Dubbo就是一个RPC框架，底层是Netty实现的。
Netty： https://mp.csdn.net/editor/html/114745014
微服务架构三大难题？ 不好拆分、分布式事务、单个故障引起上层大量线程阻塞。
部署容器对比：
单体：tomcat、jettry等serlet容器
微服务：Docker容器
事务差异比对：
单体：通过Transactional、数据库本身的事务来控制。
微服务：分布式事务，解决方案有二阶段提交、三阶段、TCC、MQ消息事务等。
springcloud 五大组件：注册中心eureka、负载均衡ribbon、服务熔断hystrix、配置中心springcloudconfig、网关zuul。其实还有远程调用feign。
开胃菜结束！
任何事情，如果太多人知道，那你就没有优势了。
微服务CAP理论：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），不可能同时满足“一致性”、“可用性”、“分区容错性”。
注册中心的类型有AP和CP，AP优先保证可用性，CP优先保证一致性。AP代表：zookeeper。CP代表：springcloud的eureka，阿里的nacos既可以支持AP也支持CP 。
虽然现在很多用nacos替换eureka，
eureka分为客户端和服务端，一个eureka既可以是客户端也可以是服务端。Client在服务启动后每30s发送心跳，Server 每90s检查一次是否有接收到心跳。可惜的是eureka2.0之后就停止更新了。目前一般是由阿里的nacos替代。
什么是Eureka的自我保护模式
默认情况下，如果Eureka Service在一定时间内没有接收到某个微服务的心跳，Eureka Service会进入自我保护模式，在该模式下Eureka Service会保护服务注册表中的信息，不在删除注册表中的数据，当网络故障恢复后，Eureka Servic 节点会自动退出自我保护模式。
服务端会出现如下错误警告：
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.