基于SpringCloud微服务系统设计方案.docxVIP

微服务系统设计方案 1 微服务本质 微服务架构从本质上说其实就是分布式架构， 与其说是一种新架构， 不如说是一种 微服务架构风格。 简单来说， 微服务架构风格是要开发一种由 多个小服务组成 的应用。 每个服务运 行于独 立的进程，并且采用 轻量级交互。多数情况下是一个 HTTP 的资源 API。这些服务具备独立业务 能力 并可以通过 自动化部署 方式 独立部署。这种风格使 最小化集中管理，从而可以使用多种 不同的编程语言和数据存储技术 。 对于微服务架构系统， 由于其服务粒度小， 模块化清晰， 因此首先要做的是对系 统整体 进行功能、服务规划 ，优先考虑如何在交付过程中，从 工程实践出发，组织好代码结构、配置、测试、部署、运维、监控 的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。 理解微服务架构和理念是核心。 系统环境 名称 名称 版本 说明 JDK 1.8 Spri ng Boot Spring Framework Ribbon kafka RabbitMQ 3 微服务架构的挑战 可靠性： 由于采用远程调用的方式， 任何一个节点、 网络出现问题， 都将使得服务调用失败， 随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。运维要求高： 系统监控、高可用性、自动化技术分布式复杂性： 网络延迟、系统容错、分布式事务部署依赖性强： 服务依赖、多版本问题 性能（服务间通讯成本高） ： 无状态性、进程间调用、跨网络调用数据一致性： 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性， 因此比起传统的单体架构 的事务，成本要高得多。另外， 瞬时一致带来的系统不可用。 重复开发： 在分布式系统中，通常会考虑通过数据的最终一致性来解决数据 微服务理念崇尚每个微服务作为一个产品看待， 有自己的团队开发， 甚至可以有自 己完全不同的技术、产生了。 框架，那么与其他微服务团队的技术共享就产生了矛盾， 重复开发的工作即 没有最好的，只有最适合自己的。 4. 架构设计 思维设计 微服务架构设计的根本目的是实现价值交付， 更顺畅，思维方式的转变是最重要的。 微服务架构只有遵循 DevOps 理念方可进行的 实现微服务技术架构， 现有产品需要进行技术上的改进以及相关配套服务的实现， 采用分阶 段实施、以及试点产品优先实施的策略 ，主要包括如下： 一、技术上的改进： 1、前后端分离， web 前端通过 Http/Https协议调用微服务的 API 网关，由 API 网关再 经过路由服务调用相应的微服务 2、 不同微服务之间通过 REST 方式互相调用 3、 微服务之间通过消息中间件实现消息交互机制二、配套服务与功能实现 ： 1、 需要进行相应的自动化服务实现， 自动化平台发布（ Docker 实现） 包括自动化构建、 自动化安装部署、 自动化测试、 2、 管理服务，对于微服务架构，必须配套相应的监控与管理服务、日志管理服务等 3、 协作服务，运用 DevOps 思想提升开发、测试、运维的高效沟通与协作，实现开发 与运维的一体化 微服务架构设计 RolesSpririQCkAul： Roles SpririQCkAul： urr-k- ■bsirtK I ^ign Client WEBU I J- I I I I I I t i 1、我们把整个系统根据业务拆分成若干个子系统或微服务 3、需要一个服务注册中心 Eureka ，所有的服务都在注册中心注册，负载均衡也是通 过在注册中心注册的服务来使用一定策略来实现。 Eureka 可部署多个，进行高可用保证。 4、 所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置判断一个 URL 请求由哪个服务处理。请求转发到服务上的时候使用负载均衡 ZUUL 网关来 Ribbon 。 5、 服务之间采用 feig n进行调用。 6、 使用断路器 hystri，x 及时处理服务调用时的超时和错误， 防止由于其中一个服务的 问题而导致整 体系统的瘫痪。 7、 还需要一个监控功能，监控每个服务调用花费的时间等。 8、使用 Spri ngCloud Config进行统一的配置管理，需要考虑与公司的配置管理平台如 何配合使用。 9、 Hystrix，监控和断路器。我们只需要在服务接口上添加 Hystrix标签，就可以实现监控和断路器功能。 10 、 Hystrix Dashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。 11 、Turbine，监控聚合，使用 Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我