企业微服务架构实践.pdf

企业微服务架构实践 1 美丽好车的微服务实践是基于 Spring Cloud 体系来做的， 在具体的开发过程中遇到了不少问题， 踩 了不少坑， 对于微服务也有了实际的切身体会和理解， 而不再是泛泛而谈。 在整个 Spring Cloud 技 术栈中，基于不同职责需要， 我们选择了相应组件来支持我们的服务化， 同时配合 Swagger 和 Feign 实现接口的文档化和声明式调用，在实际开发过程中极大地降低了沟通成本，提高了研发联调和测试 的效率。 从应用架构来看， 正是由于基于 Spring Cloud 来实现， 整个系统完全秉承了微服务的原则， 无论是 Spring Cloud 组件还是业务系统，都体现了服务即组件、独立部署、去中心化的特性，由此提供了 快速交付和弹性伸缩的能力。 2 接下来我们基于各个组件具体介绍一下美利好车的微服务实践，首先最基本的就是 Eureka ，其承载 着微服务中的服务注册和服务发现的职责，是最基础的组件，必然有高可用的要求。 基于高可用的 Eureka 集群实现服务发现 3 美利好车在生产实践中部署了一个三节点的 Eureka Server 的集群，每个节点自身也同时基于 Eureka Client 向其它 Server 注册，节点之间两两复制，实现了高可用。在配置时指定所有节点机 器的 hostname 既可，即做到了配置部署的统一，又简单实现了 IP 解耦，不需要像官方示例那样 用 profile 机制区分节点配置。这主要是由于 Eureka 节点在复制时会剔除自身节点，向其它节点 复制实例信息，保证了单边同步原则：只要有一条边将节点连接，就可以进行信息传播和同步。在生 产环境中并不要过多调整其它配置，遵循默认的配置既可。 服务发现 4 作为服务提供者的 Eureka Client 必须配置 register-with-eureka 为 true ，即向 Eureka Server 注册服务，而作为服务消费者的 Eureka Client 必须配置 fetch-registry=true ，意即从 Eureka Server 上获取服务信息。如果一个应用服务可能既对外提供服务，也使用其它领域提供的服务，则 两者都配置为 true ，同时支持服务注册和服务发现。由于 Ribbon 支持了负载均衡，所以作为服务 提供者的应用一般都是采用基于 IP 的方式注册，这样更灵活。 健康检查 在开发测试环境中，常常都是 standlone 方式部署，但由于 Eureka 自我保护模式以及心跳周期长 的原因，经常会遇到 Eureka Server 不剔除已关停的节点的问题，而应用在开发测试环境的启停又 比较频繁，给联调测试造成了不小的困扰。为此我们调整了部分配置让 Eureka Server 能够迅速有 效地踢出已关停的节点，主要包括在 Server 端配置关闭自我保护 (eureka.server.enableSelfPreservation=false) ，同时可以缩小 Eureka Server 清理无效节点的时 间间隔（ eureka.server.evictionIntervalTimerInMs=1000 ）等方式。 另外在 Client 端