目录
1.微服务架构5个核心问题
（解决这些问题都是依托于中间件，学微服务也是学这些中间件）
①、服务很多，客户端该如何访问（后台接口有很多，有可能一个页面需要调用几十个服务)
a.网关：后端有一个总管将任务分给谁的部件（所有对外暴露接口的管理者）
②、这么多服务，服务之间如何通信（如何做到全自动化)
a、服务注册，将ip和端口号放入到zk中
b、zookeeper:所有微服务的管理者（在后端想要调用零另一个服务时，先去zk查另一个服务的ip和端口号）
③、这么多服务，如何去管理，如何监控每个服务的运行状态
a、zookeeper
④、如果有其中一个服务挂了，如何解决
a、zk会定时向每个注册进来的微服务发送心跳检测，看能不能通。没有回就认为宕机了
b、微服务中宕机是个很严重的事故，因为只要宕机，调用链中含宕机的那个服务就都不能访问了。（可能会有30%）问题是：用户会认为网络卡了，然后刷新。就会导致网络流量激增，但是一直返回服务异常。而一个服务的网络带宽是有限制的。就会导致本来正常调用链的请求，也进不来了。一般如果不做处理，会导致整个系统瘫痪。
c、解决
结合zk做好报警系统。如果说zk监听到的宕机了，或者服务内存占用量过大，即使向开发人员反馈（apm报警系统：先发短信--》过一分钟没有处理--》发邮件--》电话）
服务熔断：网关检测到接口失败率过高，直接返回服务异常。熔断返回很快，因为没有业务逻辑，是直接返回的
⑤、微服务架构存在哪些缺陷，什么是cap问题
2.微服务架构实现方案
①、spring cloud Netflix
②、apache dubbo + zookeeper.（spring）
③、Spring cloud Alibaba
3.微服务架构更多的是架构思想
微服务架构会带来很多问题，比如两个服务数据不一致（用户更改用户名调用的接口是用户服务的接口，更改了用户服务的数据表，但是没有更改订单服务的表）
4.学习微服务的意义
虽然就开发来说，就是单纯的Springbot做增删改查，但是一但涉及到解决各个系统之间交互的问题时，如果不学微服务的思想，架构设计的调优方案就会看不懂，不知道怎么实施。
5.微服务架构一般采用
①、common:放一些公用的枚举
②、client：rpc调用（RPC（Remote Procedure Call）远程过程调用协议，一种通过网络从远程计算机上请求服务，而不需要了解底层网络技术的协议。RPC采用客户端/服务端的模式，通过request-response消息模式实现）
③、service:rpc实现
④、web:http接口实现，controller
⑤、base：共有的业务逻辑
6.服务器有三种类型
①、云服务器：有一个公网ip（在云服务器上面部署了一个程序，是可以访问到的，因为有公网IP）
②、物理机（一个配置特别高的电脑）：可以有公网ip，也可以没有公网ip，如果没有公网ip，只能在机房内部通过交换机访问
公司一般都有一个同样的公网暴露服务器（有公网ip，通过他来调用其他没有公网ip的服务，保证安全）。xsheel通过账号密码访问跳板机（跳板机：可以对一些指令进行监控，跳板机也是一个有公网暴露面的服务器）
③虚拟机：由这个物理机用虚拟化技术虚拟出来的（vmware），两个虚拟机连接在同一个物理机里面直接传输，在同一个机房用交换机传输，距离远了就只能用互联网传输了。互联网传输是不可靠的，因为是通过光纤去传输的，有可能光纤受损传不过去，这就是我们微服务要解决的问题