完整版)基于SpringCloud微服务系统设计方案

完整版)基于SpringCloud微服务系统设计方案

微服务系统设计方案

1.微服务本质

微服务架构实质上是分布式架构的一种风格，它由多个小服务组成的应用构成。每个服务运行于独立的进程，采用轻量级交互，通常是一个HTTP的资源API。这些服务具备独立业务能力，可以通过自动化部署方式独立部署，从而最小化集中管理，使用多种不同的编程语言和数据存储技术。对于微服务架构系统，首先要规划功能和服务，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。

2.系统环境

名称：JDK、Spring Boot、Spring Framework

版本：1.8

说明：Ribbon、XXX、RabbitMQ

3.微服务架构的挑战

微服务架构面临的挑战包括可靠性、运维要求高、分布式复杂性、部署依赖性强、性能、数据一致性和重复开发。由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。系统监控、高可用性、自动化技术是必要的。网络延迟、系统容错、分布式事务是分布式复杂性的主要问题。服务依赖、多版本问题是部署依赖性强的主要原因。无状态性、进程间调用、跨网络调用导致了性能问题。分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此成本高。微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，这就产生了重复开发的工作。

4.架构设计

4.1.思维设计

微服务架构设计的根本目的是实现价值交付，遵循DevOps理念方可进

行的更顺畅，思维方式的转变是最重要的。

为了实现微服务技术架构，我们需要进行技术上的改进和相关配套服务的实现。我们采用分阶段实施和试点产品优先实施的策略。具体包括以下两个方面：

一、技术上的改进：

1、实现前后端分离，让web前端通过Http/Https协议调用微服务的API网关，再由API网关经过路由服务调用相应的微服务。

2、不同微服务之间通过REST方式互相调用。

3、微服务之间通过消息中间件实现消息交互机制。

二、配套服务与功能实现：

1、需要实现相应的自动化服务，包括自动化构建、自动化安装部署、自动化测试、自动化平台发布（使用Docker实现）。

2、必须配套相应的监控与管理服务、日志管理服务等管理服务，以实现微服务架构的管理。

3、需要协作服务，运用DevOps思想提升开发、测试、运维的高效沟通与协作，实现开发与运维的一体化。

除此之外，我们还需要进行微服务架构设计，具体包括以下几个方面：

1、根据业务拆分成若干个子系统或微服务。

2、每个子系统可以部署多个应用，多个应用之间使用负载均衡。

3、需要一个服务注册中心XXX，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。XXX可部署多个，进行高可用保证。

4、所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置ZUUL网关来判断一个URL请求由哪个服务处理。请求转发到服务上的时候使用负载均衡Ribbon。

5、服务之间采用XXX进行调用。

6、使用断路器hystrix，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。

7、还需要一个监控功能，监控每个服务调用花费的时间等。

8、使用SpringCloud Config进行统一的配置管理，需要考虑与公司的配置管理平台如何配合使用。

9、Hystrix，监控和断路器。我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。

10、Hystrix Dashboard，监控面板，提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。

11、XXX，监控聚合，使用Hystrix监控，可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。

最后，为了保证架构的可靠性，我们需要不断进行测试和优化，确保整个系统的稳定性和可靠性。

在设计阶段，为了防止单点故障，可以在关键节点做主备或集群部署。同时，需要确认如何将Zuul网关的Access

Control功能与公司的CAS结合使用，以及如何将SpringCloud提供的远程配置中心与公司的配置管理平台结合使用。

在总体设计阶段，需要对产品功能进行拆分，将其拆分为若干个微服务，并部署在多个服务器节点上，以进行负载均衡。

同时，需要设计原子服务层，将核心应用和公共应用作为独立的服务下沉到核心和公共能力层，以形成稳定的服务中心。每个服务需要设计API接口，并根据不同类型的服务配置不同的资源，包括CPU、内存、存储等。

在服务拆分原则方面，需要根据业务功能划分服务粒度，使服务内部高内聚，服务之间低耦合。每个服务只做一件事，即单一职责原则。每个服务相互隔离，且不互相影响。基础服务是一些基础组件，与具体的业务无关，比如短信服务和邮件服务，最容易划分出来做微服务，也是第一优先级分离出来的服务。

