[武汉|结业弟子]JAVA-柯诗阳|2019年10月27日的日报-技能树.IT修真院

发表于： 2019-10-27 20:48:01

1 998

一、今天完成的事

1.任务9深度思考

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

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

其核心部分包含:

1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo目前支持4种注册中心,multicast,zookeeper,redis,和simple

（1）Zookeeper

优点：支持网络集群

缺点：稳定性受限于Zookeeper

（2）Redis

优点：性能高

缺点：对服务器环境要求较高

（3）Multicast

优点：面中心化，不需要额外安装软件

缺点：建议同机房（局域网）内使用

（4）Simple

适用于测试环境，不支持集群

推荐使用Zookeeper注册中心。

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

注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

举个现实生活中的例子，比如说，我们手机中的通讯录的两个使用场景：

当我想给张三打电话时，那我需要在通讯录中按照名字找到张三，然后就可以找到他的手机号拨打电话。

李四办了手机号，那么他把手机号告诉我，我把李四的号码存进通讯录，后续，我就可以从通讯录找到他。

上述两个场景就是我们在微服务架构中常常提到的：

服务发现

服务注册

Eureka 简介：

Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。其中， Eureka 又可细分为 Eureka Server 和 Eureka Client。

CAP 原则

C（Consistency）：数据一致性。分布式系统中，数据会有副本，无论是否从副本中取数据，从哪个副本取数据，结果都是一样的。保证所有地方数据一样就是保证了数据一致性。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。

A（Availability）：可用性。即只要收到用户的请求，服务器就必须给出回应。我们需要获取数据时，都能够正常的获取到想要的数据（允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。

P（Partition Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition），区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信，系统设计的时候，必须考虑到这种情况。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到，所以需要取舍是做到 A 还是 C 。

区别：

Zookeeper保证CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

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

使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

选择使用spring cloud,因为SpingCloud整个体系功能完备，与Spring框架完美契合，开箱即用，极大降低了落地微服务架构的开发成本。

dubbo由于是二进制的传输，占用带宽会更少

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

dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

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

dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研

从系统结构简易程序：springcloud的系统结构更简单、“注册+springmvc=springcloud”，而dubbo各种复杂的Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化..........炫技的成分更多一些

从性能：dubbo的网络消耗小于springcloud，但是在国内95%的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解

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

微服务就是把原本臃肿的一个项目的所有模块拆分开来并做到互相没有关联，甚至可以不使用同一个数据库。比如：项目里面有User模块和Power模块，但是User模块和Power模块并没有直接关系，仅仅只是一些数据需要交互，那么就可以吧这2个模块单独分开来，当user需要调用power的时候，power是一个服务方，但是power需要调用user的时候，user又是服务方了，所以，他们并不在乎谁是服务方谁是调用方，他们都是2个独立的服务，这时候，微服务的概念就出来了。

实现方案：

Spring Cloud：http://projects.spring.io/spring-cloud （现在非常流行的微服务架构）

Dubbo：http：//dubbo.io

Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）

Consul、etcd&etc.（微服务的模块）

包含模块：

（1）微服务

（2）配置管理器：统一管理配置

（3）服务名册：解耦主机地址

（4）API网关：入口和路由

（5）鉴权服务：身份和权限问题

（6）消息中介：异步和通知

（7）前置后端：优化前端开发

（8）回路熔断器：提高容错度

（9）负载均衡器：提升服务弹性

（10）扩展基建

Spring Cloud 微服务架构几个核心组件的底层原理：

（1）Eureka：各个服务启动时，(服务端) 都会将服务注册到(注册机)，

并且（服务端）还可以反过来从（注册机）拉取注册表，从而知道其他服务在哪里。(注册中心)

（2）Ribbon：服务间发起请求的时候，基于 Ribbon去做这个负载均衡，从一个服务的集群机器中根据策略选择一台执行作业。

（3）Feign：基于 Feign 的动态代理机制，根据注解和选择的机器，拼接请求 URL 地址，发起作业请求。

（4）Hystrix：发起请求是通过 Hystrix 的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。

（5）Zuul：如果前端、移动端要调用后端系统，统一从 Zuul 网关进入，由 Zuul 网关转发请求给对应的服务。

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

SCA为构建基于SOA的应用和解决方案提供了编程模型。它基于这样的理念：将业务功能作为一系列的服务而提供，并由这一系列的服务组装起来的解决方案来满足特定业务需求。这些组合的应用既包括为应用而新创建的特定服务，也包括源自已已存在系统和应用的业务逻辑，这些业务逻辑作为组合构件的一部分被复用。SCA既为服务的组合也为服务构件的创建提供了模型，包括对SCA组组合构件中对已存在应用功能的复用。

SCA是一个可执行的模型，用于将不同的服务集成到一个业务解决方案。它简化了实现业务服务的组件编程模型，这些组件可以使用不同编程语言实现。

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

6.Spring RMI，Spring Cloud，Tuscany，Dubbo分别是什么，互相之间有哪些不同？

SPring RMI：远程方法调用(Remote Method Invocation)。能够让在客户端Java虚拟机上的对象像调用本地对象一样调用服务端java 虚拟机中的对象上的方法。

Spring Cloud：Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路由、链路追踪等。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。

Tuscany：tuscany是一套开源的SCA框架模型，是做SOA的基础架构，SOA它是面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来

7.怎么实现WEB调用Service的负载均衡，怎么实现可以动态添加服务？

部署两台Service，利用Nginx去随机访问，任意一台挂掉都会自动访问另一台。

8.公司内部项目里使用的Scallop是什么，和资源中心是怎么结合在一起使用实现动态增加服务的？

不清楚...

二、遇到的问题

想在远程运行server，尝试了很多办法都没有启动成功

直接打包成jar包是启动不了的，

换成war包，先尝试启动，还是没能启动成功