基于SpringCloud 微服务系统设计方案.docx
《基于SpringCloud 微服务系统设计方案.docx》由会员分享，可在线阅读，更多相关《基于SpringCloud 微服务系统设计方案.docx（17页珍藏版）》请在冰豆网上搜索。
基于SpringCloud微服务系统设计方案
微服务系统设计方案微服务本质1.微服不如说是一种微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，务架构风格。
行于独每个服务运微服务架构风格是要开发一种由多个小服务组成的应用。
简单来说，具备独立。
这些服务的资源API轻量级交互立的进程，并且采用。
多数情况下是一个HTTP，从而可以使最小化集中管理独立部署。
这种风格使业务能力并可以通过自动化部署方式不同的编程语言和数据存储技术用多种。
统整体模块化清晰，因此首先要做的是对系对于微服务架构系统，由于其服务粒度小，工程实践出发，组织好代码结构、进行功能、服务规划，优先考虑如何在交付过程中，从配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。
本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。
理解微服务架构和理念是核心。
2.系统环境
名称
版本
说明
JDK
SpringBoot
SpringFramework
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、使用SpringCloudConfig进行统一的配置管理，需要考虑与公司的配置管理平台如何配合使用。
9、Hystrix，监控和断路器。
我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。
10、HystrixDashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。
11、Turbine，监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。
而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。
这样就不需要挨个打开一个个的页面一个个查看。
架构的可靠性保证：
在关键节点做主备、集群部署，防止单点故障。
待后续确认问题：
1、AccessControl：
Zuul网关提供了相关控制功能，与我司CAS如何结合使用
2、ConfigServer：
SpringCloud提供了远程配置中心，与我司的配置管理平台如何结合使用．
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用来满足后台业务数据库中，在同步的过程中进行数据清洗，服务数据库数据同步到NoSQLHBase等。
系统的使用，推荐使用MongoDB、慢慢演化第二种方案，适合在原有系统之上，第一种方案适合业务较为简单的小公司；为微服务架构的公司；第三种适合大型高并发的互联网公司。
建议，我们当前采用第二种方案。
负载均衡5.7.
等，而、、NginxLVS不再采用一般的增加负载均衡服务器的方式进行负载均衡，如F5软负载均衡是把负载均衡的功能以库的方式集成到服务消费方的进程内，这种方案称为的服务注中配合EurekaSoftLoadBalancing（）或者客户端负载均衡。
在SpringCloud客户端实现了负载均衡。
子项目则为册功能，RibbonREST
进行负载均衡，其工作原理可以概括为下面四个步骤：
使用Ribbon1.Ribbon首先根据其所在Zone优先选择一个负载较少的EurekaServer;
定期从EurekaServer2.更新并过滤服务实例列表;
;根据指定的负载均衡策略，从可用的服务器列表中选择一个服务实例的地址3.
然后通过4.进行服务调用。
RestClient本身提供了下面几种负载均衡策略：
Ribbon以轮询的方式选择服务器，这个是默认值。
RibbonRoundRobinRule:
轮询策略，
所以示例中所启动的两个服务会被循环访问;
RandomRule:
随机选择，也就是说Ribbon会随机从服务器列表中选择一个进行访
问;
BestAvailableRule:
最大可用策略，即先过滤出故障服务器后，选择一个当前并
发请求数最小的;
WeightedResponseTimeRule:
带有加权的轮询策略，对各个服务器响应时间进行加
权处理，然后在采用轮询的方式来获取相应的服务器;
AvailabilityFilteringRule:
可用过滤策略，先过滤出故障的或并发请求大于阈
值一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个;
ZoneAvoidanceRule:
区域感知策略，先使用主过滤条件（区域负载器，选择最优
区域）对所有实例过滤并返回过滤后的实例清单，依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数（默认1）和最小过滤百分比（默认0），最后对满足条件的服务器则使用RoundRobinRule（轮询方式）选择一个服务器实例。
5.8.性能策略
1、网络优化：
优化组网结构，提升网络间通讯性能；
2、配置优化：
优化SpringCloud组件集以及其他组件的配置信息，使得性能最大化。
5.9.技术管理策略
微服务的架构理念中指出各微服务可以独立建设，可以使用不同的技术、语言、框架等，以便能更快速的使用新技术、新框架等响应特定客户需求，解决单体应用架构更新技术、更新框架时面临的困难或阻碍。
但这也同时带来了诸多问题，如下：
、各服务是否可以任意使用自己的技术、自己的组件、框架呢？
如果这样，势必带来1更大的管理困难、维护困难、技术共享困难。
、公共的方法如何实现共享？
如格式化时间的一个简单方法需要共享，也需要封装为2一个服务接口吗？
管理策略：
、总体原则：
仍然需要进行统筹考虑，所有组件统一管理，组件放置在产品仓库中，1
每个产品或服务需要共享组件时，从产品仓库获取。
、特殊情况：
特殊服务需要使用特殊的组件、框架，需提出申请，统筹规划后进行决2策。
开发阶段6.服务的调用6.1.AIP网关调用6.1.1.
Zuul网关进行调用，不允许直接调用微服务提供者。
所有服务通过Zuul进行主备或负载均衡处理。
Zuul可能会成为系统瓶颈，在项目复杂时可考虑为
6.1.2.同步调用
采用HTTPREST方式进行调用，针对业务需求可以进行负载均衡，负载均衡的调用方式有两种：
1、FeignClient
2、RestTemplate
建议使用FeignClient方式进行服务调用。
不管是什么方式，他都是通过REST接口调用服务的http接口，参数和结果默认都是通过Jackson序列化和反序列化。
因为SpringMVC的RestController定义的接口，返回的数数据。
JSON序列化成Jackson据都是通过．
6.1.3.异步调用均是可以选择的方案。
rabbitMq、kafka、SpringCloudStream实现的消息微服务，简单声明模、Kafka基于Redis、RabbitSpringCloudStream，SpringCloud应用中收发消息。
型用以在
服务间调用的权限验证6.1.4.或者tokenAPI一般我们的接口都需要某种授权才能访问，登陆成功以后，然后通过等方式才能调用接口。
cookie框架的话，登录的时候，把登录请求转发到相应的用户服务SpringCloudNetfix使用等。
然后客户端接下来的请求就会带着这token或header上，登陆成功后，会设置cookieZuul网关传到相应的服务上进行验证。
些验证信息，从传到服务端，如：
网关在把请求转发到后台的服务的时候，会默认把一些headerZuul就可以传递到服headers、Authorization。
这样，客户端请求的相关Cookie、Set-Cookiecookie也可以传到客户端。
务端，服务端设置的网关的配置里通过下面的Zuul但是，如果你想禁止某些header透传到服务端，可以在方式禁用：
zuul:
routes:
users:
path:
/users/**
sensitiveHeaders:
Cookie,Set-Cookie,Authorization
serviceId:
user里面也不会刚才说了我们的某个服务有时候需要调用另一个服务，这时候，这个请求不是客户端发起，他的请求的header有任何验证信息。
这时候，要么，通过防火墙等设置，保证服务间调用的接口，只能某几个地址访问；要么，就通过某种方式header。
设置iprequest获得同时，如果你想在某个服务里面获得这个请求的真是IP，（因为请求的通过网关转发而来，你直接通过，也可以：
），就可以从headerX-Forwarded-Host获得。
如果想禁用这个headerIP得到的是网关的=false。
header的Options如果你使用RestTemplate的方式调用，可以在请求里面添加一个有方式和FeignClient的方式都可以起作用：
也可以通过如下的拦截器的方式设置，它对RestTemplate@Bean
publicRequestInterceptorrequestInterceptor（）{
returnnewRequestInterceptor（）{
@Override
publicvoidapply（RequestTemplatetemplate）{
StringauthToken=getToken（）;
（AUTH_TOKEN_HEADER,authToken）;
}
};
}
6.1.5.服务编排
主要的作用是减少项目中的相互依赖。
比如现在有项目a调用项目b，项目b调用项目c...一直到h，是一个调用链，那么项目上线的时候需要先更新最底层的h再更新g...更新。
这只是这一个调用链，在复杂的业务中有非常多的调用，如果a最后是更新项目b更新c
要记住每一个调用链对开发运维人员来说就是灾难。
一个核心的业务处理项有这样一个好办法可以尽量的减少项目的相互依赖，就是服务编排，，现在统一在一个调用d掉用c，c目，负责和各个微服务打交道。
比如之前是a调用b，bc。
的时候W去调用W服务使用a的时候去调用b，使用b核心项目W中来处理，而采取一个方法进减少方法之间的一层层嵌套调用，其实可以理解为面向对象的设计，实现一个完整的业务处理，则采取下面方式：
行业务流程的串联，如方法W（）functionw{
；、调用方法a1
；、调用方法b2
；、调用方法c3
}
服务的熔断处理6.2.或压力过载等异常导致的由于各种原因会导致远程服务不可用在服务之间进行调用时，组Hystrix通过SpringCloudNetflix的故障蔓延，此时需要有一种机制进行保护处理。
是一种能够在远程服务不可（CricuitBreaker）件实现熔断和降级处理解决此问题。
断路器Cloud的设施，Spring闭合开关），并在远程服务恢复时自动恢复（）打开开关用时自动熔断（组件提供断路器、资源隔离与自我修复功能。
Hystrix通过Netflix的SpringcloudHystrix熔断器
6.3.统一日志管理
不同微服务部署在不同节点上，登录每个节点查看日志是比较麻烦的，同时对于需要关联多个微服务日志联合查看分析的情况将更加麻烦。
伴随节点数量的增加，如果没有合适的管理机制与工具，定位问题、发现问题的复杂性将越来越大，将成指数级增长，因此需要进行统一日志管理。
．
1、建立统一的日志管理规范；Blitz4j由log4j或2、开发并使用统一的日志组件，为所有微服务提供统一的日志服务，
封装；Agent进行日志的采集与转发；3、在每个服务节点上部署日志采集Agent组件，由此4、建立统一的日志中心，所有日志写入日志中心。
说明：
上述日志的实现由公司的“日志管理平台”进行实现，采用的是ELK集合框架。
统一监控管理6.4.
组件进行服务的监控，使用使用HystrixNagios进行服务器等资源的监控。
就可以实现Hystrix标签，、1Hystrix，监控和断路器。
我们只需要在服务接口上添加对这个接口的监控和断路器功能。
，监控面板，他提供了一个界面，可以监控各个服务上的服2、HystrixDashboard
务调用所消耗的时间等。
监控，我们需要打开每一个服务实例的监控HystrixTurbine3、，监控聚合，使用可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查信息来查看。
而Turbine看。
这样就不需要挨个打开一个个的页面一个个查看。
6.5.统一配置管理Spring
统一参数配置以及版本管理，可采用公司的配置管理平台或者实现各微服务的配置中心。
CloudConfig配置中心SpringCloudConfig
把应用SpringCloudConfig-就是我们通常意义上的配置中心。
SpringCloudConfig。
本质是配置信息从本地迁移到云端原本放在本地文件的配置抽取出来放在中心服务器，
从而能够提供更好的管理、发布能力。
）中存储的配置文（svnSpringCloudConfig分服务端和客户端，服务端负责将git
客户端并不能主动感知件发布成RESTREST接口获取配置。
但接口，客户端可以从服务端方法触发各自的到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST。
/refresh为解决配置信息能及时通知到各服务，同时减少每个微服务处理配置信息更新的复杂
度，为此我们通过消息总线来解决此问题，方案如下：
”的实例B“ServiceGit仓库、ConfigServer、以及微服务“ServiceA”、1.中都引入了SpringCloudBus，所以他们都连接到了RabbitMQ的消息总线上。
2.从Git仓库中配置的修改到发起/bus/refresh的POST请求这一步可以通过Git仓库的WebHook来自动触发。
3./bus/refresh请求不再发送到具体服务实例上，而是发送给ConfigServer，并通过destination参数来指定需要更新配置的服务或实例。
4.由于所有连接到消息总线上的应用都会接受到更新请求，所以在WebHook中就不需要维护所有节点内容来进行更新，从而解决了通过WebHook来逐个进行刷新的问题。
6.6.分布式session
采用Redis作为缓存组件以及session的共享组件。
6.7.REST资源响应结构
制定规范和解析方法。
调用链追踪6.8.API调用，对外暴露的一个接口，可能需要很微服务架构上通过业务来划分服务的，通过REST都会形多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，成导致接口调用失败。
随着业务的不断扩张，服务之间互相调用会越来越复杂。
主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了SpringCloudSleuth
文件中引入相应的依赖即可。
，你只需要在pomzipkin
6.9.单元测试
做微服务架构，进行系统测试的复杂度较大，为保证产品质量与开发、测试效率，单元测试是必不可少的。
可采用Mock方式进行测试模拟，由持续集成进行自动化单元测试的执行以及结果输出。
6.10.代码调试
对于单体架构系统，可直接本地化调试，但对于微服务架构，接口间的调用需采用远程通讯的方式，也就是说被调用的服务必须启动后方可被调用，因此当微服务增多时，你可能需要启动大量的微服务或者web服务器，这给本地化调用与调试带来了困难。
解决方案待研究。
7.测试
自动化测试7.1.单元测试：
由开发人员实现。
方式进行测试模拟，由持续集成进行自动化单元测试的执行以及结果输采用Mock出。
业务测试：
开发进行实现，测试也需考虑如何实现。
甚至是不同业务之间组成将多个服务或业务单元进行串联，测试一个完整的业务，RobotFramework自动化测试框
升级会员 