在服务规划方面，为了实现负载均衡，允许相同的服务在多个节点注册相同的服务名，不同的端口。为避免服务名混乱，需要进行服务名的统一规划，包括统一制定每个服务提供者的服务名或模块标示，命名规则为ModuleName_ServiceName，且所有字符小写，不同单词之间以下划线分隔。新增服务名需要提出申请并经过审批通过后方可使用。

在开发策略方面，不同的微服务需进行物理隔离，可以在SVN上创建独立的分支，不同微服务的代码提交不受相互影响。但是，开发分支与集成分支将增加很多，维护工作量增加，需要由配置管理员进行统一控制。

是采用服务网格技术进行负载均衡。服务网格是一种架构模式，它将网络层和应用层的负载均衡功能集成到应用程序中，使得微服务之间的通信更加可靠和高效。服务网格技术可以自动化地管理和监控微服务之间的通信，提高了系统的可靠性和可维护性。等服务网格技术来实现负载均衡。

6.安全策略

在微服务架构中，由于服务之间的通信是通过网络进行的，因此安全问题变得尤为重要。为了保障系统的安全性，我们需要采取以下策略：

1、采用HTTPS协议来保障通信的安全性；

2、采用OAuth2.0等授权机制来保障访问的安全性；

3、采用JWT等令牌机制来保障身份的安全性；

4、采用防火墙、入侵检测等安全设施来保障系统的安全性；

5、采用安全编码规范、安全审计等手段来保障代码的安全性。

总之，微服务架构的安全问题需要全方位地考虑和解决，才能保障系统的安全性。

7.监控策略

在微服务架构中，由于服务之间的通信是通过网络进行的，因此监控问题变得尤为重要。为了保障系统的可靠性和可维护性，我们需要采取以下策略：

1、采用ELK等日志管理工具来实现日志的收集和分析；

2、采用Prometheus等监控工具来实现系统的实时监控；

3、采用Zipkin等分布式跟踪工具来实现服务之间的调用链跟踪；

4、采用Grafana等数据可视化工具来实现监控数据的可视化；

5、采用自动化运维工具来实现系统的自动化运维。

总之，微服务架构的监控问题需要全方位地考虑和解决，才能保障系统的可靠性和可维护性。

负载均衡是一种将请求分配到不同服务器的技术。软负载均衡是将负载均衡的功能以库的方式集成到服务消费方的进程内，也称为客户端负载均衡。在Spring Cloud中，Ribbon子项目与Eureka的服务注册功能配合，实现了REST客户端的负载均衡。

使用Ribbon进行负载均衡，其工作原理可以概括为以下四个步骤：首先根据其所在Zone优先选择一个负载较少的Eureka Server；然后定期从Eureka Server更新并过滤服务实例列表；接着根据指定的负载均衡策略，从可用的服务器列表中选择一个服务实例的地址；最后通过RestClient进行服务调用。

XXX提供了多种负载均衡策略，包括轮询策略、随机选择、最大可用策略、带有加权的轮询策略、可用过滤策略和区域感知策略。其中，轮询策略是默认值，示例中启动的两个服务会被循环访问。

在性能策略方面，可以通过优化组网结构和配置信息，提升网络间通讯性能和最大化性能。在技术管理策略方面，微服务的架构理念允许各微服务独立建设，使用不同的技术、语言、

框架等，以便更快速地响应特定客户需求，解决单体应用架构更新技术、更新框架时面临的困难或阻碍。

在微服务架构中，服务之间的调用是必不可少的。但是这也带来了一些问题，例如是否允许各服务任意使用自己的技术、组件、框架，这样会带来更大的管理、维护和技术共享困难。为了解决这些问题，我们需要采取一些管理策略。

总体原则是所有组件都需要统一管理，放置在产品仓库中。当一个产品或服务需要共享组件时，从产品仓库获取。对于特殊情况，特殊服务需要使用特殊的组件、框架，需要提出申请，并进行统筹规划后进行决策。

