基于SpringCloud-微服务系统设计方案.docx-资料库

csonline5-11589961-4744302543319569642.docx.pdf-第1页.png

第1页 / 共25页

csonline5-11589961-4744302543319569642.docx.pdf-第2页.png

第2页 / 共25页

csonline5-11589961-4744302543319569642.docx.pdf-第3页.png

第3页 / 共25页

csonline5-11589961-4744302543319569642.docx.pdf-第4页.png

第4页 / 共25页

csonline5-11589961-4744302543319569642.docx.pdf-第5页.png

第5页 / 共25页

csonline5-11589961-4744302543319569642.docx.pdf-第6页.png

第6页 / 共25页

csonline5-11589961-4744302543319569642.docx.pdf-第7页.png

第7页 / 共25页

csonline5-11589961-4744302543319569642.docx.pdf-第8页.png

第8页 / 共25页

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

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

没有最好的，只有最适合自己的。 4. 架构设计 4.1. 思维设计微服务架构设计的根本目的是实现价值交付，微服务架构只有遵循 DevOps 理念方可进行的更顺畅，思维方式的转变是最重要的。实现微服务技术架构，现有产品需要进行技术上的改进以及相关配套服务的实现，采用分阶段实施、以及试点产品优先实施的策略，主要包括如下：一、技术上的改进： 1、前后端分离，web 前端通过 Http/Https 协议调用微服务的 API 网关，由 API 网关再

经过路由服务调用相应的微服务 2、不同微服务之间通过 REST 方式互相调用 3、微服务之间通过消息中间件实现消息交互机制二、配套服务与功能实现： 1、需要进行相应的自动化服务实现，包括自动化构建、自动化安装部署、自动化测试、自动化平台发布（Docker 实现） 2、管理服务，对于微服务架构，必须配套相应的监控与管理服务、日志管理服务等 3、协作服务，运用 DevOps 思想提升开发、测试、运维的高效沟通与协作，实现开发与运维的一体化 4.2. 微服务架构设计 1、我们把整个系统根据业务拆分成若干个子系统或微服务。 2、每个子系统可以部署多个应用，多个应用之间使用负载均衡。

3、需要一个服务注册中心 Eureka，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。 Eureka 可部署多个，进行高可用保证。 4、所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置 ZUUL 网关来判断一个 URL 请求由哪个服务处理。请求转发到服务上的时候使用负载均衡 Ribbon。 5、服务之间采用 feign 进行调用。 6、使用断路器 hystrix，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。 7、还需要一个监控功能，监控每个服务调用花费的时间等。 8、使用 SpringCloud Config 进行统一的配置管理，需要考虑与公司的配置管理平台如何配合使用。 9、Hystrix，监控和断路器。我们只需要在服务接口上添加 Hystrix 标签，就可以实现对这个接口的监控和断路器功能。 10、Hystrix Dashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。 11、Turbine，监控聚合，使用 Hystrix 监控，我们需要打开每一个服务实例的监控信息来查看。而 Turbine 可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。架构的可靠性保证：在关键节点做主备、集群部署，防止单点故障。待后续确认问题： 1、Access Control：Zuul 网关提供了相关控制功能，与我司 CAS 如何结合使用 2、Config Server：Spring Cloud 提供了远程配置中心，与我司的配置管理平台如何结合使用

5. 设计阶段 5.1. 总体设计 1、功能规划：对产品功能进行拆分，拆分为若干个微服务；一个功能可以创建多个微服务并部署在多个服务器节点上，以便进行负载均衡。 2、设计原子服务层，梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使应用能更快速的响应多变的客户需求。 3、为每个服务设计 API 接口（REST 方式） 4、为不同的服务进行分类，不同类型的服务需要的资源不同，可以配置不同的资源，包括 CPU、内存、存储等。 5.2. 服务拆分原则 1、粒度微小：根据业务功能划分服务粒度，总的原则是服务内部高内聚，服务之间低耦合。 2、责任单一：每个服务只做一件事，即单一职责原则。 3、隔离性原则：每个服务相互隔离，且不互相影响 4、业务无关优先原则：基础服务，是一些基础组件，与具体的业务无关。比如：短信服务、邮件服务。这里的服务最容易划分出来做微服务，也是我们第一优先级分离出来的服务。 5.3. 服务规划为实现负载均衡，允许相同的服务在多个节点注册相同的服务名，不同的端口。如果没有前期的规划，不同的服务提供者可能会注册相同的服务名，导致消费者调用服务时产生调用混乱。因此，需进行服务名的统一规划： 1、规划期统一制定每个服务提供者的服务名或者模块标示。

2、服务名的命名规则:ModuleName_ServiceName，且所有字符小写，不同单词之间以下划线分隔。如用户管理模块提供了获取用户信息的服务，则命名为：user_get_info。 3、新增服务名时，需要提出申请，审批通过后方可使用，为减少审批复杂度，可只审批 ModuleName，即在模块内部可以自由增加服务名，不需要进行审批。 5.4. 开发策略总体原则：不同的微服务需进行物理隔离。 1、SVN 策略：SVN 上创建独立的分支，不同微服务的代码提交不受相互影响； ---由配置管理员统一控制。问题：开发分支与集成分支，都将增加很多，维护工作量增加。 2、编译策略：代码编译时，各个微服务独立编译、打包，杜绝直接的依赖； 3、工程构建：代码开发时，各微服务创建独立的工程，工程之间不能产生直接依赖 4、持续集成：每个微服务独立执行持续集成。 5、版本集成：由统一的集成工具，实现自动化的版本集成，将所有微服务集成到统一的版本发布包中。 5.5. 版本策略每个微服务可以独立制作版本，伴随着服务的增多，SVN 分支增多，版本也将增多，版本管理的复杂度将成指数级增加。在服务之间依赖较多时，每个服务的升级或降级都将影响其他服务的正常运行。因此需执行如下策略： 1、所有服务的版本制作交由专业的版本管理员执行。 2、采用自动化的版本制作策略，最大程度的减少人工操作。 3、每个服务的版本必须有详细的版本计划、版本说明，对于版本说明要制定模板，明确需要提交的内容、版本号、SVN 标签等。 4、对项目经理的要求提升，需对整体的版本计划有严格的制定，尤其是版本之间的依赖关系要非常明确，版本升级、降级的风险评估需完全充分。 5、接口管理：严格执行接口管理制度，任何接口的变更必须进行审批、发公告等流程。

5.6. 数据库挑战与策略每个微服务都有自己独立的数据库，那么后台管理的联合查询怎么处理？这应该是大家会普遍遇到的一个问题，有三种处理方案。 1）严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。 2) 将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现，是一个折中的方案。 3）数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中，在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用 MongoDB、HBase 等。第一种方案适合业务较为简单的小公司；第二种方案，适合在原有系统之上，慢慢演化为微服务架构的公司；第三种适合大型高并发的互联网公司。建议，我们当前采用第二种方案。 5.7. 负载均衡不再采用一般的增加负载均衡服务器的方式进行负载均衡，如 F5、Nginx、LVS 等，而是把负载均衡的功能以库的方式集成到服务消费方的进程内，这种方案称为软负载均衡（Soft Load Balancing）或者客户端负载均衡。在 Spring Cloud 中配合 Eureka 的服务注册功能， Ribbon 子项目则为 REST 客户端实现了负载均衡。

资料库

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

相关推荐

开发技术

热门标签

最新资料