Docker 学习教程【面试+工作】 1. 了解docker 1.1. 思考 我们之前是如何将项目发布到Linux服务器的？ 大致步骤如下： 1、 安装jdk 2、 安装tomcat 3、 将项目war包上传到tomcat的webapps下 4、 修改配置文件 5、 启动tomcat 这样看似没问题，其实我们想想，发一台机器还好，这几步就完成了，如果我们要将这个项目发布到N多台机器，那么我们是否需要在每个机器上都进行相同的步骤，并且要进行环境兼容性的测试。 再来看一个例子，我们现在想部署使用一个成熟的产品
问题描述: 权限维护模块从前台获取数据后传输到后台后，在逻辑处理时把获取的参数值，过滤掉 id。导致项目出现修改错误。
3.安装eureka——运行dokcer镜像安装 (1)构建eureka的镜像，网易云的docker镜像比较全一些，也可以去https://hub.docker.com/拷贝下
亚马逊提供了一个负载均衡工具 Elastic Load Balancer，但针对的是终端用户 Web 流量服务器，而 Eureka 针对的是中间层服务器的负载均衡。AWS 固有的环境，对 IP 地址、主机名等传统的负载均衡支持并不好，并且需要更加复杂的注册/退出机制。Eureka 填补了这一空白。本文在前边几篇博客的基础上，较为系统地介绍一下 Eureka。 Eureka 是什么 官方给出的具体定义是"Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers."，翻译过来就是："Eureka 是一个基于 REST 的服务，它主要是用于定位服务，以实现 AWS 云端的负载均衡和中间层服务器的故障转移"。 Eureka VS ELB 亚马逊 ELB 针对的是终端用户 Web 流量服务器，Eureka 针对的是中间层服务器。 Why Eureka？ AWS 对 IP 地址、主机名等传统的负载均衡支持并不好，并且需要更加复杂的注册/退出机制。AWS 并没有提供一个中间层负载均衡器，Eureka 填补了这一空白。 Eureka 的适用场景
选型 对于数量众多的微服务，手动部署无疑是非常麻烦的做法，并且容易出错。所以我们这里学习如何自动部署，这也是企业实际开发中经常使用的方法。
构建部署流水线能让我们自动化地进行程序构建和部署。在这篇文章中，我们选择GitHub作为源代码管理仓库，构建引擎选择Jenkins，使用Docker作为部署引擎。
一、maven配置 <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <gro
在前面的示例中， Eureka Server 是允许匿名访问的， 本节来构建一个需要登录才能访问的 Eureka Server。
1、Eureka单机版的话，可能会出现单点故障，所以要保障Eureka的高可用，那么可以进行搭建Eureka的集群版。
最后我们在rancher上部署eureka和config项目，首先我们需要在本地创建这两个项目的docker镜像，然后推送到网易云镜像仓库上。
在分布式环境中Eureka做为注册中心存在，承担着各个服务的注册与发现，是非常核心的组件，所以如果Eureka环境挂了，那么我们的整个系统也就不稳定了，所以我们要保证我们的Eureka是高可用的，本文来介绍下Eureka的集合搭建。
我们针对于HongHu cloud的eureka项目做以下构建，整个构建的过程很简单，我会将每一步都构建过程记录下来，希望可以帮助到大家：
1.通常我们部署的eureka节点多于两个，根据实际需求，只需要将相邻节点进行相互注册(eureka节点形成环状)，就达到了高可用性集群，任何一个eureka节点挂掉不会受到影响。
在SpringCloud教程文章的 SpringCloud详细教程 | 第一篇：服务的注册与发现Eureka(Greenwich版本)实现Eureka的服务注册与发现,Eureka 作为注册中心，必须保障高可用，否则会直接影响有关的整个服务体系。介绍了服务注册与发现，其中服务注册中心Eureka Server，是一个实例，当成千上万个服务向它注册的时候，它的负载是非常高的，这在生产环境上是不太合适的,需要搭建集群实现互相注册,防止其中一个服务挂掉影响整个服务体系
在Spring Cloud（1）——服务注册中心这篇文章中，我们已经搭建好一个单机的注册中心。这篇文章要做的就是把单机版的注册中心改造为高可用集群模式。
版权声明：欢迎转载，请注明出处，谢谢。 https://blog.csdn.net/boling_cavalry/article/details/90578934
笔者不想直接用专业的术语来说明“微服务注册与发现”，所以我们来看生活中的一个案例：“公益图书馆”。
Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
详情参考： https://blog.csdn.net/qinaye/article/details/82840625
本系列是 Spring Cloud 微服务实战系列教程。之前在 《Spring Cloud Eureka 入门 （一）服务注册中心详解》 聊过 Spring Cloud Eureka。那今天聊聊阿里开源的 Nacos ~
Docker是指容器化技术，用于支持创建和使用 Linux容器。借助 Docker，我们可将容器当做轻巧、模块化的虚拟机使用。同时，还将获得高度的灵活性，从而实现对容器的高效创建、部署及复制，并能将其从一个环境顺利迁移至另一个环境。
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。 github地址为： https://github.com/ctripcorp/apollo 该项目提供了两种部署方式：本地部署和分布式部署。生产环境建议使用“分布式部署”。 因最近项目有使用配置中心的需求，在综合分析了apollo、Qconf、SpringCloud Config等一系列分布式配置中心后，初步选定apollo。 官方提供的分布式部署架构适合大规模集群环境。在其总体架构基础上做了精简，力求先跑起来，给开发部门提供环境，测试。
Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot 的开发风格做到一键启动和部署。Spring Cloud 并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
目前业界主流的负载均衡方案可分成两类： 第一类：集中式负载均衡, 即在 consumer 和 provider 之间使用独立的负载均衡设施(可以是硬件，如 F5, 也可以是软件，如 nginx), 由该设施负责把 访问请求 通过某种策略转发至 provider； 第二类：进程内负载均衡，将负载均衡逻辑集成到 consumer，consumer 从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的 provider。Ribbon 就属于后者，它只是一个类库，集成于 consumer 进程，consumer 通过它来获取到 provider 的地址。
我们在之前的章节SpringCloud组件：搭建Eureka服务注册中心学习到了单个服务注册中心的创建，不过单模式的部署方式在实战中确实不太提倡，因为有很多种原因可能会导致服务注册中心宕机，如果宕机就会有一些灾难性的问题出现，所以保证服务注册中心处于活着运行状态显得尤为重要！！！
1.1 首先请确认你的电脑是windows10专业版或企业版，只有这只有这两个版本才带有hyper-v
这个需求应该也比较常见，在不同的条件下创建不同的bean，具体场景很多，能看到这篇的肯定懂我的意思。
我们一直在使用Eureka进行注册服务，然而你有可能很少关心服务在注册到Eureka Server时是采用的主机名的方式？还是IP地址的方式？
注册中心在分布式应用中是经常用到的，也是必不可少的，那注册中心，又分为以下几种：eureka（springcloud推荐的），zookeeper（与dubbo无缝结合），consul（HashiCorp开源），nacos（阿里开源的）；
步骤i同 将EurekaClient端8001注册进EurekaServer成为服务提供者provider ！！！
服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心;
服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。
谈到服务治理，就不得不小了解一下CAP理论 ，因为一般都是分布式框架，才会有服务治理的概念，而CAP理论是分布式架构中重要理论
如果对配置中心完全没有过了解的，可以先移步去了解一下常用的开源配置中心组件，如: SpringCloud Config和Nacos等。
Spring Cloud是一个相对比较新的微服务框架，2016年才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。
本章节参考 eureka-server 的 代码仓库，并着重从容器化部署的角度来理解 Spring Cloud eureka-server 以及 OCP 中 eureka-server 的配置文件。
微服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。
随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？
Kubelets 通过调用以下三种类型的 Pod中的 Handler 进行健康检查：
微服务设计、前后端分离、高可用、易扩展、易维护、统一配置、令牌限流、服务熔断、链路追踪、docker容器部署、rancher容器管理、自动化运维
eureka官方已经正式宣布：自2.0起不再维护该项目，并在github 项目wiki上放出了一段吓唬人的话:
对于注册中心，在写这篇文章前，我其实只对ETCD有比较深入的了解，但是对于Zookeeper和其它的注册中心了解甚少，甚至都没有考虑过ETCD和Zookeeper是否适合作为注册中心。
Spring Cloud是目前用于开发微服务的主流框架之一，我们都知道在微服务架构中最为基础、核心的模块，就是服务注册与发现。
https://www.cnblogs.com/you-men/category/1789332.html
Maven项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的项目管理工具软件
最近在进行重构一个新项目，为了后续更好的落地，适应于日新月异的技术更新，进行了各方的技术选型及技术预研，最终选型基于微服务架构体系进行开发重构。项目构建前最重要的一步就是要想清楚，整体的部署架构、高可用性(HA)等等，做好前期的部署架构技术调研，确定最终方案。
在Nacos的GitHub页面，提供有下载链接，可以下载编译好的Nacos服务端或者源代码：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
