一，今天完成的事情

任务九

1，如果要用Spring Cloud的负载均衡，一定注意看以下网页。

https://cloud.spring.io/spring-cloud-commons/reference/html/#spring-cloud-loadbalancer-starter

尤其注意其中的

2.3. Spring RestTemplate as a Load Balancer Client

和2.4. Spring WebClient as a Load Balancer Client

2，任务九深度思考

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

1，在 Dubbo 中支持多种注册中心分别是：

（1）Multicast

Multicast 注册中心不需要启动任何中心节点，只要广播地址一样，就可以互相发现。

（2）Zookeeper

Zookeeper 是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用

（3）Nacos

Nacos 是最近由 Alibaba 推出快速实现动态服务发现、服务配置、服务元数据及流量管理、多租户的开源项目。同时支持注册中心、配置中心分离和合并部署。

（4）Redis

基于 Redis 实现的注册中心，使用 Redis 的 Key/Map 结构存储数据结构，使用 Redis 的 Publish/Subscribe 事件通知数据变更。

（5）Simple

Simple 注册中心本身就是一个普通的 Dubbo 服务，可以减少第三方依赖，使整体通讯方式一致。

2，ZooKeeper是Duboo官方推荐的注册中心，所以“Redis和Zookeeper”之中我也推荐Zookeeper。

（1）Zookeeper稳定性受到肯定，具体的实现在Dubbo源码的dubbo-registry-zookeeper模块中。Zookeeper本身不是为了服务发现而生，它是一个基于ZAB协议实现的可靠的分布式协调系统，它是强一致（CP）、使用基于TCP的私有协议通信。在应对大规模分布式集群上，Zookeeper的实力都是不容小觑的。而Redis注册中心，并没有经过长时间运行的可靠性验证，其稳定性依赖于Redis本身。

（2）Zookeeper比较Redis的优势：不会产生脏数据；redis需要每隔30s进行一次大查询；Redis每个服务都需要一个线程来监听数据(阻塞)。

（3）Zookeeper（简称zk）的数据模型很简单，有一系列被称为ZNode的数据节点组成，与传统的磁盘文件系统不同的是，zk将全量数据存储在内存中，可谓是高性能，而且支持集群，可谓高可用，另外支持事件监听。这些特点决定了zk特别适合作为注册中心(数据发布/订阅)。

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

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

2，Scallop有提供注册中心的功能，但是不是公开的系统，此回答不比较。

（1）CAP理论中，Eureka保证AP，Zookeeper保证CP。服务注册功能对可用性的要求要高于一致性。作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适。Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。

（2）Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。其中一个原因是zookeeper选举leader的时间太长，30 ~ 120s, 且选举期间整个zookeeper集群都是不可用的。Eureka可以布置多台，需要服务的服务器也可以暂时通过自己本地的缓存查询是否缓存中的服务器可用，应对Eureka网络连接失败这样经常可能遇到的情况。

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

1，（1）最大的区别:Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

（2）性能比较

使用一个Pojo对象包含10个属性，请求10万次，Dubbo和Spring Cloud在不同的线程数量下，每次请求耗时（ms）如下：

仅仅是参考，图是引用

（3）来源（背景）：

Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。

Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。

其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。

（4）传输：

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

Spring Cloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大。虽然考虑通过压缩、二进制、高速缓存、分段降级等方法解决，也可以考虑Thrift、ProtoBuf 等高效的 RPC、序列化协议同样可以作为替代JSON方案。

（5）开发难度：

Dubbo的jar包依赖问题很多大型工程无法解决，是Dubbo开发的一个难点。首先要能用。

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

（6）后续改进：

Dubbo通过dubbofilter，功能还是有限，需要自己继承，如监控，如日志，如限流，如追踪。

Spring Cloud自己带了很多监控、限流措施。

（7）注册中心：

Dubbo的注册中心可以选择多种。

Spring Cloud的注册中心可以用适合作为注册中心的Eureka或者自研。

（8）配置中心：

Dubbo：使用配置中心、分布式跟踪难度不小，都需要自己去集成。

