6.9面试笔记

什么是分布式 ：分布式就是将应用按照业务进行拆分成多个子应用，多个子应用部署在不同的服务器中，多个子应用组成一个完整的系统，所有的子系统一起工作相互通信相互协调才能完成最终的业务流程，缺一不可，简单理解：“多个人在一起做不同的事情，多人和在一起才是一件完整的事情，有点0.5+0.5=1的感觉”。

什么是分布式系统?

拆分服务,拆分多个子系统,提高性能,提高并发量(三高) 防止一部分出现故障,会影响其他的部分

高可用 ,高性能,高并发

应用架构的演变过程是怎么样?

*(ORM)单体架构----垂直架构----分布式架构----面向服务的分布式架构(SOA)--微服务架构

 (ORM)单体架构

  把全部都写在一起

所有的模块，组件等都在一个应用中应用最终打成一个(war,jar)包使用一个容器(Tomcat)进行部署，通常一个应用享用一个数据库。

单体架构的优缺点

• 易于开发 ：架构简单，技术成本低
• 易于测试 ：所有功能在一个项目，方便测试
• 易于部署 ：一个Tomcat就可以实现部署，简单方便

随着项目规模日益变大，我们可以采用集群的手段来出来解决高并发，但包含了所有组成部分的单体应用终归是有许多不足，主要缺点如下

    代码臃肿不方便开发维护(代码可读性差)

    代码编译系统启动变慢

    系统扩展性能变差(牵一发而动全身)

    无法针对某一个业务做扩展(集群)

    对大数据量,高并发量的处理不占优势

    技术选型单一

    模块/业务耦合度高
 

垂直架构

为了避免单个项目越来越大，引入了垂直架构的概念，它其实就是把原来比较大的单体项目拆分成多个小的单体项目，拆分过程是根据业务逻辑进行拆分的.

 技术单一，开发上手快，测试，部署都是比较简单的

但是:带来了数据冗余、耦合性大的问题。

分布式架构:

一个Tomcat负担不起系统中的所有业务的时候，我们可以按照业务把应用进行拆分成多个小的应用，每个小应用都用一个Tomcat去运行，每个小应用都是单体架构，每个应用只需要关系自己的业务即可，应用之间通过API相互调用，

如果某个子系统压力依然很大，可以单独对该子系统再做集群，所以分布式和集群并不冲突

面向服务的分布式架构(SOA)

SOA是面向服务的架构,它的思想是每个子应用可以通过网络通信协议向其他子应用提供服务或者消费服务，SOA也是分布式架构，我们可以简单的理解为SOA把分布式架构划分成表示层和服务层，服务层中包含了业务逻辑和相关流程，只需要对外暴露服务即可，表现层负责处理和页面的交互。这样的划分好处在于系统之间调用的方便性，如用户子系统只需要调用订单子系统的服务层即可完成应用之间的通信。这样的结构划分提高了应用的重用性，业务逻辑也变得可组合。

SOA架构中有重要的两个角色，服务消费者(Consumer)和服务提供者(Provider)即服务调用者和服务被调用者，这样的架构优点有：

    模块拆分，使用API通信，降低模块之间的耦合度
    项目拆分多个子应用，每个子应用业务简单，代码简单，方便维护开发。
    不同技术人员可以负责不同的子应用
    提高服务之间的重用性，业务逻辑可组合。

其缺点在于：

    服务之间的API接口开发增加了工作量，
    SOA服务之间的网络通信调用对性能有一定的影响(尽管很小)
    相对于单体应用来说，技术,人力成本较高。
    部署和运维相对麻烦
微服务架构

微服务就是把单一应用进行细粒度的拆分成多个小(微)的服务相，每个服务独立运行，每个服务只需要专注一个业务即可，并且每个服务都可以有自己的数据库(分库)，服务之间互协调配合完成整个系统的业务

特点 ：

• 由多个服务组成完整的系统
• 每个服务都是独立的，有自己的进程
• 服务之间使用HTTP协议通信
• 不同的服务可以使用不同的编程语言
• 不同的服务的数据库可以多样化选择
• 微服务是一个分布式系统

优缺点

在项目规模较大的时候，相对于单体应用来说，微服务具备很多优势，主要体现在如下方面：

    单个服务业务简单，代码简单方便开发维护
    服务之间无耦合，服务之间升级维护互不影响
    轻量级HTTP通信机制，使得的不同的服务可以采用不同的编程语言
    微服务有极强的扩展能力,业务量大的服务可以再次拆分服务，也可以进行集群部署，剔除服务也很方便
    更大的系统负载能力和容错能力(集群)
    对于开发人员来说,通常只需要关注单一服务,新员工上手也比较快
    微服务架构对现在流行的敏捷开发支持优化

凡是都有双面性，微服务展示出了他都优势之处，同时也有其不足的地方，主要体现如下方面：

    分布式事务 ：服务通信机制增加了事务的复杂性，架构师要选择合适的分布式方案(CAP理论)

    部署麻烦 ：微服务众多，部署麻烦，需要借助容器技术和自动化部署工具，这又增加了开发人员的学习成本。

    技术成本高 ：微服务架构本身比较复杂,技术成本高，开发人员需要花更多的时间学习相关技术。

    服务通信对性能的损耗 ： 微服务架构一定要考虑服务通信延迟对服务调用性能的损耗问题，开发人员需要选择合适的通信方式解决这一问题。
 

分布式架构实现的原理?

远程过程调用 rpc

dubbo是什么?

一款分布式服务框架 高性能和透明化的RPC远程服务调用方案

Java语言开发的,RPC,分布式服务框架
(暴露服务,消费服务)

dubbo怎么使用?(跟项目联系在在一起)
dubbo暴露服务和应用服务的，实现远程调用，springboot项目应用dubbo的start,jar包,配置注册中心（hadoop的子项目zookeeper用于做注册中心）
@Service,@relerence,@EnableDubbo

服务注册与发现
1.0容器启动了提供者
2.1提供者注册
3.2消费找Registry服务,
4.3Registry跟消费者说服务的地方
5.4通知注册中心服务在哪里
6.5建立连接

一般用dubbo，说明你业务量非常庞大，前后端分离，用Vue做前端，用vue调用springboot分布式项目中的api接口

多模块项目是单体应用的情况下，可以设置某个模块作为web。