微服务器查ip

⑴ 无服务架构和微服务器架构的区别

微服务架构中有两个阵营，一是坚持微服务是无状态的HTTP API服务，另一阵营认为微服务本身就要求把整个系统当做一个完整的分布式应用来对待，而不是原来那种把各种组件堆积在一起，“拼接”系统的做法。
无服务架构就是原来那种把各种组件堆积在一起，拼接系统的做法。

⑵ 微服务器的简单介绍

微服务器是一种新型服务器系统，它拥有比刀片服务器更高的密度，同时能耗也更低。
它是一种比小型服务器还更小的超小型服务器。
近年来，随着处理器技术的不断创新，低功耗处理器都已呈现多核化态势，采用这种更低功耗微处理器的微服务器，也逐渐进入人们的视野。

⑶ 微服务架构是什么

微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有 Spring cloud、Dubbo 等。
微服务 Microservices 之父，马丁.福勒，对微服务大概的概述如下：就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。
六种常见的微服务架构模式：
1、聚合器微服务设计模式
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。
2、代理微服务设计模式
这是聚合模式的一个变种，在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应，在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。
4、分支微服务设计模式
这种模式是聚合器模式的扩展，允许同时调用两个微服务链。
5、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。
6、异步消息传递微服务设计模式
虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应。

⑷ IP被限制怎么办

先禁用网卡然后再启动，自己获取网络地址！当然你要是知道网关了就自己设置个不重复的地址就好了。如果别人的网关不是那种常用的，比如192.168.2.200，子网掩码也不是常规的那种，这样你就很难获取到IP了。要么是一直是被限制，要么就是一直在获取网络地址

⑸ Spring Cloud微服务升级总结

Spring Boot框架是由Pivotal团队提供的全新框架，其设计目的是用来简化基于Spring应用的初始搭建以及开发过程。SpringBoot框架使用了特定的方式来进行应用系统的配置，从而使开发人 员不再需要耗费大量精力去定义模板化的配置文件。

Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务注册，服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Boot通过@SpringBootApplication注解标识为Spring Boot应用程序。所有的应用都通过jar包方式编译，部署和运行.

每个Spring Boot的应用都可以通过内嵌web容器的方式提供http服务，仅仅需要在pom文件中依赖spring-boot-start-web即可，原则上微服务架构希望每个独立节点都提供http服务。

在Spring Boot需要启动任务时，只要继承CommandLineRunner接口实现其run方法即可。

在Spring Boot需要执行定时任务时，只需要在定时任务方法上增加@Scheled(cron = “0 15 0 **?”)注解（支持标准cron表达式），并且在服务启动类上增加@EnableScheling的注解即可。

Actuator是spring boot提供的对应用系统自身进行监控的组件，在引入spring-boot-start-web基础上引入spring-boot-starter-actuator即可。

在我们实现微服务架构时，每个微服务节点都需要自身的相关配置数据项，当节点众多，维护就变得非常困难，因此需要建立一个中心配置服务。

Spring Cloud Config分为两部分。Spring Cloud Config server作为一个服务进程，Spring Cloud Config File为配置文件存放位置。

[图片上传失败...(image-bfc9bd-1511489698023)]

服务注册的概念早在微服务架构之前就出现了，微服务架构更是把原先的单一应用节点拆分成非常多的微服务节点。互相之间的调用关系会非常复杂，Spring Cloud Eureka作为注册中心，

服务注册的概念早在微服务架构之前就出现了，微服务架构更是把原先的单一应用节点拆分成非常多的微服务节点。互相之间的调用关系会非常复杂，Spring Cloud Eureka作为注册中心，
所有的微服务都可以将自身注册到Spring Cloud Eureka进行统一的管理和访问（Eureka和Zookeeper不同，在AOP原则中选择了OP，更强调服务的有效性）

服务注册的概念早在微服务架构之前就出现了，微服务架构更是把原先的单一应用节点拆分成非常多的微服务节点。互相之间的调用关系会非常复杂，Spring Cloud Eureka作为注册中心，
所有的微服务都可以将自身注册到Spring Cloud Eureka进行统一的管理和访问（Eureka和Zookeeper不同，在AOP原则中选择了OP，更强调服务的有效性）

当我们把所有的服务都注册到Eureka（服务注册中心）以后，就涉及到如何调用的问题。Spring Cloud Zuul是Spring Cloud提供的服务端代理组件，可以看做是网关，Zuul通过Eureka获取到可用的服务，通过映射配置，客户端通过访问Zuul来访问实际需要需要访问的服务。所有的服务通spring.application.name做标识，不同IP地址，相同spring.application.name就是一个服务集群。当我们增加一个相同spring.application.name的节点，Zuul通过和Eureka通信获取新增节点的信息实现智能路由，增加该类型服务的响应能力。

