微服务系统设计方案
1.微服务本质
微服务架构从本质上说其实就是分布式架构，    与其说是一种新架构，    不如说是一种 微服
务架构风格。
简单来说， 微服务架构风格是要开发一种由    微服务项目技术架构多个小服务组成    的应用。 每个服务运 行于独
立的进程 ，并且采用 轻量级交互 。多数情况下是一个 HTTP 的资源 API。这些服务 具备独立业务能力 并可以通过 自动化部署 方式 独立部署 。这种风格使 最小化集中管理 ，从而可以使用多种 不同的编程语言和数据存储技术 。
对于微服务架构系统，    由于其服务粒度小，    模块化清晰， 因此首先要做的是对系    统整体
进行功能、服务规划 ，优先考虑如何在交付过程中，从 工程实践出发，组织好代码结构、配置、测试、部署、运维、监控 的整个过程，从而有效体现微服务的独立性与可部署性。
本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。
理解微服务架构和理念是核心。
2.系统环境

名称
版本
说明

JDK
1.8

Spring Boot
Spring Framework
Ribbon
kafka
RabbitMQ

3.微服务架构的挑战
可靠性：
由于采用远程调用的方式， 任何一个节点、 网络出现问题， 都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。
也就是没有充分的保障机制，则单点故障会大量增加。
运维要求高：
系统监控、高可用性、自动化技术
分布式复杂性：
网络延迟、系统容错、分布式事务
部署依赖性强：
服务依赖、多版本问题
性能（服务间通讯成本高）    ：
无状态性、进程间调用、跨网络调用
数据一致性：
分布式事务管理需要跨越多个节点来保证数据的瞬时一致性， 因此比起传统的单体架构的事务，成本要高得多。另外， 在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。
重复开发：
微服务理念崇尚每个微服务作为一个产品看待，    有自己的团队开发，    甚至可以有自
己完全不同的技术、 框架， 那么与其他微服务团队的技术共享就产生了矛盾， 重复开发的工作即产生了。

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