关于java:基于SpringCloud微服务系统设计5万字总结

1. 微服务实质

微服务架构从实质上说其实就是分布式架构，与其说是一种新架构，不如说是一种 微服

务架构格调。

简略来说，微服务架构格调是要开发一种由 多个小服务组成 的利用。每个服务运 行于独立的过程，并且采纳 轻量级交互。少数状况下是一个 *HTTP* 的资源 *API*。这些服务 具备独立业务能力 并能够通过 自动化部署 形式 独立部署。这种格调使 最小化集中管理，从而能够应用多种 不同的编程语言和数据存储技术。

对于微服务架构零碎，因为其服务粒度小，模块化清晰，因而首先要做的是对系 统整体进行性能、服务布局，优先思考如何在交付过程中，从 工程实际登程，组织好代码构造、配置、测试、部署、运维、监控 的整个过程，从而无效体现微服务的独立性与可部署性。

本文将从微服务零碎的设计阶段、开发阶段、测试阶段、部署阶段进行综合论述。

了解微服务架构和理念是外围。

2. 零碎环境

3. 微服务架构的挑战

可靠性：

因为采纳近程调用的形式，任何一个节点、网络呈现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。

也就是没有充沛的保障机制，则单点故障会大量减少。

运维要求高：

系统监控、高可用性、自动化技术

分布式复杂性：

网络提早、零碎容错、分布式事务

部署依赖性强：

服务依赖、多版本问题

性能（服务间通信老本高）：

无状态性、过程间调用、跨网络调用

数据一致性：

分布式事务管理须要逾越多个节点来保证数据的刹时一致性，因而比起传统的单体架构的事务，老本要高得多。另外，在分布式系统中，通常会思考通过数据的最终一致性来解决数据刹时统一带来的零碎不可用。

反复开发：

微服务理念崇尚每个微服务作为一个产品对待，有本人的团队开发，甚至能够有本人齐全不同的技术、框架，那么与其余微服务团队的技术共享就产生了矛盾，反复开发的工作即产生了。

4. 架构设计

4.1. 思维设计

微服务架构设计的基本目标是实现价值交付，微服务架构只有遵循 *DevOps* 理念方可进行的更顺畅，思维形式的转变是最重要的。

实现微服务技术架构，现有产品须要进行技术上的改良以及相干配套服务的实现，段施行、以及试点产品优先施行的策略，次要包含如下：

一、技术上的改良：

1、前后端拆散，web 前端通过 Http/Https 协定调用微服务的 API 网关，由 API 网关再通过路由服务调用相应的微服务

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

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

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

1、须要进行相应的自动化服务实现，包含自动化构建、自动化装置部署、自动化测试、自动化平台公布（Docker 实现）

2、治理服务，对于微服务架构，必须配套相应的监控与治理服务、日志治理服务等

3、合作服务，使用 DevOps 思维晋升开发、测试、运维的高效沟通与合作，实现开发与运维的一体化

4.3. 微服务架构设计

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 客户端实现了负载平衡。

Ribbon 自身提供了上面几种负载平衡策略：

RoundRobinRule: 轮询策略，Ribbon 以轮询的形式抉择服务器，这个是默认值。所以示例中所启动的两个服务会被循环拜访 ;

RandomRule: 随机抉择，也就是说 Ribbon 会随机从服务器列表中抉择一个进行拜访

BestAvailableRule: 最大可用策略，即先过滤出故障服务器后，抉择一个以后并发申请数最小的;

WeightedResponseTimeRule: 带有加权的轮询策略，对各个服务器响应工夫进行加权解决，而后在采纳轮询的形式来获取相应的服务器 ;

AvailabilityFilteringRule: 可用过滤策略，先过滤出故障的或并发申请大于阈值一部分服务实例，而后再以线性轮询的形式从过滤后的实例清单中选出一个 ;

ZoneAvoidanceRule: 区域感知策略，先应用主过滤条件（区域负载器，抉择最优区域）对所有实例过滤并返回过滤后的实例清单，顺次应用次过滤条件列表中的过滤条件对主过滤条件的后果进行过滤，判断最小过滤数（默认 1）和最小过滤百分比（默认 0），最初对满足条件的服务器则应用 RoundRobinRule(轮询形式) 抉择一个服务器实例。

