将Spring Boot微服务部署到容器平台方案.docx

? ? ? ? ? ? ? 将 Spring Boot 微服务部署到容器平台方案 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  相关场景如下： Spring Cloud 微服务系统已经提前搞好了，并没有运行在容器平台上，而是直接运行在虚机上。这次就是结合Spring Boot的组件和K8S (OpenShift)的相关概念和优势 ，将其迁移部署到容器平台上。 Spring Boot 全家桶及替代品 备注：替代品请关注K8S的相关替代品，本次主要目的是结合Spring Boot的组件和OpenShift的相关概念和优势。 框架 虽然调用微服务通常是通过HTTP发送JSON或XML payload这样简单的事情，但是各种各样的考虑导致了专用客户端库的流行，特别是在Spring Boot环境中。这些库不仅提供与Spring Boot的集成，还提供与微服务体系结构中经常需要的许多其他工具和库的集成。 Ribbon Ribbon 是一个具有内置客户端负载均衡的进程间通信(RPC)库。主要的使用模型包括REST调用和各种序列化方案支持。 这次的实例程序只使用Ribbon的最基本功能。因为Ribbon 就是Spring Boot框架全家桶的一员. 服务注册 微服务体系架构通常意味着在私有、混合或公共云中对单个服务进行动态扩展，其中主机的数量和地址不能总是预先预测或静态配置。(说人话, 微服务经常会横向动态扩展.) 解决方案是使用服务注册中心作为发现每个服务的已部署实例的起点。这通常由客户端库或负载均衡层进行匹配，当发现实例不再存在时，该层会无缝地进行故障转移，并更新服务注册表查找的缓存。更进一步说，客户机库和服务注册中心之间的集成可以使查找和调用过程成为单个步骤，并且对开发人员是透明的。 在现代云环境中，这种功能通常由平台提供（说人话: 这个应该由我K8S来做! 你框架做的太多了），而服务复制和扩展是一个核心特性。 这次的示例构建在OpenShift之上，就用K8S的Service来做服务注册。 Eureka Eureka是一种基于REST(REpresentational State Transfer)的服务，主要用于微服务中定位服务，以实现中间层服务器的负载平衡和故障转移。 Ribbon和Eureka之间的紧密集成允许在调用者使用Ribbon库时声明性地使用Eureka. 负载均衡 对于客户端对无状态服务的调用，高可用性(HA)意味着需要从服务注册中心查找服务，以及可用实例之间的负载平衡。前面提到的客户端库包括合并这两个步骤的功能，但是容器平台通过在 Service 抽象概念中包含负载平衡功能，使得这两个操作变得多余。OpenShift提供一个单一地址，在这个地址中，调用将被负载平衡并重定向到适当的实例。(说人话: Spring Boot虽然提供了库, 但还是要写代码的; 容器平台直接提供Service, Service自动在实例间负载均衡. 对于开发来说, 就是只用配一个Service地址, 就可以负载均衡). Ribbon Ribbon 允许在声明的静态实例列表之间进行负载均衡，或者在注册表查找中发现服务的任意多个实例之间进行负载均衡。 断路器 微服务的高度分布式特性意味着远程调用失败的风险更高，因为此类远程调用的数量增加了。断路器模式可以通过隔离有问题的服务和避免破坏性超时来帮助避免这类故障的级联。 Hystrix Hystrix是一个延迟处理和故障转移功能库，旨在隔离远程系统、服务和第三方库的访问点，中止级联故障，并在不可避免的复杂分布式系统中启用弹性。 Hystrix实现了断路器和 bulkhead 模式。 外部化配置 外部化配置管理解决方案可以为配置文件、命令行参数和环境变量的典型组合提供一种优雅的替代方案，这些配置文件、命令行参数和环境变量用于使应用程序更加可移植，并减少对外部更改的响应。 Spring Cloud Config Spring Cloud Config为分布式系统中的外部化配置提供了服务器和客户端支持。有了Config Server，您就有了一个中心位置来管理跨所有环境的应用程序的外部属性。 分布式 Tracing 尽管微服务体系结构有很多优点，但是很难分析和排除故障。每个业务请求在不同的层上生成对各个服务的多个调用，以及在各个服务之间的多个调用。分布式 Tracing 将所有单独的服务调用绑定在一起，并通过惟一生成的ID将它们与业务请求关联起来。 Sleuth/Zipkin Spring Cloud Sleuth为应用程序中请求点上的每个调用和 span ID生成trace ID。这些信息可以与日志框架集成，通过跟踪日志文件来帮助解决应用程序的故障，或者广播到Zipk