今天完成的事情： 深度思考
明天计划的事情：复习前面任务，做评审ppt
遇到的问题：
收获：

1.Dubbo提供了哪几种注册中心的方式？Redis和Zookeeper应该用哪一种？ 

1.1 Dubbo是什么？

http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

架构图如下：

节点角色说明

调用关系说明

0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。

1.2 注册中心有哪些？

Zookeeper(推荐)，Multicast，Redis，Simple

Zookeeper支持分布式，有很多周边产品。但是受限于稳定性。

Multicast去中心化，不需要单独安装软件。但是Provider 和 Consumer 和 Registry 不能跨机房(路由)。

Redis支持集群，性能好。

Simple标准RPC服务，没有兼容问题。但是不支持集群。

1.3 Redis和Zookeeper区别？

都是用来做注册中心，zookeeper用的要多些。至于什么区别暂时不清楚。

1.4 Zookeeper安装，Dubbo控制台？

1）下载安装 Zookeeper：https://archive.apache.org/dist/zookeeper/zookeeper-3.4.11/

2）解压：tar -zxvf zookeeper-3.4.11.tar.gz

3）移动至指定位置并改名为 zookeeper

mv zookeeper-3.4.11 /usr/local/zookeeper

4）配置 zookeeper：初始化 zookeeper 配置文件

拷贝 /usr/local/zookeeper/conf/zoo_sample.cfg 到同一个目录下，改名为 zoo.cfg

5）启动 zookeeper

./zkServer start 启动

./zkServer stop 停止

./zkServer status 当前状态

./zkSever restart 重启

3、安装 dubbo-admin 管理控制台

旧版 dubbo-admin 是 war，新版为 jar 可直接运行，不需要放置到 tomcat 中

<p <span="" <="" span="" style="margin-top: 0px; margin-bottom: 10px; word-break: break-all; white-space: normal; font-family: Arial, "Times New Roman", "Microsoft YaHei", SimSun, SimHei; font-size: 14px;">

可以看到 dubbo-admin 管理后台

2.微服务里，什么是注册中心，注册中心最常见的有Zookeeper，Eureka，还有我们自己的Scallop，他们之间的区别是什么？

注册中心，类似于中介，租客就是消费方，房东就是提供方。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。区别在上面的1中有提到。Scallop没有了解到。

3.Dubbo和Spring Cloud的区别是什么？如果让你来做架构选型，你会选择哪一个微服务体系，原因是什么？ 

Dubbo具有调度、发现、监控、治理等功能，支持相当丰富的服务治理能力。Dubbo架构下，注册中心对等集群，并会缓存服务列表已被数据库失效时继续提供发现功能，本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的网站。

4.什么是微服务，微服务有哪几种实现方案，包含哪几个模块，Spring Cloud分别是怎么实现的？

https://www.cnblogs.com/kenshinobiy/p/11113124.html

微服务：

微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。微服务和整体架构之间的区别在于，微服务由许多较小的，松散耦合的服务组成一个应用程序，与大型，紧密耦合的应用程序的整体方法相反。

常见的设计模式和应用

微服务架构需要考虑的问题，包括：

a. API Gateway

b. 服务间调用

c. 服务发现

d. 服务容错

e. 服务部署

f. 数据调用

六种常见的微服务架构设计模式：

a. 聚合器微服务设计模式

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步

b. 代理微服务设计模式

在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

c. 链式微服务设计模式

在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。

e. 分支微服务设计模式

这种模式是聚合器模式的扩展，允许同时调用两个微服务链，

f. 数据共享微服务设计模式

在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。

g. 异步消息传递微服务设计模式

虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应

Spring Cloud

服务发现框架-Eureka

负载均衡-Ribbon

熔断降级处理-Hystrix

服务网关-Zuul

配置管理-Config

消息总线-Bus

5.什么是SOA，什么是SCA，什么是微服务？ 

SOA

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。把系统按照实际业务，拆分成刚刚好大小的、合适的、独立部署的模块，每个模块之间相互独立。

SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服

务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方

式进行通信。

SCA

SCA全称Service Component Architecture，即服务组件框架。它由BEA、IBM、Oracle等知名中间件厂商联合制定的一套符合SOA思想的规范。