今天给各位分享springcloud部署服务器的知识，其中也会对Docker项目部署经验进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
一、SpringCloud***Docker项目部署经验
1. Linux服务器安装宝塔面板
2.使用ssh root@ip的方式远程连接
3.安装Docker,参考: 中的Docker安装
1.项目中 eureka配置需加上: prefer-ip-address: true具体配置列如:
2.其余微服务的yml文件中也需配置:prefer-ip-address: true具体配置列如:
3.微服务的pom.xml文件,配置打包插件,具体配置列如:
4.编译项目并打包,使用idea自带的打包方式:右侧M*en按钮->项目[root]->双击package->打包成功,获取jar包;
1.在服务器非系统盘符中(如果有)创建对应文件夹,以项目为例如下:
1) mhxs-eureka-server(eureka注册与发现)
2) mhxs-web-ment-api(客户端)
3) mhxs-web-novel-api(客户端)
4) mhxs-web-user-api(客户端)
5) mhxs-gateway(网关zuul,集成了swagger2)
2.上传对应的jar文件到对应对应的文件夹中.
3.在对应文件夹中的分别创建Dockerfile文件,并编辑内容例如:
注1:其中微服务jar包修改了版本(如:xx-1.jar,xxx-2.jar,xxx-3.jar,....),对应文件夹下的同理修改,目的是为了方便后期版本回退.
注2:注意修改对应的jar名称和端口
4.编写创建镜像的脚本文件: build_images.sh和相应jar文件夹一级,具体内容列如:
注:其中modules中的为对应的 jar文件夹名称
5.使用ssh连接到linux服务器,进入到build_image.sh文件夹下,创建Docker镜像,操作如下:
6.查看镜像
7.在jar包文件夹同一层中创建启动镜像脚本:start_services.sh具体内容例如:
注1:其中CODE用于检测对应服务是否已经启动成功,需根据具体项目修改.
注2:启动方式分为全顺序启动和非全顺序启动
8:查看镜像容器:
9:更新jar:
10.查看日志，有两种方法
1）通过宝塔面板可以找到对应日志位置：
2）使用命令查看
二、spring cloud和dubbo哪个会被淘汰
个人觉的两者都不会被淘汰，但是在未来分布式微服务解决方案中或者架构中，springCloud会占主导地位。
springCloud：
1.springCloud提供了完成的分布式解决方案，基础解决方案以及组件比较健全，而且最近几年围绕springCloud边缘服务组件越来越多，例如：nacos。
2.springCloud是基于springboot的，spring的使用部署太方便了。
dubbo：
1.dubbo更多解决的是服务间的调用，也就是服务通讯协议rpc，也会是dubbo没有完整的分布式解决方案基础设施。例如：注册中心需要借助Zookeper，链路追踪：zipkin。
要说Dubbo，算是Spring Cloud的一个子集好了,大致相当于Spring Cloud里的 Eureka+ Feign+ 1/2Hystrix另外
现在大公司也在慢慢想springCloud服务过度，还有面试中文springCloud问题越来阅读，dubbo越来越少。
dubbo生态圈没有spring cloud好，会被先淘汰掉。现有架构都会优先选择Spring cloud，毕竟使用起来更简单一点。
微服务现在是一阵风而已，实际来说，很多系统不适用，综合算下来，微服务成本比原来大多了。不是所有系统都是互联网，都是弹缩*很强。有的系统就是固定数据量，稳定运行，可能几个大一点服务器就足够了。
真正需要微服务的不会像现在看到的那么多。
慢慢沉淀，估计会把一些不需要的改回去，套壳的改回去。
如果简化方式，感觉dubbo这种轻便的有优势，开发运维都简单。或者替代品也是轻便为主。
剩的可能真的需要微服务，一般都是中等规模以上的，或者巨头，一般都有自己的内部框架。这种用也得全套完善的。
它们都淘汰也是早晚的事[捂脸]毕竟是j*a闭源。随着service mesh的兴起，isito的落地并于k8s的无缝融合，一切像基础设施下沉[呲牙]
事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。
以服务调用的方式，固然可以有更好的复用*，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：
第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。
第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。
第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用*等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用*。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。
第四种，就更进一步，即以独立的系统存在，该系统具有独立*和完备*，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，*系统，核心系统等。
因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特*的实现，否则就是过犹不及，最后导致整体出现问题。
个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。
分层是计算机科学永恒的主题，service mesh是微服务的未来，这样看来这两个以后都会被取代，只有spring boot能够继续存活。
这是两个作用和使用场景不同的框架，目前的情况来看都不会被淘汰。
springcloud用于微服务，dubbo用于服务治理，各有各的适用场景。
在国外springcloud使用的多，在国内dubbo使用的多。
springcloud由国外的spring团队开发维护，热度和可靠*不用多说，dubbo由国内的阿里巴巴开发，现交由Apache孵化器，可靠*也很高。
Spring cloud是当前主流的微服务架构，轻便，插件式的设计理念很赢得当前开发及企业的青睐，在很多方面优于dubbo的架构设计，我认为dubbo最终会被淘汰，但短时间内不会，因为很多金融机构之前很多系统用的是dubbo架构，金融机构在短时间内考虑系统和业务的稳定*不会立刻就更新换代
dubbo
对内rpc，对外，dubbo效率比client高很多
三、SpringCloud—网关简述
API网关的出现的原因是微服务架构的出现，不同的微服务一般有不同的网络，而外部客户端可能需要调用多个服务的接口才能完成完成一个业务需求，如果让客户端与各个微服务通信，会出现以下的问题。
以上的问题可以借助API网关来解决。API网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过API网关这一层。也就是说，API网关可以完成安全、*能、监控等功能，而服务提供者可以专门的完成具体的业务逻辑。
在生产环境中，一般需要部署高可用的API网关集群来避免单点故障，这里有两种部署方案。（以Zuul举例）
这种情况是比较简单的，即多个Zuul客户端注册到Eureka Server上，就可以实现Zuul的高可用。Zuul客户端会从Eureka Server查询Zuul Server列表，然后使用负载均衡组件（Ribbon）请求Zuul集群。
假如我们的客户端是手机APP，那么是客户端是不能注册到Eureka Server上。这种情况下，我们可以使用额外的负载均衡器来实现Zuul的高可用，例如Nginx，F5等。
相关nginx请参考： nginx从入门到精(fang)通(qi)
客户端将请求发送到负载均衡器，负载均衡器将请求转发到其代理的其中一个Zuul节点上。这样就实现了Zuul节点的高可用。
API网关*能分析