5.8. 性能策略

1、网络优化：优化组网构造，晋升网络间通信性能；

2、配置优化：优化 Spring Cloud 组件集以及其余组件的配置信息，使得性能最大化。

5.9. 技术管理策略

微服务的架构理念中指出各微服务能够 独立建设，能够应用不同的技术、语言、框架等，以便能更疾速的应用新技术、新框架等响应特定客户需要，解决单体利用架构更新技术、更新框架时面临的艰难或妨碍。

但这也同时带来了诸多问题，如下：

1、各服务是否能够任意应用本人的技术、本人的组件、框架呢？如果这样，势必带来更大的治理艰难、保护艰难、技术共享艰难。

2、公共的办法如何实现共享？如格式化工夫的一个简略办法须要共享，也须要封装为一个服务接口吗？

管理策略：

1、总体准则：依然须要进行兼顾思考，所有组件对立治理，组件搁置在产品仓库中，每个产品或服务须要共享组件时，从产品仓库获取。

2、非凡状况：非凡服务须要应用非凡的组件、框架，需提出申请，统筹规划后进行决策。

6. 开发阶段

6.1. 服务的调用

6.1.1. AIP 网关调用

所有服务通过 Zuul 网关进行调用，不容许间接调用微服务提供者。

Zuul 可能会成为零碎瓶颈，在我的项目简单时可思考为 Zuul 进行主备或负载平衡解决。

6.1.2. 同步调用

采纳 HTTP REST 形式进行调用，针对业务需要能够进行负载平衡，负载平衡的调用形式有两种：

1、FeignClient

2、RestTemplate

倡议应用 *FeignClient*形式进行服务调用。

不论是什么形式，他都是通过 REST 接口调用服务的 http 接口，参数和后果默认都是通过 Jackson 序列化和反序列化。因为 Spring MVC 的 RestController 定义的接口，返回的数据都是通过 Jackson 序列化成 JSON 数据。

6.1.3. 异步调用

rabbitMq、kafka、Spring Cloud Stream 均是能够抉择的计划。

Spring Cloud Stream，基于 Redis、Rabbit、Kafka 实现的音讯微服务，简略申明模型用以在 Spring Cloud 利用中收发音讯。

6.1.4. 服务间调用的权限验证

个别咱们的 API 接口都须要某种受权能力拜访，登陆胜利当前，而后通过 token 或者 cookie 等形式能力调用接口。应用 Spring Cloud Netfix 框架的话，登录的时候，把登录申请转发到相应的用户服务上，登陆胜利后，会设置 cookie 或 header token 等。而后客户端接下来的申请就会带着这些验证信息，从 Zuul 网关传到相应的服务上进行验证。

Zuul 网关在把申请转发到后盾的服务的时候，会默认把一些 header 传到服务端，如：Cookie、Set-Cookie、Authorization。这样，客户端申请的相干 headers 就能够传递到服务端，服务端设置的 cookie 也能够传到客户端。

然而，如果你想禁止某些 header 透传到服务端，能够在 Zuul 网关的 application.yml 配置里通过上面的形式禁用：

方才说了咱们的某个服务有时候须要调用另一个服务，这时候，这个申请不是客户端发动，他的申请的 header 外面也不会有任何验证信息。这时候，要么，通过防火墙等设置，保障服务间调用的接口，只能某几个地址拜访；要么，就通过某种形式设置 header。

同时，如果你想在某个服务外面取得这个申请的真是 IP，（因为申请的通过网关转发而来，你间接通过 request 取得 ip 失去的是网关的 IP），就能够从 headerX-Forwarded-Host 取得。如果想禁用这个 header，也能够：

如果你应用 RestTemplate 的形式调用，能够在申请外面增加一个有 header 的 Options。也能够通过如下的拦截器的形式设置，它对 RestTemplate 形式和 FeignClient 的形式都能够起作用：

@Bean

public RequestInterceptor requestInterceptor() {return new RequestInterceptor() {

@Override
public void apply(RequestTemplate template) {String authToken = getToken();
template.header(AUTH_TOKEN_HEADER, authToken);

}
};
}

6.1.5. 服务编排

