目录

1.微服务架构5个核心问题

2.微服务架构实现方案

3.微服务架构更多的是架构思想

4.学习微服务的意义

5.微服务架构一般采用

6.服务器有三种类型

---

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），两个虚拟机连接在同一个物理机里面直接传输，在同一个机房用交换机传输，距离远了就只能用互联网传输了。互联网传输是不可靠的，因为是通过光纤去传输的，有可能光纤受损传不过去，这就是我们微服务要解决的问题