Spring Cloud提供了微服务的一整套解决方案：服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。使用比自己再开发难度小很多，部分功能可以自己配置。

2，微服务体系选Spring Cloud。

（1）Spring Cloud是真正的微服务框架、提供整套的组件支持、使用简单方便、强大的社区支持等等。

（2）Spring Cloud更容易支持跨语言实现。.NET/.NET Core 的兼容处理，RPC 并不能很好的实现跨语言（需要借助跨语言库，比如 gRPC、Thrift，但因为 Dubbo 本身就是“gRPC”，在 Dubbo 之上再包一层 gRPC，有点重复封装了），而 HTTP REST 本身就是支持跨语言实现；Dubbox 也支持，但性能相比要差一些。

（3）Dubbo 专注 RPC 和服务治理，Spring Cloud 则是一个微服务架构生态。

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

1，微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。

使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。

2，微服务有哪几种实现方案：Spring Cloud,  Dubbo ，AWS Azure等云托管容器，某些公司内部使用的软件。

3，微服务通常包含以下模块。

服务注册和发现，负载均衡，容错，熔断，网关，分布式追踪，通信，安全等等。

4，Spring Cloud都实现了。

服务注册和发现Eureka；负载均衡 Spring Cloud Loadbalancer(过去是Spring Cloud Netflix Ribbon）；容错-其中一种方式是服务降级Resilience4j或者Hystrix；熔断（熔断也是一种容错方式）Resilience4j或者Hystrix；路由网关-Zuul，现在更常用Gateway；分布式追踪Sleuth。

通信：（1）RestTemplate。

（2）OpenFeign或者以前的Netflix的Feign

（3）WebClient。WebFlux：The Spring WebFlux can work with both reactive and non-reactive WebClient configurations

安全：Spring Security OAuth2，Spring Cloud Security。

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

1，面向服务的架构（Service-Oriented Architecture，SOA）还没有一个公认的定义。许多组织从不同的角度和不同的侧面对 SOA 进行了描述，较为典型的有以下三个：

（1）W3C 的定义：SOA 是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。

（2）Service-architecture.com 的定义：服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。

（3）Gartner 的定义：SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成，SOA 与大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口

面向服务的架构（Service Oritented Architecture，SOA）。跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的组件类型，比如POJO, EJB, 流程组件，人工交互组件等都可以通过一种标准的接口来封装和调用。结合SDO的数据模型，这种服务组件的编程模型可以大大的简化客户的编程，提高应用的灵活性。

2，SCA （Service Component Architecture）是为实现 SOA 而产生的一种规范。它提供了一种编程模型，能够十分方便、快速地来构建 SOA 所需的系统和应用。SCA 提出了一种组合应用（composite applications）的概念，这些组合可以是各种符合 SOA 规范的服务，或者是已经构建好的其他组合应用。通过这种灵活的编程方式，它可以很快地组装出各种所需的应用程序。

3，定义微服务。

微服务，从本质意义上看，还是SOA架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有Java编写的服务，也可以有Python编写的服务，他们是靠Restful架构风格统一成一个系统的。

最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性强。另一个不同是微服务架构本身很轻，底层也有类似于SOA的总线，不过非常轻薄，现在看到的就两种方式：MQ和HTTP，而HTTP都不能完全等同于总线，而仅仅是个信息通道。

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

1，Java远程方法调用，即Java RMI（Java Remote Method Invocation）是Java编程语言里，一种用于实现远程过程调用的应用程序编程接口。它使客户机上运行的程序可以调用远程服务器上的对象。远程方法调用特性使Java编程人员能够在网络环境中分布操作。RMI全部的宗旨就是尽可能简化远程接口对象的使用。

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

3，Tuscany是Apache 的开源项目，是一套开源的SCA框架模型，是做SOA的基础架构。

4，Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC（一种远程调用） 分布式服务框架（SOA），致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

5，除了上面四点介绍的不同，Spring RMI，Spring Cloud，Tuscany，Dubbo使用方式不同。

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

1，常见的负载均衡的软件有：Nginx，LVS, Spring Cloud Loadbalancer(过去的Spring Cloud Netflix Ribbon）硬件F5等。

（1）服务器的负载均衡，代表是Nginx。客户端所有的请求都会交给Nginx，然后由Nginx实现转发请求，即负载均衡是由服务端实现的。

（2）本地负载均衡，在Spring Cloud是Loadbalancer(过去是Spring Cloud Netflix Ribbon）。在调用服务接口的时候，会在注册中心上获取注册信息服务列表之后缓冲到JVM本地，从而在本地实现RPC远程服务调用技术。

2，实现动态添加服务一般需要实现以下功能，往往有一个注册中心进行：服务注册、接收服务心跳、服务剔除、服务下线。这样可以提供新服务时候，注册。监测服务是否目前能使用，定期接收分析目前注册正常的服务的心跳。服务不正常的时候及时剔除下线。用固定的名字，比如String类型的服务名替代提供相同服务的所有服务的ip（可以是单个服务，可以是多个服务组成的集群），客户不知道具体哪个服务是新来添加，哪个是失效剔除，都是向注册中心请求相同的String类型的服务名，使用能使用的服务。动态添加删除服务可以按照自己的逻辑进行添加删除服务。

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

这个内部项目使用的Scallop参考别人的回答。

（1）Scallop是提供注册中心服务的一个软件。

（2）scallop 的资源中心db里记录了每个rmi名和host以及端口信息，通过注册名找到对应service及其调用的host地址、端口返回给client，client根据资源中心的信息去进行service调用，需要配置好host指向。

3,任务九小结

使用Spring Cloud实现任务，我选用的是任务三。把任务三的一部分做成放在Spring Cloud上。

我首先看了中文在某个工程师文化主导的公司的搜索引擎，搜索到的前5的Spring Cloud，工程教程等关键字的学习笔记。由此我知道了Spring Cloud Netflix组件。

有一位波兰小哥写的piggymetrics项目高星，中文英文互联网一直推荐，我当然不免俗的去看了，也知道了Spring Cloud Netflix的经典。我也把使用场景看了，确实重要功能都考虑到都实现了。这个项目还是影响了我如何呈现我觉得应该呈现的Spring Cloud的部分。

但是注意到Spring Cloud从2020版本开始变坏很大，并且2020和以前的版本很不兼容（incompatibility）。我参考了现在VMware对这个项目的维护，果断把一定要做的客户端负载均衡用LoadBalancer完成。

OpenFeign的使用。还可以加入Spring Cloud其它的组件。

问题，困惑，疑难：

分布式系统的部署，希望实践。首先最好有需求，需要布置到物理上就是不同的多台机器上。

如果版本更新不慢，一个星期至少发布一次新版本，能成功部署。成功回滚。

要更新的包很多，更新的时间不一样。

甚至灰度更新，都希望有实践。

4，回顾任务一到任务九的深度思考。总结项目

任务一是一个没有controller的项目。

任务二加入了controller。

任务三分析更复杂的需求，艺术家的网站，写出后端。

任务四有了前端页面。

任务五有了拦截，session, cookie, token这些重要概念。

任务六引入压力测试，非关系型数据库。

任务七手机验证码验证，电子邮件验证，头像上传，文件迁移。

任务八Spring RMI调用，把项目拆分成service和带前端。

任务九使用Spring Cloud，使用微服务。

二，今天问题

任务九因为Spring Cloud的产品多，可以加入很多功能。

要和葡萄藤公司讨论，也许会有下一步进展。不止是任务九希望达到的要求。

分布式系统的部署，希望实践。首先最好有需求，需要布置到物理上就是不同的多台机器上。

如果版本更新不慢，一个星期至少发布一次新版本，能成功部署。成功回滚。

要更新的包很多，更新的时间不一样。

甚至灰度更新，都希望有实践。

三，今天的收获

Dubbo，Redis和Zookeeper概念，对比。

Eureka等Spring Cloud的概念

SOA,SCA,微服务概念梳理

Spring RMI，Tuscany对比

动态添加服务

Scallop内部使用

四，明天的计划

和葡萄藤公司讨论

葡萄枝子要多结果子