去中心化的架构
SOA集中架构： ESB Nginx
ServiceMesh

Spring 基于bean
SpringBoot 基于application 自动配置
SpringCloud 基于Service 微服务架构共性功能 集成

微服务之间调用存在什么问题？需要什么技术？
RPC调用： fegin dubbo
服务的注册与发现：eureka nacos
配置统一管理：zk nacos redis
服务链路的排查，微服务监控： skyWalking zipkin+sleuth
服务熔断降级限流： hystrix sentinel
分布式是：seata : AT模式
skywalking : agent代理增强模式

公司： Netflix alibaba huawei 都实现自己的微服务架构设计

阿里云提供了对应的微服务的脚手架一样的配置‘’

阿里云对应的产品 ： promi

对应官网；
spring cloud 对应不同的springboot版本，注意关系对应

2.2.4：有问题，不稳定

怎么去用？

思考，框架的设计思想？
有术无道止于术
设计上要处于可扩展。灵活
客户端负载均衡
灵活感知客户端是否存在？

如何设计一个注册中心

1：记录各个服务的提供者的信息，
2：保证记录的是可以用的有效服务列表
3：动态，实时的维持这份关系表
阈值保护：
提供者，消费者是通路的
只是注册中心不通了
有点想Spring的bean，需要bean的时候不是自己new ,有点外包的感觉
只是外包了维护，获取的步骤不是真实外包了全部的功能。
设计服务的续约？ 心态，续约。 如何发送心态

nacos server启动

集群模式，单机模式
稍微改下，默认是集群模式的，要改成单机版的

使用

1. 引入依赖
2. 修改配置 nacosDiscoveryProperties.java
3. 加一个enable注解

启动就可以了，

Derby数据结构 ，存储命名空间相关信息

调用方怎么用

负载均衡器
拉取对应服务的信息去调用
框架的扩展点， 拦截器，去扩展
ClientHttpRequestInterceptor :
注册中心会集成进来，引入的是ribbon ，
loadBalanceInterceptor的拦截器，去替换serverName

实际不是，实际是@LoadBanlance做的

CP架构，基于reft算法架构的，
注册表结构
已经设计
官网：nacos.io

namingService 接口，
底层是http请求，发起注册请求。
支持异步的接口，提供了接口，
异构的服务也可以实现注册中心

类：InstanceController.java 包含注册，心跳接口，服务列表查询的接口
ServiceManger： 内部的map结构维护服务名称对应的服务list
namespace: 隔离的作用，区分，各个环境的，生产，测试，开发
也可以是各个服务的
Map
不同的group也是不通的，最好是同一个group

Map clusterMap # 集群的map
不同的集群是可以通的 尽可能的同一集群

负载均衡算法时，可以考虑同一集群的节点

persistentinstances 持久实例
ephemeralInstances 临时实例

nacos的数据结构

nacos自动注册的

Spring cloud ALibaba Nacos 整合进来了
依赖SpringCloud 依赖Spring boot 依赖 Spring 依赖 bean

Spring Cloud的服务注册的标准
ServiceRegistry#register
spring cloud关于注册的规范，

onApplicationEvent：在实践监听中，发起的注册的调用
AbstractAutoServiceRegistration 实现了 OnapplicationEvent
Spring 的扩展点，

集群架构搭建