与Spring Cloud Zuul的服务端代理相对应，Spring Cloud Ribbon提供了客户端代理。在服务端代理中，客户端并不需要知道最终是哪个微服务节点为之提供服务，而客户端代理获取实质提供服务的节点，并选择一个进行服务调用。Ribbon和Zuul相似，也是通过和Eureka（服务注册中心）进行通信来实现客户端智能路由。

Spring Cloud Feign是一种声明式、模板化的http客户端。 使用Spring Cloud Feign请求远程服务时能够像调用本地方法一样，让开发者感觉不到这是远程方法（Feign集成了Ribbon做负载均衡）。

1.把远程服务和本地服务做映射

应用管理中心可以对每个已经注册的微服务节点进行停止，编译，打包，部署，启动的完整的上线操作。

zookeeper数据查询中心根据zookeeper地址，端口，命令获取zookeeper数据信息。

健康检测中心周期性检查每个微服务的状态，当发现有微服务状态处于DOWN或连接超时时，触发报警

健康检测中心周期性检查每个微服务的状态，当发现有微服务状态处于DOWN或连接超时时，触发报警

我的官网

我的官网 http://guan2ye.com
我的CSDN地址 http://blog.csdn.net/chenjianandiyi
我的地址 http://www.jianshu.com/u/9b5d1921ce34
我的github https://github.com/javanan
我的码云地址 https://gitee.com/jamen/
阿里云优惠券 https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=vf2b5zld&utm_source=vf2b5zld

⑹ 微服务器 gen 10 干嘛

是运行软件应用的。
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。
微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。

⑺ 请教kubernetes部署问题，pod一直处于pending状态