在开发阶段，服务调用是一个重要的环节。所有服务都通过Zuul网关进行调用，不允许直接调用微服务提供者。Zuul可能会成为系统瓶颈，在项目复杂时可考虑为Zuul进行主备或负载均衡处理。

在同步调用方面，我们可以采用HTTP REST方式进行调用，并进行负载均衡。建议使用FeignClient方式进行服务调

用。不管是什么方式，都是通过REST接口调用服务的http接口，参数和结果默认都是通过Jackson序列化和反序列化。

在异步调用方面，我们可以选择rabbitMq、kafka、Spring

Cloud Stream等方案。Spring Cloud Stream是基于Redis、Rabbit、Kafka实现的消息微服务，可以在Spring Cloud应用中收发消息。

服务间调用的权限验证也是必不可少的。一般我们的API接口都需要某种授权才能访问，登陆成功以后，通过token或者cookie等方式才能调用接口。使用Spring Cloud Netfix框架的话，登录请求会被转发到相应的用户服务上，登陆成功后，会设置cookie或header token等。然后客户端接下来的请求就会带着这些验证信息，从Zuul网关传到相应的服务上进行验证。

Zuul网关会默认将一些header传递到服务端，例如Cookie、n，从而实现客户端请求的相关headers传递到服务端，服务端设置的cookie也可以传递到客户端。但是，如果要禁止某些header透传到服务端，配置文件中通过sensitiveHeaders属性禁用。

当一个服务需要调用另一个服务时，请求的header中不会包含任何验证信息。此时，可以通过防火墙等设置来保证服务间调用的接口只能被某几个地址访问，或者通过设置header的方式来实现。同时，如果想要在某个服务中获取请求的真实IP，可以从header X-Forwarded-Host中获取。如果要禁用该header，可以在Zuul网关的配置文件中设置addProxyHeaders属性为false。

如果使用RestTemplate方式调用，ns。也可以通过拦截器的方式设置，该拦截器对RestTemplate方式和FeignClient方式都适用。

服务编排的主要作用是减少项目中的相互依赖。例如，如果项目a调用项目b，项目b调用项目c，一直到h，形成了一个调用链，那么在项目上线时需要先更新最底层的h，然后再更新g，以此类推，这样才能确保服务之间的依赖关系得到满足。

更新项目a需要调用b，这只是复杂业务中的一个调用链，对开发和运维人员来说是灾难。为了尽量减少项目之间的相互

依赖，可以采用服务编排。核心业务处理项目W负责和各个微服务打交道。以前是a调用b，b调用c，c调用d，现在统一在W中处理。W服务使用a时，调用b；使用b时，调用c。这可以理解为面向对象的设计，减少方法之间的嵌套调用，采取一个方法实现完整的业务处理。

在服务之间进行调用时，可能由于各种原因导致远程服务不可用或压力过载等异常，这时需要有一种机制进行保护处理。Spring Cloud通过Netflix的Hystrix组件实现熔断和降级处理解决此问题。断路器是一种能够在远程服务不可用时自动熔断并在远程服务恢复时自动恢复的设施。Spring Cloud通过Netflix的Hystrix组件提供断路器、资源隔离和自我修复功能。

不同微服务部署在不同节点上，登录每个节点查看日志是比较麻烦的，同时对于需要关联多个微服务日志联合查看分析的情况将更加麻烦。因此需要进行统一日志管理。建立统一的日志管理规范，开发并使用统一的日志组件，为所有微服务提供统一的日志服务，由log4j或Blitz4j封装。在每个服务节点上部署日志采集Agent组件，由此Agent进行日志的采集与转发。建立统一的日志中心，所有日志写入日志中心。这些日志

的实现由公司的“日志管理平台”进行实现，采用的是ELK集合框架。

为了统一监控管理，可以使用Hystrix和XXX在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。XXX提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。