次要的作用是缩小我的项目中的相互依赖。比方当初有我的项目 a 调用我的项目 b，我的项目 b 调用我的项目 c … 始终到 h，是一个调用链，那么我的项目上线的时候须要先更新最底层的 h 再更新 g… 更新 c 更新 b 最初是更新我的项目 a。这只是这一个调用链，在简单的业务中有十分多的调用，如果要记住每一个调用链对开发运维人员来说就是劫难。

有这样一个好方法能够尽量的缩小我的项目的相互依赖，就是服务编排，一个外围的业务解决我的项目，负责和各个微服务打交道。比方之前是 a 调用 b，b 掉用 c，c 调用 d，当初对立在一个外围我的项目 W 中来解决，W 服务应用 a 的时候去调用 b，应用 b 的时候 W 去调用 c。

其实能够了解为面向对象的设计，缩小办法之间的一层层嵌套调用，而采取一个办法进行业务流程的串联，如办法 W 实现一个残缺的业务解决，则采取上面形式：

function w（）

{

1、调用办法 a；

2、调用办法 b；

3、调用办法 c；

}

6.2. 服务的熔断解决

在服务之间进行调用时，因为各种起因会导致近程 服务不可用 或压力过载等异样导致的故障蔓延，此时须要有一种机制进行爱护解决。Spring Cloud 通过 Netflix 的 Hystrix 组件实现熔断和降级 解决解决此问题。断路器 (Cricuit Breaker) 是一种可能在近程服务不可用时主动熔断 (关上开关)，并在近程服务复原时主动复原 (闭合开关) 的设施，Spring Cloud 通过 Netflix 的 Hystrix 组件提供断路器、资源隔离与自我修复性能。

6.3. 对立日志治理

不同微服务部署在不同节点上，登录每个节点查看日志是比拟麻烦的，同时对于须要关联多个微服务日志联结查看剖析的状况将更加麻烦。随同节点数量的减少，如果没有适合的管理机制与工具，定位问题、发现问题的复杂性将越来越大，将成指数级增长，因而须要进行对立日志治理。

1、建设对立的日志治理标准；

2、开发并应用对立的日志组件，为所有微服务提供对立的日志服务，由 log4j 或 Blitz4j 封装；

3、在每个服务节点上部署日志采集 Agent 组件，由此 Agent 进行日志的采集与转发；

4、建设对立的日志核心，所有日志写入日志核心。

阐明：上述日志的实现由公司的“日志治理平台”进行实现，采纳的是 ELK 汇合框架。

6.4. 对立监控治理

应用 Hystrix 组件进行服务的监控，应用 Nagios 进行服务器等资源的监控。

1、Hystrix，监控和断路器。咱们只须要在服务接口上增加 Hystrix 标签，就能够实现对这个接口的监控和断路器性能。

2、Hystrix Dashboard，监控面板，他提供了一个界面，能够监控各个服务上的服务调用所耗费的工夫等。

3、Turbine，监控聚合，应用 Hystrix 监控，咱们须要关上每一个服务实例的监控信息来查看。而 Turbine 能够帮忙咱们把所有的服务实例的监控信息聚合到一个中央对立查看。

这样就不须要挨个关上一个个的页面一个个查看。

6.5. 对立配置管理

实现各微服务的 对立参数配置以及版本治理，可采纳公司的配置管理平台或者 SpringCloud Config 配置核心。

pring Cloud Config 就是咱们通常意义上的配置核心。Spring Cloud Config- 把利用本来放在本地文件的配置抽取进去放在核心服务器，实质是配置信息从本地迁徙到云端。从而可能提供更好的治理、公布能力。

Spring Cloud Config 分服务端和客户端，服务端负责将 git（svn）中存储的配置文件公布成 REST 接口，客户端能够从服务端 REST 接口获取配置。但 客户端并不能被动感知到配置的变动，从而被动去获取新的配置，这须要 每个客户端通过 POST 办法触发各自的 /refresh。为解决配置信息能及时告诉到各服务，同时缩小每个微服务解决配置信息更新的复杂度，

为此咱们通过音讯总线来解决此问题，计划如下：

​

6.6. 分布式 session

采纳 Redis 作为缓存组件以及 session 的共享组件。

6.7. REST 资源响应构造

制订标准和解析办法。

