docker-compose方式部署
官方Demo
1. 下载demo
git clone https://github.com/nacos-group/nacos-docker.git
cd nacos-docker/example
2. 执行脚本
因为官方它这个要内嵌数据库,我们生产一般不会在去为它单独搞一个msql,直接用我们业务现成的。
所以需要在我们现有的mysql执行db脚本(创建数据库和表,它这边默认是nacos_config)
sql执行脚本:
https://github.com/alibaba/nacos/blob/develop/distribution/conf/nacos-mysql.sql
https://github.com/alibaba/nacos/blob/develop/distribution/conf/schema.sql
3. 编辑docker-compose文件
修改compose文件(指定版本号和修改连接mysql的配置文件)
version: "3"
services:
nacos:
image: nacos/nacos-server:1.4.2
container_name: nacos-standalone-mysql
environment:
- PREFER_HOST_MODE=hostname
- SPRING_DATASOURCE_PLATFORM=mysql
- MODE=standalone
- MYSQL_SERVICE_HOST=192.168.1.148
- MYSQL_SERVICE_DB_NAME=nacos_config
- MYSQL_SERVICE_PORT=3307
- MYSQL_SERVICE_USER=root
- MYSQL_SERVICE_PASSWORD=123456
- NACOS_APPLICATION_PORT=8848
- MYSQL_SERVICE_DB_PARAM=characterEncoding=utf8&connectTimeout=10000&socketTimeout=30000&autoReconnect=true&useSSL=false
- JVM_XMS=512m
- JVM_MMS=320m
volumes:
- ./standalone-logs/:/home/nacos/logs
ports:
- "8848:8848"
restart: always
4. 查看日志
启动成功后,查看start.out日志,会发现我们连接外部数据库是ok的
如果你连接的不是外部数据库,默认是采用嵌入式的数据库则日志启动如下:
5. 更换mysql用户名:
当然如果你希望换个用户名,需要链接mysql实例进行操作,我是为了省事。
CREATE USER 'nacos'@'%' IDENTIFIED BY 'nacos';
grant all privileges on nacos_config.* to 'nacos'@'%' identified by 'nacos';
flush privileges;
备注:nacos默认优先读取配置中心的数据,而非本地配置的数据,切记!
参考文档:
官方文档:https://nacos.io/zh-cn/docs/quick-start-docker.html
k8s单机版
service
apiVersion: v1
kind: Service
metadata:
name: nacos-headless
namespace: prod
labels:
app: nacos
annotations:
service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"
spec:
type: NodePort
ports:
- port: 8848
nodePort: 30002
name: server
targetPort: 8848
selector:
app: nacos
ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: nacos-config-map
namespace: prod
data:
prefer.host.mode: "hostname"
spring.datasource.platform: "mysql"
mode: "standalone"
nacos.application.port: "8848"
mysql.service.host: "10.10.10.145"
mysql.service.db.name: "nacos_config"
mysql.service.port: "30001"
mysql.service.user: "root"
mysql.service.password: "123456"
mysql.service.db.param: "characterEncoding=utf8&connectTimeout=10000&socketTimeout=30000&autoReconnect=true&useSSL=false"
jvm.xms: "512m"
jvm.mms: "320m"
StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nacos
namespace: prod
spec:
serviceName: nacos
replicas: 1
template:
metadata:
labels:
app: nacos
selector:
matchLabels:
app: nacos
spec:
containers:
- name: nacos
imagePullPolicy: IfNotPresent
image: nacos/nacos-server:1.4.2
resources:
requests:
memory: "2Gi"
cpu: "500m"
ports:
- containerPort: 8848
env:
- name: PREFER_HOST_MODE
value: "hostname"
- name: SPRING_DATASOURCE_PLATFORM
value: "mysql"
- name: MODE
value: "standalone"
- name: NACOS_APPLICATION_PORT
value: "8848"
- name: MYSQL_SERVICE_HOST
value: "10.10.10.145"
- name: MYSQL_SERVICE_DB_NAME
value: "nacos_config"
- name: MYSQL_SERVICE_PORT
value: "30001"
- name: MYSQL_SERVICE_USER
value: "root"
- name: MYSQL_SERVICE_PASSWORD
value: "123456"
- name: MYSQL_SERVICE_DB_PARAM
value: "characterEncoding=utf8&connectTimeout=10000&socketTimeout=30000&autoReconnect=true&useSSL=false"
- name: JVM_XMS
value: "512m"
- name: JVM_MMS
value: "320m"
volumeMounts:
- name: logs
mountPath: /home/nacos/logs
volumes:
- name: logs
hostPath:
path: /root/project-server/nacos/k8s/logs
StatefulSet(comfigmap)
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nacos
namespace: prod
spec:
serviceName: nacos-headless
replicas: 1
template:
metadata:
labels:
app: nacos
spec:
containers:
- name: nacos
imagePullPolicy: IfNotPresent
image: nacos/nacos-server:1.4.2
resources:
requests:
memory: "2Gi"
cpu: "500m"
ports:
- containerPort: 8848
env:
- name: PREFER_HOST_MODE
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: prefer.host.mode
- name: SPRING_DATASOURCE_PLATFORM
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: spring.datasource.platform
- name: MODE
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: mode
- name: NACOS_APPLICATION_PORT
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: nacos.application.port
- name: MYSQL_SERVICE_HOST
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: mysql.service.host
- name: MYSQL_SERVICE_DB_NAME
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: mysql.service.db.name
- name: MYSQL_SERVICE_PORT
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: mysql.service.port
- name: MYSQL_SERVICE_USER
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: mysql.service.user
- name: MYSQL_SERVICE_PASSWORD
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: mysql.service.password
- name: MYSQL_SERVICE_DB_PARAM
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: mysql.service.db.param
- name: JVM_XMS
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: jvm.xms
- name: JVM_MMS
valueFrom:
configMapKeyRef:
name: nacos-config-map
key: jvm.mms
volumeMounts:
- name: logs
mountPath: /home/nacos/logs
volumes:
- name: logs
hostPath:
path: /root/project-server/backend/nacos/logs
selector:
matchLabels:
app: nacos
问题点
1. 通过nacos发现getway内部容器里面无法ping通外网
当我们把应用部署在148服务器上后,我们启动本地105的一个服务,发现自己某个服务已经注册到nacos,但是转发到我本地105服务失败了,检测发现内部无法ping 通105和百度,需要重启下docker。在检查下网络是否通畅。
systemctl 方式
守护进程重启
sudo systemctl daemon-reload
重启docker服务
sudo systemctl restart docker
关闭docker
sudo systemctl stop docker
service 方式
重启docker服务
sudo service docker restart
关闭docker
sudo service docker stop
再见了nacos
下面文章转载于:文章地址
在阐述Service Mesh服务注册发现机制前,先简单回顾下在以Spring Cloud为代表的传统微服务中是如何实现服务注册与发现的。
nacos基本原理
先说下nacos基本原理:微服务启动时会通过集成的服务发现SDK,向注册中心(应用配置的注册中心地址)发送注册信息,注册中心在收到服务注册请求后将存储服务的基本信息,比如我们这里存储服务是mysql;之后,如有服务消费者要调用该服务,那么调用方通过服务发现组件(例如Ribbon)就可以向注册中心查询目标微服务的地址列表,并通过获取的服务地址列表,以某种负载策略向目标微服务发起调用了。
而当服务节点发现变更时,新的节点会被重新注册,而下线的节点基于服务探活机制也会及时从服务注册中心被踢除,基于这样的服务注册/发现机制,微服务之间的通信顺畅就能得到保证。从这个角度看,注册中心与服务之间的健康性检查就显得很重要,如果注册中心不能及时将下线或故障的节点从可用服务器地址列表剔除,那么就很可能会造成微服务某些调用的失败。
那么一般怎样进行服务健康性检查呢?从方式上看,主流的健康性检查方式,主要有以下3种:
健康检查方式
1. 微服务主动探活
服务主动探活就是微服务定期向注册中心发送租约信息以表面自己的存活。在实际场景中主动探活是我们使用注册中心时用得最多的一种方式,如果服务规模不大,或者使用了类似于Eureka这样的最终一致性注册中心,那么主动探活就是一种最佳选择,它可以较大程度地避免服务部署在Kubernetes集群后,因为Pod IP重用而导致的旧有服务节点依然存活的问题,毕竟续约信息都是带着服务基础信息上报到注册中心的。
但这种方式也有明显的弊端,它会造成注册中心写操作压力变大。如果大量的服务同时发布,节点产生较大的变动,那么就可能产生大量的通知事件,从而对整个微服务体系的稳定产生较大影响。
此外,主动续约,也并不完全说明服务是健康的,因为某些特殊情况下可能会存在虽然服务无法对外提供服务,但还能正常向注册中心发出租约信息的问题。
2. 注册中心发起健康性检查
前面分析了微服务主动探活方式的优缺点,而如果由注册中心发起健康性检查会怎么样呢?
这种方式是指微服务在注册时,同时向注册中心暴露自己的健康检查端点(如/actuator/health),注册中心通过定期访问来探测服务节点是否存活。
不过这种方式也不是完全没有问题,例如前面提到的Pod IP重用问题,如果其他微服务重用了之前节点的IP,那么就会发生失效节点被激活的假象。当然也有相应的解决方案,例如后面会讲到Istio微服务注册发现时Envoy会对服务名称进行二次Check的方式。
3.调用方负载均衡器进行健康性检查
第3种方案比较极端,注册中心不进行任何服务探活,全部由微服务调用方所在的负载均衡器进行探活。这种方案常见的一种场景就是gRPC的失效节点自动摘除功能。但这种方案依然具有IP被重用问题,所以此种方式在实际的场景中并不是很受欢迎。
前面讲了微服务注册发现常见的三种服务探活方式,其实三种方案各有利弊。以Spring Cloud微服务体系中,使用最广泛的几种注册中心为例,如Eureka、Consul、Nacos,它们的对比如下表所示:
从表格中可以看到,除了Eureka主要采用服务主动探活方式外,Consul及Nacos都采用了多种服务探活方式,从而尽量规避不同方式的弊端,这也是为什么目前大部分实践逐步抛弃Eureka而采用Consul或Nacos的原因。
除了健康性检查外,上面表格还分别列出了这几种注册中心的一致性协议。这里顺带普及下CAP理论。CAP是分布式系统中重要的一种概念,它分别由一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)三部分组成。在CAP理论中,一个分布式系统不可能三种都满足,一般只能同时满足其中的两种,而作为分布式系统分区容错基本都是要满足的所以Partition tolerance基本必不可少。例如Eureka和Nacos只能满足可用性和分区容错性,而无法满足一致性;Consul则只能满足一致性和分区容错性,而无法完全满足可用性。
在注册中心的场景中,一致性一般要求并不高,只要能达到最终一致性即可。毕竟在微服务架构中,涉及节点的注册和反注册,注册中心和客户端之间的通信需要一定时间,一致性本身也很难达到。所以在注册中心的选型中,一般会优先选择AP的系统,这也是目前还在以Spring Cloud构建微服务的实践中,除了自研外,开源技术中会优先选择Nacos作为服务注册中心的原因。
弊端
传统微服务体系中,注册中心无疑是整个微服务体系最重要的组成部分,没有服务注册中心提供的统一服务注册发现功能,微服务本身就无从谈起。不过相较于Service Mesh架构中服务注册发现,很大程度上是依赖于基础设施(例如数据面[envoy]、控制面[istio]以及Kubernetes集群),而无需微服务亲力亲为。在Spring Cloud传统架构中,服务注册、发现及健康性检查等服务治理逻辑则都需要微服务自己上下打点。
虽然不用重复造轮子,都有现成的服务治理组件及框架,但从应用运行形态上说,与服务注册发现相关的逻辑都是微服务直接与注册中心产生的交互。从系统架构上看,这种方式显然是将服务治理逻辑与业务应用耦合了,其运行逻辑如下图所示: