基于SpringCloud 微服务系统设计方案
微服务系统设计方案
1.微服务本质
微服务架构实际上是一种微服务架构风格，它是分布式架构的一种，由多个小服务组成应用。每个服务运行在独立的进程中，并采用轻量级交互，通常是一个HTTP的资源API。这些服务具备独立业务能力，并且可以通过自动化部署方式独立部署。这种风格使得集中管理最小化，从而可以使用多种不同的编程语言和数据存储技术。对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。理解微服务架构和理念是核心。
2.系统环境
名称：JDK、Spring Boot、Spring Framework
版本：1.8
说明：Ribbon、XXX、RabbitMQ
3.微服务架构的挑战
微服务架构面临的挑战主要包括可靠性、运维要求高、分布式复杂性、部署依赖性强、性能（服务间通讯成本高）和数据一致性。由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。因此，必须有充分的保障机制，否则单点故障会大量增加。此外，微服务架构还需要系统监控、高可用性和自动化技术，以及考虑网络延迟、系统容错、分布式事务等分布式复杂性问题。服务依赖、多版本问题也是部署依赖性强的挑战。无状态性、进程间调用、跨网络调用等问题也会导致性能问题。最后，分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。
4.架构设计
4.1.思维设计
微服务架构设计的根本目的是实现价值交付，微服务架构只有遵循DevOps理念方可进行的更顺畅，思维方式的转变是最重要的。
为了实现微服务技术架构，我们需要进行技术上的改进和相关配套服务的实现。为此，我们采用了分阶段实施和试点产品优先实施的策略。具体来说，我们的改进和实现包括以下几个方面。
首先是技术上的改进。我们采用了前后端分离的方式，通过Http/Https协议调用微服务的API网关，再通过路由服务调用相应的微服务。不同微服务之间通过REST方式互相调用，通过消息中间件实现消息交互机制。
分布式和微服务的关系其次是配套服务与功能实现。我们需要进行相应的自动化服务实现，包括自动化构建、自动化安装部署、自动化测试、自动化平台发布（Docker实现）。同时，我们还需要配套相应的监控与管理服务、日志管理服务等，以及协作服务，实现开发与运维的一体化。
针对微服务架构设计，我们把整个系统根据业务拆分成若干个子系统或微服务，每个子系统可以部署多个应用，多个应用之间使用负载均衡。我们需要一个服务注册中心Eureka，
所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。XXX可部署多个，进行高可用保证。
所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置ZUUL网关来判断一个URL请求由哪个服务处理。请求转发到服务上的时候使用负载均衡Ribbon。服务之间采用feign进行调用，使用断路器hystrix，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。
我们还需要一个监控功能，监控每个服务调用花费的时间等。使用SpringCloud Config进行统一的配置管理，需要考虑与公司的配置管理平台如何配合使用。同时，我们可以使用Hystrix Dashboard监控面板来监控各个服务上的服务调用所消耗的时间等，以及XXX监控聚合，将所有的服务实例的监控信息聚合到一个地方统一查看。
综上所述，我们的微服务技术架构设计可靠性得到了充分保证。
在设计阶段，需要考虑主备和集部署，以避免单点故障。同时，需要确认如何与公司的CAS和配置管理平台结合使用，以确保功能规划的顺利实施。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。