面试总结第54天微服务开始

第54天 -微服务-zookeeper-kafka

前言核心内容总结

1.了解内容

单体(巨石)架构

传统架构（单机系统），一个项目一个工程：比如:商品、订单、支付、库存、登录、注册等等，统一部署，一个进程。

all in one的架构方式，把所有的功能单元放在一个应用里。然后把整个应用部署到一台服务器上。如果负载能力不行，将整个应用进行水平复制，进行扩展，然后通过负载均衡实现访问。
架构简单,部署方便,打包编译部署升级效率低下,各功能耦合度高,扩展困难,扩缩容不灵活,适合小型简单项目

SOA（Service Oriented Architecture）是由多个服务组成的分布式系统

各个服务之间通过ESB(Enterprise Service Bus)进行通信,ESB是一个由大量规则和原则集成的软件架构，可以将一系列不同的应用程序集成到单个基础架构中，由于没有好的开源方案，只能使用商业公司的产品,因此成本很高。ESB的单点依赖和商业ESB的费用问题反而成为了所有服务的瓶颈。

2.什么是微服务？

微服务（Microservices）是一种软件架构设计模式，它将一个复杂的应用程序拆分为多个小型、独立的服务，每个服务专注于完成单一业务功能，并通过轻量级通信机制（如 HTTP/REST、gRPC）协同工作。简单来说，就是 “化整为零”—— 把原来一个庞大的单体应用，拆成多个可独立开发、部署、维护的小服务。

微服务还是单体，单体在绝大部分时候是更好的选择，即单体优先。

3.Spring Cloud

Spring Cloud

官网地址: https://spring.io/projects/spring-cloud

SpringCloud是目前国内使用最广泛的Java微服务框架。

4.什么是无服务架构（serverless）？

无服务架构（Serverless Architecture） 是一种云计算模型，核心特点是开发者无需关心底层服务器的管理、运维、扩展等基础设施问题，只需专注于编写业务逻辑代码，由云厂商自动处理服务器的资源分配、弹性伸缩、故障恢复等工作。

5.Zookeeper是什么？工作流程是什么？

ZooKeeper 是一个分布式服务框架，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：命名服务、状态同步、配置中心、集群管理等。

ZooKeeper 是一个开源的分布式协调服务，ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
学习zookeeper是因为它是kafka的重要组件，不过kafka4.0以后不再依赖zookeeper，Kafka 4.0 依赖 KRaft

工作流程如下：

1. 生产者启动

2. 生产者注册至zookeeper

3. 消费者启动并订阅频道

4. zookeeper 通知消费者事件

5. 消费者调用生产者

6. 监控中心负责统计和监控服务状态

生产者、消费者：独享 抢占式
订阅者：共享

6.zookeeper的安装与配置

zookeeper依赖java环境 需要安装jdk或jre

安装略
配置按照二进制安装的配置    我将建议修改成的用红色的字体标出 
[root@ubuntu1804 ~]#grep -v "#" /usr/local/zookeeper/conf/zoo.cfg

tickTime=2000  #"滴答时间"，用于配置Zookeeper中最小的时间单元长度，单位毫秒，是其它时间配置的基础  

initLimit=10   #初始化时间，包含启动和数据同步，其值是tickTime的倍数

syncLimit=5    #正常工作，心跳监测的时间间隔，其值是tickTime的倍数

dataDir=/tmp/zookeeper #配置Zookeeper服务存储数据快照的目录,可以自动创建,可以修改为 dataDir=/usr/local/zookeeper/data

dataLogDir=/usr/local/zookeeper/logs  #指定日志路径，默认与 dataDir 一致,事务日志对性能影响非常大，强烈建议事务日志目录和 数据目录分开，如果后续修改路径，需要先删除中dataDir中旧的事务日志，否则可能无法启动，此目录可以自动创建,

clientPort=2181 #配置当前Zookeeper服务对外暴露的端口，用户客户端和服务端建立连接会话

preAllocSize：#为事务日志预先开辟磁盘空间。默认是64M，意味着每个事务日志初始大小64M。如果ZooKeeper产生快照频率较大，可以考虑减小这个参数，因为每次快照后都会切换到新的事务日志，即使前面的64M没有写满。

snapCount：#该配置项指定ZooKeeper在将内存数据库保存为快照之前，需要先写多少次事务日志，即，每写几次事务日志就快照一次。默认值为

100000。为了防止所有的ZooKeeper服务器节点同时生成快照(一般情况下，所有集群的实例的配置文件是完全相同的)，当某节点的先写事务数量在

(snapCount/2+1,snapCount)范围内时挑选一个随机值做为该节点拍快照的时机。

autopurge.snapRetainCount=3 #3.4.0中的新增功能：启用后，ZooKeeper 自动清除功能,会将只保留此最新3个快照和相应的事务日志,并分别保留在dataDir 和dataLogDir中，删除其余部分，默认值为3,最小值为3

autopurge.purgeInterval=24  #3.4.0及之后版本，ZK提供了自动清理日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是 0，表示不开启自动清理功能

#通过prometheus监控的相关配置,需要stop再start，restart可能会失败

## Metrics Providers

#

# https://prometheus.io Metrics Exporter

#提供prometheus监控功能

metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider

metricsProvider.httpHost=0.0.0.0

metricsProvider.httpPort=7000

metricsProvider.exportJvmInfo=true

定义dataDir目录出现FAILED TO START的报错  原因是dataDir=/usr/local/zookeeper 这么写

开启：/usr/share/zookeeper/bin/zkServer.sh start   适用于包安装

7.ZooKeeper 集群部署

集群角色

1 领导者(Leader)

负责处理写入请求的，事务请求的唯一调度和处理者,负责进行投票发起和决议，更新系统状态

2 跟随者(Follower)

接收客户请求并向客户端返回结果，在选Leader过程中参与投票

3 观察者(Observer)

转交客户端写请求给leader节点，和同步leader状态和Follower唯一区别就是不参与Leader投票,也不参与写操作的"过半写成功"策略

4 学习者(Learner)

和leader进行状态同步的节点统称Learner，包括:Follower和Observer

5 客户端(client)

请求发起方

集群特性：整个集群中只要有超过集群数量一半的 zookeeper工作是正常的，那么整个集群对外就是可用的。反之则不可用

只需要在所有主机的配置文件zoo.cfg里面添加下面的内容 其中
2888端口用于 ZooKeeper 集群内各节点之间的 Leader 选举和数据同步
3888端口用于 ZooKeeper 集群内的 Leader 选举投票。

#格式: server.MyID服务器唯一编号=服务器IP:Leader和Follower的数据同步端口(只有leader才会打开):Leader和Follower选举端口(L和

F都有)

server.1=10.0.0.101:2888:3888

server.2=10.0.0.102:2888:3888

server.3=10.0.0.103:2888:3888

在各个节点生成ID文件

[root@zookeeper-node1 ~]#mkdir /usr/local/zookeeper/data; echo 1 > /usr/local/zookeeper/data/myid

[root@zookeeper-node2 ~]#mkdir /usr/local/zookeeper/data; echo 2 > /usr/local/zookeeper/data/myid

[root@zookeeper-node3 ~]#mkdir /usr/local/zookeeper/data; echo 3 > /usr/local/zookeeper/data/myid