springcloud相关知识

一、单体架构

-在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。

此时服务架构图

单体架构不足之处：

-在小型应用的初期，访问量小的时候这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。用户的增加，访问量越来越多单体架构的应用并发能力十分有限

-可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。

这种架构图

-这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。基于以上单体架构系统的不足，提出了微服务架构

二、微服务

-将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过HTTP协议进行通信（也可以采用消息队列来通信，如RoocketMQ，Kafaka等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如Eureka，Zookeeper等都是比较常见的服务集中化管理框架

微服务优势和劣势：

-优势：

--将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。--微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。面对高并发的场景可以将服务集群化部署，加强系统负载能力。--服务间采用HTTP协议通信，服务与服务之间完全独立。每个服务可以根据业务场景选取合适的编程语言和数据库。--微服务每个服务都是独立部署的，每个服务的修改和部署对其他服务没有影响。

-劣势

--随着服务数量增加，管理复杂，部署复杂，服务器需要增多，服务通信和调用压力增大，运维工程师压力增大，人力资源增多，系统依赖增强，数据一致性，性能监控

微服务和SOA的关系：

-SOA即面向服务的架构，SOA是根据企业服务总线（ESB）模式来整合集成大量单一庞大的系统，微服务可以说是SOA的一种实现，将复杂的业务组件化。但它比ESB实现的SOA更加的轻便敏捷和简单

微服务之间如何独立通讯？

-同步通信：dobbo通过 RPC 远程过程调用、springcloud通过 REST 接口json调用 等。

-异步：消息队列，如：RabbitMq、ActiveM、Kafka 等

SpringCloud 和 Dubbo 有哪些区别?

-共同：都是分布式管理框架

-不同：

–dubbo 是二进制传输，占用带宽会少一点。

SpringCloud是http 传输，带宽会多一点，同时使用http协议一般会使用JSON报文，消耗会更大

–dubbo 开发难度较大，所依赖的 jar 包有很多问题大型工程无法解决。

SpringCloud 对第三方的继承可以一键式生成，天然集成

–SpringCloud 接口协议约定比较松散，需要强有力的行政措施来限制接口无序升级

–Spring Cloud抛弃了Dubbo 的RPC通信，采用的是基于HTTP的REST方式

—REST牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。

而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适

三、微服务架构

-将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理

微服务架构系统

-是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求

四、SpringBoot 和 SpringCloud 之间关系

-SpringBoot：专注于快速方便的开发单个个体微服务（关注微观）；

-SpringCloud：关注全局的微服务协调治理框架，将SpringBoot开发的一个个单体微服务组合并管理起来（关注宏观）；

-SpringBoot可以离开SpringCloud独立使用，但是SpringCloud不可以离开SpringBoot，属于依赖关系。

五、什么是熔断？什么是服务降级？

-服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用

-服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性

六、eureka和zookeeper都可以提供服务注册与发现的功能，但有区别

-zookeeper 是CP原则，强一致性和分区容错性。

-eureka 是AP 原则 可用性和分区容错性。

C-Consistency,强一致性
A-Available,可用性
P-Partition tolerance,分区容错性

-在分布式中P是必须要有的，所以分布式有CP和AP两种模式：

    AP的就是可用性强，一致性弱；CP就是一致性强,可用性弱

-zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，耗时过长，虽然最终能够恢复，但是选取主节点期间会导致服务不可用，这是不能容忍的。

-eureka各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。

七、微服务技术栈总结