我们先从整体上看一下Kubernetes的一些理念和基本架构，然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能，今后在研究和使用这个具的时候有所参考和帮助。1.Kubernetes的一些理念：用户不需要关心需要多少台机器，只需要关心软件（服务）运行所需的环境。以服务为中心，你需要关心的是api，如何把大服务拆分成小服务，如何使用api去整合它们。保证系统总是按照用户指定的状态去运行。不仅仅提给你供容器服务，同样提供一种软件系统升级的方式；在保持HA的前提下去升级系统是很多用户最想要的功能，也是最难实现的。那些需要担心和不需要担心的事情。更好的支持微服务理念，划分、细分服务之间的边界，比如lablel、pod等概念的引入。对于Kubernetes的架构，可以参考官方文档。大致由一些主要组件构成，包括Master节点上的kube-apiserver、kube-scheler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy，以及底层的网络支持（可以用Flannel、OpenVSwitch、Weave等）。看上去也是微服务的架构设计，不过目前还不能很好支持单个服务的横向伸缩，但这个会在Kubernetes的未来版本中解决。2.Kubernetes的主要特性会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限，只能简单一些了。另外，对于服务发现、高可用和监控的一些更详细的介绍，感兴趣的朋友可以通过这篇文章了解。1）网络Kubernetes的网络方式主要解决以下几个问题：a.紧耦合的容器之间通信，通过Pod和localhost访问解决。b.Pod之间通信，建立通信子网，比如隧道、路由，Flannel、OpenvSwitch、Weave。c.Pod和Service，以及外部系统和Service的通信，引入Service解决。Kubernetes的网络会给每个Pod分配一个IP地址，不需要在Pod之间建立链接，也基本不需要去处理容器和主机之间的端口映射。注意：Pod重建后，IP会被重新分配，所以内网通信不要依赖PodIP；通过Service环境变量或者DNS解决。2）服务发现及负载均衡kube-proxy和DNS，在v1之前，Service含有字段portalip和publicIPs，分别指定了服务的虚拟ip和服务的出口机ip，publicIPs可任意指定成集群中任意包含kube-proxy的节点，可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中，publicIPS被约定废除，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp,而在serviceport定义列表里，增加了nodePort项，即对应node上映射的服务端口。DNS服务以addon的方式，需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息，同时以watch的方式检查service的变动，及时收集变动信息，并将对于的ip信息提交给etcd存档，而skydns通过etcd内的DNS记录信息，开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,"tenx.domain"是提前设置的主域名。注意：kube-proxy在集群规模较大以后，可能会有访问的性能问题，可以考虑用其他方式替换，比如HAProxy，直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。3）资源管理有3个层次的资源限制方式，分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持，比如Docker对CPU、内存、磁盘、网络等的支持；Pod方面可以限制系统内创建Pod的资源范围，比如最大或者最小的CPU、memory需求；Namespace层次就是对用户级别的资源限额了，包括CPU、内存，还可以限定Pod、rc、service的数量。资源管理模型－》简单、通用、准确，并可扩展目前的资源分配计算也相对简单，没有什么资源抢占之类的强大功能，通过每个节点上的资源总量、以及已经使用的各种资源加权和，来计算某个Pod优先非配到哪些节点，还没有加入对节点实际可用资源的评估，需要自己的schelerplugin来支持。其实kubelet已经可以拿到节点的资源，只要进行收集计算即可，相信Kubernetes的后续版本会有支持。4）高可用主要是指Master节点的HA方式官方推荐利用etcd实现master选举，从多个Master中得到一个kube-apiserver保证至少有一个master可用，实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha，但仍未成熟，据了解，未来会更新升级ha的功能。一张图帮助大家理解：也就是在etcd集群背景下，存在多个kube-apiserver，并用pod-master保证仅是主master可用。同时kube-sheller和kube-controller-manager也存在多个，而且伴随着kube-apiserver同一时间只能有一套运行。5）rollingupgradeRC在开始的设计就是让rollingupgrade变的更容易，通过一个一个替换Pod来更新service，实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc，并逐步减少老的rc的复本、增加新的rc的复本，在老的rc数量为0时将其删除。通过kubectl提供，可以指定更新的镜像、替换pod的时间间隔，也可以rollback当前正在执行的upgrade操作。同样，Kuberntes也支持多版本同时部署，并通过lable来进行区分，在service不变的情况下，调整支撑服务的Pod，测试、监控新Pod的工作情况。6）存储大家都知道容器本身一般不会对数据进行持久化处理，在Kubernetes中，容器异常退出，kubelet也只是简单的基于原有镜像重启一个新的容器。另外，如果我们在同一个Pod中运行多个容器，经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。Docker也有Volume的概念，但是相对简单，而且目前的支持很有限，Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念：Volume只是一个目录，并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样，后端用什么介质和里面的内容则由使用的特定Volume类型决定。创建一个带Volume的Pod：spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛，有很多贡献者为其添加不同的存储支持，也反映出Kubernetes社区的活跃程度。emptyDir随Pod删除，适用于临时存储、灾难恢复、共享运行时数据，支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源（比如本地Docker）。gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。rbd-RadosBlockDevice-Cephsecret用来通过KubernetesAPI向Pod传递敏感信息，使用tmpfs（aRAM-backedfilesystem）persistentVolumeClaim-从抽象的PV中申请资源，而无需关心存储的提供方glusterfsiscsigitRepo根据自己的需求选择合适的存储类型，反正支持的够多，总用一款适合的:)7）安全一些主要原则：基础设施模块应该通过APIserver交换数据、修改系统状态，而且只有APIserver可以访问后端存储（etcd）。把用户分为不同的角色：Developers/ProjectAdmins/Administrators。允许Developers定义secrets对象，并在pod启动时关联到相关容器。以secret为例，如果kubelet要去pull私有镜像，那么Kubernetes支持以下方式：通过dockerlogin生成.dockercfg文件，进行全局授权。通过在每个namespace上创建用户的secret对象，在创建Pod时指定imagePullSecrets属性（也可以统一设置在serviceAcouunt上），进行授权。认证（Authentication）APIserver支持证书、token、和基本信息三种认证方式。授权（Authorization）通过apiserver的安全端口，authorization会应用到所有http的请求上AlwaysDeny、AlwaysAllow、ABAC三种模式，其他需求可以自己实现Authorizer接口。8）监控比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里，cadvior功能被集成到了kubelet组件中，kubelet在与docker交互的同时，对外提供监控服务。Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend（如influxdb）构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里，也可以单独运行以standalone的方式。注意：heapster目前未到1.0版本，对于小规模的集群监控比较方便。但对于较大规模的集群，heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息，信息在内存的临时存储成为问题，再加上heaspter要支持api获取临时metrics，如果将heapster以pod方式运行，很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。

⑻ 基于docker部署的微服务架构（二）： 服务提供者和调用者

前一篇 基于docker部署的微服务架构（一）：服务注册中心 已经成功创建了一个服务注册中心，现在我们创建一个简单的微服务，让这个服务在服务注册中心注册。然后再创建一个调用者，调用此前创建的微服务。

新建一个maven工程，修改pom.xml引入 spring cloud 依赖:

在 resources 目录中创建 application.yml 配置文件，在配置文件内容:

