目录
3、创建数据库以及表（conf>nacos-mysql.sql）
4、配置startup.cmd，以standalone方式启动
一：微服务架构
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都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。
3078
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