6.8. API 调用链追踪

Spring Cloud Sleuth 次要性能就是在分布式系统中提供追踪解决方案，并且兼容反对了 zipkin，你只须要在 pom 文件中引入相应的依赖即可。

6.9. 单元测试

做微服务架构，进行零碎测试的复杂度较大，为保障产品质量与开发、测试效率，单元测试是必不可少的。

可采纳 Mock 形式进行测试模仿，由继续集成进行自动化单元测试的执行以及后果输入。

6.10. 代码调试

对于单体架构零碎，可间接本地化调试，但对于微服务架构，接口间的调用需采纳近程通信的形式，也就是说被调用的服务必须启动前方可被调用，因而当微服务增多时，你可能须要启动大量的微服务或者 web 服务器，这给本地化调用与调试带来了艰难。

解决方案待钻研。

7. 测试

7.1. 自动化测试

单元测试：

由开发人员实现。

采纳 Mock 形式进行测试模仿，由继续集成进行自动化单元测试的执行以及后果输入。

业务测试：

开发进行实现，测试也需思考如何实现。将多个服务或业务单元进行串联，测试一个残缺的业务，甚至是不同业务之间组成的零碎测试，须要采纳相干的自动化测试框架执行，如 RobotFramework 自动化测试框架。

7.2. 依赖测试

也能够称为接口测试或者契约测试，在微服务逐步增多的状况下，如何无效保障服务之间可能依照接口的约定失常工作，即合乎契约，成为微服务施行过程中，测试面临的次要挑战。

一、开发自动化的接口测试工具，

1、检测接口是否满足约定

2、检测接口是否发生变化

3、检测接口是否能够失常被调用。

二、测试方法：

采取基于消费者驱动的契约测试，测试架构如下：

其劣势如下：

从价值实现的角度定义契约从消费者应用契约的角度登程，首先保障消费者基于此契约是能够实现价值的，有了这个前提，再应用契约来验证提供者，如果提供者提供的契约同定义的契约统一，则证实提供者提供的契约是可能实现服务消费者的。通过这种形式，使得更聚焦于如何从价值实现登程。

隔离消费者和提供者的测试对于契约的消费者和提供者能够离开独立测试，无效解决传统集成测试服务架构的弊病，将微服务的接口测试老本降到最低。

三、测试工具：

*Pact*、*Janus*、*Pacto*等。

7.3. 零碎测试

7.4. 熔断测试

1、通过进行微服务的形式测试服务路由的正确性

2、通过压力测试，将某个微服务产生过载等异样，测试服务熔断或降级

3、通过压力测试，测试负载平衡策略的正确性

7.5. 性能测试

原有本地化的 api 调用将会变成 REST 的近程调用，调用速度势必受到影响，因而须要对系统性能进行思考以及性能测试，次要影响因素如下：

1、网络：近程调用时受到网络通讯速度的影响，这波及到网络速度、网络部署以及零碎架构，有相互依赖的服务应采取 就近部署准则。

2、服务器：受到近程服务所在服务器性能的影响。

3、数据量：数据量这里指的是数据大小以及数据传输的次数以及频率，此时 REST 调用形式会产生瓶颈，当然，最好的形式是防止此种状况产生，此种场景采取消息中间件的形式异步通信。

8. 继续集成

1、继续集成：每个微服务独立执行继续集成。

2、版本集成：由对立的集成工具，实现自动化的版本集成，将所有微服务集成到对立

的版本公布包中。

3、继续集成可制作多种场景的版本，包含测试环境、开发环境、生产环境。

4、统计测试覆盖率等指标数据。

5、工具：Jenkins、Sonar 等。

9. 继续部署

1 通过继续集成主动制作公布版本的 Docker 镜像；

2 将 docker 镜像主动上传到 docker 容器中。

10. 运维阶段

10.1. 近程降级

微服务一直减少后，意味着部署容器也在同步减少，对于后续降级保护的工作量将会逐步减少，开发对立管理中心，反对近程保护与降级将可缩小运维的复杂度。

10.2. 对立配置核心

应用 Spring Cloud Config 或者配置管理平台进行对立的配置管理。

10.3. 对立日志核心

应用日志治理平台进行对立的日志采集、日志剖析。