这里eureka的注册地址为上一篇中设置的defaultZone。
在 java 目录中创建一个包 demo ，在包中创建启动入口 AddServiceApplication.java

在demo包下新建一个子包controller，在controller子包下创建一个controller对外提供接口。

在服务注册中心已经运行的情况下，运行 AddServiceApplication.java 中的 main 方法，启动微服务。
访问服务注册中心页面 http://localhost:8000 ， 可以看到已经成功注册了 ADD-SERVICE-DEMO 服务。

启动第二个实例，修改端口为 8101 ，修改 AddController.java 中的输出信息为

再次运行 AddServiceApplication.java 中的 main 方法。
访问服务注册中心页面 http://localhost:8000 ， 可以看到已经成功注册了两个 ADD-SERVICE-DEMO 服务，端口分别为 8100 和 8101 。

新建一个maven工程，修改pom.xml引入 spring cloud 依赖:

在 resources 目录中创建 application.yml 配置文件，在配置文件内容:

在 java 目录中创建一个包 demo ，在包中创建启动入口 RibbonClientApplication.java

这里配置了一个可以从服务注册中心读取服务列表，并且实现了负载均衡的 restTemplate 。

在demo包下新建一个子包controller，在controller子包下创建一个controller对外提供接口。

可以看到这里的请求url用了服务注册中心对应的 Application 。

运行 RibbonClientApplication.java 中的 main 方法，启动项目。
在浏览器中访问 http://localhost:8200/add?a=1&b=2 ，得到返回结果：

多次访问，查看 AddServiceApplication 的控制台，可以看到两个 ADD-SERVICE-DEMO 被负载均衡的调用。
demo源码 spring-cloud-1.0/ribbon-client-demo

新建一个maven工程，修改pom.xml引入 spring cloud 依赖:

在 resources 目录中创建 application.yml 配置文件，在配置文件内容:

在 java 目录中创建一个包 demo ，在包中创建启动入口 FeignClientApplication.java

在demo包下新建一个子包service，在service子包下创建一个接口 AddService.java 调用之前创建的微服务 ADD-SERVICE-DEMO 。

这里 @FeignClient 注解中的参数为服务注册中心对应的 Application 。

在demo包下再新建一个子包controller，在controller子包下创建一个 FeignController.java 对外提供接口。

FeignController 里注入了刚才创建的 AddService 接口。

运行 FeignClientApplication.java 中的 main 方法，启动项目。
在浏览器中访问 http://localhost:8300/add?a=1&b=2 ，得到返回结果：

多次访问，查看 AddServiceApplication 的控制台，可以看到两个 ADD-SERVICE-DEMO 被负载均衡的调用。
demo源码 spring-cloud-1.0/feign-client-demo

以 add-service-demo 为例，
复制 application.yml ，重命名为 application-docker.yml ，修改 defaultZone 为：

这里修改了 defaultZone 的访问url，如何修改取决于部署docker容器时的 --link 参数， --link 可以让两个容器之间互相通信。

修改 application.yml 中的 spring 节点为：

这里增加了 profiles 的配置，在maven打包时选择不同的profile，加载不同的配置文件。

在pom.xml文件中增加：

选择 docker profile，运行 mvn install -P docker ，打包项目并生成docker镜像， 注意docker-maven-plugin中的 <entryPoint> 标签里的内容不能换行，否则在生成docker镜像的时候会报错 。
运行成功后，登录docker节点，运行 docker images 应该可以看到刚才打包生成的镜像了。

在前一篇中，已经创建了一个 service-registry-demo 的docker镜像，这里先把这个镜像运行起来。

对这条命令做个简单说明， -d 指定当前容器运行在后台， --name 指定容器名称， --publish 指定端口映射到宿主机， --volume 这个挂载是为了解决容器内的时区和宿主机不一致的问题，让容器使用宿主机设置的时区，最后指定使用的docker镜像，镜像名称和标签需要根据自己的情况做修改。
运行这条命令之后， service-registry-demo 的容器就启动了。访问 http://宿主机IP:8000 ，打开注册中心的页面。
下边启动 add-service-demo 容器，

这条命令和上一条差不多，只是增加了一个 --link 参数， --link 指定容器间的连接，命令格式 --link 容器名:别名 ，这里连接了之前创建的名为 service-registry-demo 的容器，这里的别名和 application-docker.yml 文件中配置的 defaultZone 一致。其实就是通过别名找到了对应的容器IP，进到容器里查看 hosts 文件就明白了，其实就是加了条hosts映射。
add-service-demo 容器启动成功之后，刷新配置中心的页面，发现已经注册到配置中心了。