springcloud架构说明

Spring Cloud架构说明

1.注册与发现

服务通过nacos server内部的open api进行服务注册，nacos server内部有一个sevice服务的概念，里面有多个instance实例的概念，同时对不同的service服务可以划归到不同的namespace命名空间下去注册的时候就是在注册表里维护好每个服务的每个实例的服务器地址，包括ip地址和端口号一旦注册成功之后，服务就会跟nacos server进行定时的心跳，保持心跳是很关键的，nacos server会定时检查服务各个实例的心跳，如果一定时间没心跳，就认为这个服务实例宕机了，就从注册表里摘除了其他服务会从nacos server通过open api查询要调用的服务实例列表，而且nacos客户端会启动一个定时任务，每隔10s就重新拉取一次服务实例列表，这样如果调用的服务有上线或者下线，就能很快感知到了还可以对要调用的服务进行监听，如果有异常变动会由nacos server反向通知他nacos本身的话，其实是完全可以脱离spring cloud自己独立运作的，但是他目前是集成到spring cloud alibaba里去的，也就是在spring cloud的标准之下实现了一些东西，spring cloud自己是有一个接口，叫做ServiceRegistry，也就是服务注册中心的概念。

2.数据一致性

目前来看基本可以归为两家：一种是基于 Leader 的非对等部署的单点写一致性，一种是对等部署的多写一致性。当我们选用服务注册中心的时候，并没有一种协议能够覆盖所有场景，Nacos 因为要支持多种服务类型的注册，并能够具有机房容灾、集群扩展等必不可少的能力，在 1.0.0 正式支持 AP 和 CP 两种一致性协议并存。目前的一致性协议实现，一个是基于简化的 Raft 的 CP 一致性，一个是基于自研协议 Distro 的 AP 一致性。

3.负载均衡

负载均衡严格的来说，并不算是传统注册中心的功能。一般来说服务发现的完整流程应该是先从注册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照一定的流量分配机制来访问不同的服务提供者，因此注册中心本身一般不限定服务消费者的访问策略

3.1Ribbon 设计的客户端负载均衡机制

Ribbon 设计的客户端负载均衡机制，主要是选择合适现有的 IRule、ServerListFilter 等接口实现，或者自己继承这些接口，实现自己的过滤逻辑。这里 Ribbon 采用的是两步负载均衡，第一步是先过滤掉不会采用的服务提供者实例，第二步是在过滤后的服务提供者实例里，实施负载均衡策略。Ribbon 内置的几种负载均衡策略功能还是比较强大的，同时又因为允许用户去扩展，这可以说是一种比较好的设计。

4.基本协议

系统内部服务之间提供swagger进行接口说明，使用FeignClient进行通信，api是基于RESTful风格的http协议

5.api网管

SpringCloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。

Spring Cloud Gateway旨在提供一种简单而有效的途径来发送API，并为他们提供横切关注点，例如：安全性，监控/指标和弹性。

6.架构优势

高可用设计

所有应用和基础服务都支持集群或HA部署模式，不存在单一故障点。

支持快速响应的一体化运维设计。

应用监控方面依托自有监控产品实现对操作系统、中间件、数据库、应用服务的监控，确保业务系统的可用性；前端运维方面依托业务运维管理实现前端设备的故障监控和快速响应。

基于中台的集约化设计

结合公司中台及战略目标，将已有系统共性能力下沉形成公共支撑层能力，同时通过SOA思想将共性能力通过API或接口服务的方式开放出去供上层应用使用和组装，完成上层应用快速迭代开发；同时将使用比较多的业务模块拆分，将大单体应用拆分为松耦合的微服务模块，提高交付效率及质量。

基于统一技术路线和标准规范的开发

统一技术路线和标准规范，提供前端开发体系、后端开发体系、移动开发平台和微服务框架，为各类应用开发提供规范化的约束和支撑能力。