目录

一：微服务架构

1.0：单体架构

1.1：微服务架构

1.2：微服务架构的优势

1.3：微服务架构的缺点(挑战)

1.4：SpringCloud与微服务关系

1.5：SpringBoot和SpringCloud关系

二：服务注册与发现

2.1：服务注册与发现

2.2：注册中心对比

nacos功能与架构

三：nacos简介

nacos功能：

 nacos安装

1、下载解压

2、配置

3、创建数据库以及表（conf>nacos-mysql.sql）

4、配置startup.cmd，以standalone方式启动

5、启动

nacos注册中心工作流程

Nacos配置中心

主流配置中心对比

---

一：微服务架构

1.0：单体架构

将项目所有模块（功能）打成jar或者war，然后部署一个进程

优点：
1：部署简单: 由于是完整的结构体，可以直接部署在一个服务器上即可。
2：技术单一: 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。
3：用人成本低: 单个程序员可以完成业务接口到数据库的整个流程。
​
缺点：
1：系统启动慢， 一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长;
2：系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机;
3：可伸缩性差：系统的扩容只能只对这个应用进行扩容，无法结合业务模块的特点进行伸缩。
4：线上问题修复周期长：任何一个线上问题修复需要对整个应用系统进行全面升级。
5. 跨语言程度差
6. 不利于安全管理，所有开发人员都拥有全量代码

1.1：微服务架构

解读微服务特点:

1:微服务是一种项目架构思想(风格)

2:微服务架构是一系列小服务的组合（组件化与多服务）

3:任何一个微服务，都是一个独立的进程（独立开发、独立维护、独立部署）

4:轻量级通信http协议(跨语言,跨平台)

5:服务粒度(围绕业务功能拆分)

6:去中心化管理(去中心化”地治理技术、去中心化地管理数据)

1.2：微服务架构的优势

1.易于开发和维护 一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态；

2.单个微服务启动较快 单个微服务代码量较少，所以启动会比较快；

3.局部修改容易部署 单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可；

4.技术栈不受限 在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈

5.按需伸缩

1.3：微服务架构的缺点(挑战)

1、服务太多，导致服务间的依赖错综复杂，运维难度大

2、微服务放大了分布式架构的系列问题

• 分布式事务（seata）、

• 分布式锁怎么处理（redisson），

• 服务注册与发现（nacos）、

• 依赖服务不稳定（sentinel）导致服务雪崩怎么办？

3、运维复杂度陡增，部署数量多、监控进程多导致整体运维复杂度提升。

1.4：SpringCloud与微服务关系

• Springcloud为微服务思想提供了完美的解决方案

• Springcloud是一些列框架的集合体（服务的注册与发现【注册中心】、服务间远程调用、服务降级、服务熔断、服务限流、分布式事务 等）

  一般我们说springcloud 其实指的是Springcloud-netflix，Springcloud并不是造轮子，只是把Netflix公司的组件做二次开发
  

1.5：SpringBoot和SpringCloud关系

• SpringBoot专注于快速方便的开发单个个体微服务。

• SpringCloud是关注全局的微服务协调、整理、治理的框架，它将SpringBoot开发的单体整合并管理起来。

• SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系。

二：服务注册与发现

2.1：服务注册与发现

服务注册，就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去（比如: zookeeper\consul\eureka\nacos）。

服务发现，就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

2.2：注册中心对比

nacos：是阿里开源的，经过了阿里实践的

eureka：netflix公司的，现在不维护了，不开源了

Consul : HashiCorp 公司推出的开源产品，用于实现分布式系统的服务发现、服务隔离、服务配置

对比组件	Nacos	Eureka	Consul	Zookeeper
一致性对比	支持AP和CP模型	AP模型	CP模型	CP模型
健康检查	tcp/http/client Beat	client Beat	TCP/HTTP/gRPC	keep Alive
负载均衡策略	Ribbon	Ribbon	Fabio	-
雪崩保护	有	有	无	无
自动注销实例	支持	支持	不支持	支持
访问协议	HTTP	HTTP	HTTP	TCP
监听支持	支持	支持	支持	支持
多数据中心	支持	支持	支持	不支持
跨注册中心同步	支持	不支持	支持	不支持
Springcloud集成	支持	支持	支持	不支持
Dubbo集成	支持	不支持	不支持	支持
K8s集成	支持	不支持	支持	不支持

三：nacos简介

nacos架构：

nacos功能：

• 名字服务 (Naming Service)

命名服务是指通过指定的名字来获取资源或者服务的地址，提供者的信息

• 配置服务 (Configuration Service)

动态配置服务让您能够以中心化、外部化和动态化的方式管理所有环境的配置。动态配置消除了配置变更时重新部署应用和服务的需要。配置中心化管理让实现无状态服务更简单，也让按需弹性扩展服务更容易。

 nacos安装

下载地址:https://github.com/alibaba/nacos/tags

1、下载解压

2、配置

3、创建数据库以及表（conf>nacos-mysql.sql）

注意 新版本的 nacos 的 数据库文件 叫 nacos-mysql.sql , schema.sql 是 derby 数据库的 注意 不要选择错了，

4、配置startup.cmd，以standalone方式启动

5、启动

nacos注册中心工作流程

        Nacos支持CP+AP模式，即Nacos可以根据配置识别为CP模式或AP模式，默认是AP模式。如果注册Nacos的client节点注册时ephemeral=true，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现；而注册Nacos的client节点注册时ephemeral=false，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。根据client注册时的属性，AP，CP同时混合存在，只是对不同的client节点效果不同。Nacos可以很好的解决不同场景的业务需求。

一句话概括就是Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。

Nacos配置中心

小结：

Nacos：注册中心，解决服务的注册与发现

Ribbon：客户端的负载均衡器，服务集群的负载均衡

OpenFeign：声明式的HTTP客户端，服务远程调用

Nacos：配置中心，中心化管理配置文件

主流配置中心对比

目前市面上用的比较多的配置中心有：Spring Cloud Config、Apollo、Nacos和Disconf等。 由于Disconf不再维护，下面主要对比一下Spring Cloud Config、Apollo和Nacos。

对比项目	Spring Cloud Config	Apollo	Nacos
配置实时推送	支持（Spring Cloud Bus）	支持(HTTP长轮询1s内)	支持(HTTP长轮询1s内)
版本管理	支持（Git）	支持	支持
配置回滚	（Git）支持	支持	支持
灰度发布	支持	支持	不支持
权限管理	支持（依赖Git）	支持	不支持
多集群	支持	支持	支持
多环境	支持	支持	支持
监听查询	支持	支持	支持
多语言	只支持Java	主流语言，提供了Open API	主流语言，提供了Open API
配置格式校验	不支持	支持	支持
单机读(QPS)	7（限流所致）	9000	15000
单机写(QPS)	5（限流所致）	1100	1800
3节点读(QPS)	21（限流所致）	27000	45000
3节点写(QPS)	5（限流所致）	3300	5600

        从配置中心 角度来看，性能方面Nacos的读写性能最高，Apollo次之，Spring Cloud Config依赖Git场景不适合开放的大规模自动化运维API。
        功能方面 Apollo最为完善，nacos具有Apollo大部分配置管理功能，而Spring CloudConfig不带运维管理界面，需要自行开发。
        Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。