皮皮网

1.SpringCloud入门实战-Zookeeper、源码k源Consul注册中心
2.如何理解@Resource和@Reference的区别
3.SpringCloud技术指南系列（十一）API网关之Zuul使用
4.dubbo知识点之管理工具dubbo-admin分享
5.dubbo与springcloud的区别
6.轻松上手 Spring Boot & Kafka 实战！源码k源

SpringCloud入门实战-Zookeeper、源码k源Consul注册中心

       官网显示，源码k源由于Eureka停更，源码k源选择Zookeeper或Consul作为注册中心成为可能。源码k源dgrs系统源码

       集成Zookeeper的源码k源步骤如下：

       首先，通过参考文档安装配置Zookeeper。源码k源

       创建名为cloud-payment3的源码k源服务提供者工程，通过新建模块、源码k源修改pom、源码k源主启动、源码k源yml文件来完成。源码k源

       在pom文件中添加与Zookeeper相关的源码k源依赖。主启动类中进行相应的源码k源配置。

       yml文件中添加Zookeeper相关配置，包括服务地址等信息。战地之王源码编译

       编写PaymentController.java，并启动Zookeeper服务。

       通过浏览器访问/article/

SpringCloud技术指南系列（十一）API网关之Zuul使用

       API网关是一个更为智能的应用服务器，类似于面向对象设计模式中的Facade模式，是整个微服务架构系统的门面。它负责调度和过滤所有外部客户端的访问请求，实现请求路由、负载均衡、校验过滤等功能，并具备与服务治理框架结合、请求转发时的熔断机制、服务的聚合等高级功能。

       在SpringCloud全家桶中，API网关有Zuul和gateway两种实现。Zuul逐渐被gateway取代，但仍然可以整合进任何SpringBoot应用。官方介绍网站源码gateway基于异步非阻塞模型，使用netty+webflux实现，不能加入web依赖，默认加载加入webflux依赖。Spring Cloud zuul使用的仍是zuul 1.x，zuul 2.x也是异步非阻塞的。选用zuul还是gateway，要根据使用场景决定，如果是在已有的非WebFlux项目使用，要用zuul；如果单纯的API网关独立部署，建议使用gateway。

       代码可以在SpringBoot组件化构建的EurekaZuul、ZkZuul和ConsulZuul组件中查看，并下载。分别对应三种不同的服务注册方式。

       本篇基于服务注册发现的最新龙吟源码项目基础，以Consul + zuul为例讲解如何使用zuul做API网关。至于（Eureka + zuul）和（zookeeper + zuul）写法上和（consul + zuul）是一样的，不再分开章节描述。选择Consul + zuul为例，是因为它在配置中有一个坑，其他两个倒是没有，下面配置时会着重说明下它。

       需要在建立好的项目中引入spring-cloud-starter-netflix-zuul，并引入consul相关配置。本篇是在consul的服务发现基础上进行zuul的配置，因此还需要引入consul相关配置。

       Zuul默认整合了hystrix做熔断。当请求次数失败次数过多（服务中途挂掉，试验时是5次），将不再请求，直接返回CommonFallbackProvider配置的烟草溯源码系统内容。只要服务不可用，都会调用CommonFallbackProvider的方法返回信息，这就是服务降级。hystrix熔断是防止不断请求无效服务浪费资源，甚至影响其他服务。

       开启Zuul代理，在启动类上使用@EnableZuulProxy即可。

       我们仍可以写自己的web服务，和zuul的转发互不影响，但是路径别重复了。使用consul做注册中心时，需要进行Consul的健康检测。

       使用到的实体包括ResultModel等，详细完整的实体可以访问品茗IT-博客《SpringCloud技术指南系列（十一）API网关之Zuul使用》进行查看。品茗IT-博客专题汇总了Spring专题、Springboot专题、SpringCloud专题、web基础配置专题等。

       快速构建项目，可以使用一键快速构建Spring项目工具、一键快速构建SpringBoot项目工具、一键快速构建SpringCloud项目工具等。喜欢这篇文章，欢迎加入我们一起讨论SpringBoot使用！