XXX是一个监控聚合工具，可以帮助我们将所有服务实例的监控信息聚合到一个地方，以便统一查看。这样就不需要逐个打开每个服务实例的监控信息页面了。使用Hystrix组件进行服务监控，s进行服务器等资源监控。

实现各微服务的统一参数配置以及版本管理，可以采用公司的配置管理平台或者SpringCloud Config配置中心。Spring

Cloud Config是一个配置中心，可以将应用原本放在本地文件的配置抽取出来放在中心服务器，从而提供更好的管理、发布能力。Spring Cloud Config分为服务端和客户端，服务端负责将存储在git（svn）中的配置文件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知

到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST方法触发各自的/refresh。

为了解决配置信息能及时通知到各服务，同时减少每个微服务处理配置信息更新的复杂度，我们通过消息总线来解决此问题。具体方案如下：Git仓库、Config Server、以及微服务“Service A”、“ServiceB”的实例中都引入了Spring Cloud Bus，所以他们都连接到了RabbitMQ的消息总线上。从Git仓库中配置的修改到发起/bus/refresh的POST请求这一步可以通过Git仓库的Web Hook来自动触发。/bus/refresh请求不再发送到具体服务实例上，而是发送给Config Server，n参数来指定需要更新配置的服务或实例。由于所有连接到消息总线上的应用都会接受到更新请求，所以在WebHook中就不需要维护所有节点内容来进行更新，从而解决了通过Web Hook来逐个进行刷新的问题。

n的共享组件，n。

制定规范和解析方法，以便更好地处理REST资源响应结构。

API调用链追踪。

问题。消费者可以通过契约来验证提供者的服务是否符合预期，而提供者则可以通过契约来验证自己的服务是否符合约定。这种隔离的测试方式可以有效地降低测试的复杂度和成本。

微服务架构是通过业务来划分服务的，这些服务通过REST调用对外暴露一个接口。但是，如果链路上任何一个服务出现问题或者网络超时，都会导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。为了解决这个问题，XXX提供了追踪解决方案，并且兼容支持了zipkin，只需要在pom文件中引入相应的依赖即可。

在微服务架构下，进行系统测试的复杂度较大，因此单元测试是必不可少的。可以采用Mock方式进行测试模拟，并由持续集成进行自动化单元测试的执行以及结果输出。对于代码调试，单体架构系统可以直接本地化调试，但微服务架构需要采用远程通讯的方式进行接口间的调用，这给本地化调用与调试带来了困难，解决方案待研究。

在测试方面，自动化测试包括单元测试和业务测试。单元测试由开发人员实现，采用Mock方式进行测试模拟，并由持续集成进行自动化单元测试的执行以及结果输出。业务测试需要将多个服务或业务单元进行串联，测试一个完整的业务，甚至是不同业务之间组成的系统测试，需要采用相关的自动化测试框架执行，如RobotFramework自动化测试框架。另外，依赖测试也可以称为接口测试或者契约测试，是微服务实施过程中测试面临的主要挑战。为了有效保证服务之间能够按照接口的约定正常工作，需要开发自动化的接口测试工具，并采取基于消费者驱动的契约测试方法，从价值实现的角度定义契约，并隔离消费者和提供者的测试，有效解决传统集成测试服务架构的问题。

微服务架构的一个弊端是接口测试成本高，但是可以使用测试工具如Pact、Janus、Pacto等来降低测试成本。在系统测试方面，可以通过停止微服务来测试服务路由的正确性，也可以通过压力测试来测试服务熔断或降级以及负载均衡策略的正确性。在性能测试方面，由于原有本地化的api调用变成了REST的远程调用，需要考虑系统性能和进行性能测试，其中主要影响因素包括网络、服务器和数据量。持续集成可以帮助每个微服务独立执行持续集成，并将所有微服务集成到统一的

版本发布包中。持续部署可以通过持续集成自动制作发布版本的Docker镜像，并将其自动上传到Docker中。在运维阶段，可以使用开发统一管理中心来支持远程维护与升级，也可以使用Spring Cloud Config或者配置管理平台进行统一的配置管理，同时使用统一日志中心来进行日志管理。