dubbo知识点之管理工具dubbo-admin分享

       在dubbo的应用体系中，一直有一款图形化的rpc管理工具，通过这款管理工具，我们可以对我们的rpc服务进行各种管理操作，包括负载均衡、权重调整、服务监测等，今天我们就先来简单看下这一款管理工具。

       dubbo的管理服务，现在也是一个独立的应用，我们可以将它独立部署。项目地址如下：

       根据官方介绍，目前的管理控制台已经发布0.1版本，结构上采取了前后端分离的方式，前端使用 Vue和 Vuetify分别作为 Javascript框架和UI框架，后端采用 Spring Boot 框架。既可以按照标准的 Maven 方式进行打包，部署，也可以采用前后端分离的部署方式，方便开发，功能上，目前具备了服务查询，服务治理(包括 Dubbo 2.7中新增的治理规则)以及服务测试三部分内容。

       下面，我们看下如何在本地安装部署dubbo的管理控制台。

       首先，我们要下载dubbo-admin的源码包或者部署包，如果下载源码包的话，需要你自己打包，由于又是前后端分离的项目，所以这里我就偷个懒，直接下载部署包：

       下载完成后，直接解压，然后进入bin\config文件夹，这里有dubbo-admin的配置文件。因为后端是spring boot项目，所以这里的application.properties文件就是我们spring boot的配置文件，默认情况下，整个配置文件只有一些简单配置项：

       因为没有项目的端口配置，所以默认情况下，dubbo-admin的访问端口是，当然你也可以自行修改；

       配置文件中，首先是注册中心、配置中心、元数据中心的配置，今天我们演示的注册中心是zk，所以这里就不修改了；

       紧接着是管理平台的登录用户名和密码，默认都是root，你也可以根据自己的需要修改；

       最后面是压缩的相关配置，这里应该是请求响应内容的压缩配置，主要是针对css/js以及页面等内容。

       完成以上内容配置，我们就可以启动测序下了。首先，我们要先启动zk，然后启动我们的管理平台，直接访问我们dubbo-admin的服务地址即可，我配置的端口是，所以我访问的地址是/s/wLzA6... 提取码: ztsj

       最后，别忘了点在看、转发哦，需要你的鼓励～

Dubbo、SpringCloud和Kubernetes优缺点

       æ€»æ‰€å‘¨çŸ¥ï¼ŒDubbo、SpringCloud和Kubernetes是当前三个主流的开源框架和平台。

        服务化框架和平台的选择是搭建微服务的一个基础，非常重要。其中Dubbo是阿里巴巴开源的，SpringCloud是netflix开源的，Kubernetes是谷歌开源的。它们都是分布式微服务框架平台的一套解决办法。值得一提的是，这3种产品其功能上是有重叠的，部分功能还可能是排他的，所以说不要相互之间进行混搭使用，架构保持一致性，维护起来也方便。

        微服务的最终目的是要实现业务逻辑，实现业务价值。为了让开发人员更专注于业务逻辑的开发，通常微服务需要底层的基础设施的支撑，这些基础设施的支撑称为微服务公共关注点(Common Concerns)。如下图所示：

        服务发现与负载均衡中，dubbo主要是基于Zookeeper实现的，阿里还开源了一个产品Nacos，其功能像Java版的Consul，Nacos后续可能会替换zk成为dubbo首选的服务发现机制。

        在API网关中，阿里没有开源网关，而K8s中则是定义了名叫Ingress规范，具体可以采用不同的实现，比如说Nginx，Envoy或者Traefik。

        在配置管理中，Nacos也具备配置的功能。SpringCloud采用的是Config，其后端是基于Git进行配置管理的。

        在服务框架中，K8s是与框架无关的，只认容器，不同的语言栈都可以住在K8s中，这是最大的亮点。

        在自动伸缩和自愈方面，K8s具有自动故障和自愈的能力，自动伸缩需要引入额外的组件，完全实现是需要一定的门槛，感兴趣可以关注一下。

        在进程隔离方面，K8s是通过容器进行进程隔离的，同时还引入Pod进一步对服务进行隔离。

        在环境管理方面，K8s是内置Namespace进行逻辑隔离的，可以实现多环境，各个环境可以单独配置认证授权机制。

        在流量治理方面，这里的流量治理指的是高级的流量调度、A、B和蓝绿部署的能力。Dubbo通过zk+client是支持一定的流量调度能力的。

        Dubbo、SpringCloud是框架组件，K8s是平台。

        所以我们在理解服务的关注点，根据企业上下文考量后选择，尽量不要混搭，保持体系的一致性。

        看了大牛的分析，自己学到了很多。