微服务架构
2021-08-19 15:27:38 1 举报单体到微服务的架构发布
作者其他创作
大纲/内容
1 单体走向微服务
什么时候进行服务化拆分, 或者微服务划分的粒度？
1. 服务的关联维度进行拆分
2. 数据库隔离维度进行拆分
服务如何定义？
服务如何发布和订阅？
发布和订阅三种常见的方式：
restful api
xml 配置
IDL 文件
RPC 远程服务调用
客户端和服务端如何建立网络连接
http 通信 - 短连接
socket通信 - 长连接
服务端如何处理请求
BIO - 同步阻塞方式 - 这个比较符合我们县杂的应用场景
NIO - 同步非阻塞方式
AIO - 异步非阻塞方式
数据传输采用什么协议
数据该如何序列化和反序列化
问题： 服务器调用可不可以用消息队列
服务如何监控？
相关名词解释
监控指标
请求量
响应时间
错误率
监控纬度
监控对象
用户端监控 - 业务需求，例如：排序
用户端监控 - 业务需求，例如：排序
用户端监控 - 业务需求，例如：排序
用户端监控 - 业务需求，例如：排序
接口监控
接口监控
接口监控
接口监控
资源监控
资源监控
资源监控
资源监控
基础监控
基础监控
基础监控
基础监控
数据采集
服务如何治理？
节点管理：
注册中心主动摘除机制（心跳包）
服务消费者摘除机制
负载均衡
随机算法
轮询算法
最少活跃调用算法
一致性 Hash 算法
服务路由
业务存在灰度发布的需求
多机房就近访问的需求
服务容错
FailOver: 失败自动切换
FailBack: 失败通知
FailCache: 失败缓存
FailFast: 快速失败
服务如何定位？
2 微服务架构
服务描述
常用的服务描述方式包括 RESTful API，XML， IDL 三种
向注册中心注册服务时，声明自己是做什么的，能够提供那些服务，地址是什么
注册中心
主要是解决服务的发布和订阅，服务提供者将自己提供的服务以及地址登记到注册中心，服务消费者则从注册中心查询所需要调用的服务地址，发起请求
工作流程
注册：服务提供者 -> 注册中心
订阅：服务消费者 -> 注册中心
通知：注册中心 -> 服务消费者
调用：服务消费者 -> 服务提供者
监控：监控服务消费者和服务提供者
实现方式
注册中心API
集群部署
目录存储
服务健康状态检测
服务状态变更通知
白名单机制
服务框架
服务提供者
服务消费者
服务注册中心
服务监控
服务追踪
服务治理
3 微服务使用
服务的发布和引用
服务提供者定义接口
服务提供者发布接口
服务消费者引用接口
注册中心选型和落地
注册中心工作流程
1. 查看是否在白名单中
2. 查看注册的Cluster（服务的接口名）是否存在
3. 检查service 是否存在
4. 将节点信息添加到对应的service 和 cluster 中
反注册工作流
1. 查看 Service（服务的分组）是否存在
2. 查看 Cluster（服务的接口名）是否存在
3. 删除存储中 Service 和 Cluster 下对应的节点信息
4. 更新 Cluster 的 sign 值
查询节点信息
1. 首先从 localcache（本机内存）中查找
2. 接着从 snapshot（本地快照）中查找，
订阅服务变更
1. 服务消费者从注册中心获取了服务的信息后，就订阅了服务的变化，会在本地保留 Cluster 的 sign 值
2. 服务消费者每隔一段时间，调用 getSign() 函数，从注册中心获取服务端该 Cluster 的 sign 值，并与本地保留的 sign 值做对比，如果不一致，就从服务端拉取新的节点信息，并更新 localcache 和 snapshot。
选型
1. 应用内注册与发布
2. 应用外注册与发布
服务监控系统的搭建
集中式日志解决方案： ELK
ELK，Elasticsearch, Logstash,Kibana 三个开源软件的首字母缩写
Logstash 负责数据的收集和传输
Elasticsearch 服务数据的处理
Kibana 负责数据展示
时序数据库解决方案： Graphite, TICK, Prometheus
Graphite ：Carbon, Whisper, Graphite-Web
Carbon:接收被监控节点的连接，收集各个指标的数据，将这些数据写入 carbon-cache 并最终持久化到 Whisper 存储文件中去。
Whisper
Graphite-Web
TICK: Telegraf、InfluxDB、Chronograf、Kapacitor 四个软件首字母的缩写
Prometheus
选型对比
数据收集
ELK 是通过在每台服务器上部署 Beats 代理来采集数据；
Graphite 本身没有收据采集组件，需要配合使用开源收据采集组件，比如 StatsD；
TICK 使用了 Telegraf 作为数据采集组件；
Prometheus 通过 jobs/exporters 组件来获取 StatsD 等采集过来的 metrics 信息。
数据传输
【推】ELK 是 Beats 采集的数据传输给 Logstash，经过 Logstash 清洗后再传输给 Elasticsearch；
【推】Graphite 是通过第三方采集组件采集的数据，传输给 Carbon
【推】TICK 是 Telegraf 采集的数据，传输给 InfluxDB
【拉】Prometheus 是 Prometheus Server 隔一段时间定期去从 jobs/exporters 拉取数据。
数据处理
数据展示
服务追踪系统的搭建
PinPoint - 深度支持java，
OpenZipKin
Collector：负责收集探针 Reporter 埋点采集的数据，经过验证处理并建立索引。
Storage：存储服务调用的链路数据，默认使用的是 Cassandra，是因为 Twitter 内部大量使用了 Cassandra，你也可以替换成 Elasticsearch 或者 MySQL。
API：将格式化和建立索引的链路数据以 API 的方式对外提供服务，比如被 UI 调用。
UI：以图形化的方式展示服务调用的链路数据。
工作原理：
4 微服务进行容器化运维
镜像仓库和资源调度
镜像仓库
权限控制
镜像同步
高可用
资源调度
容器调度和服务编排
容器调度:业界最有名的莫过于 Swarm、Mesos 和 Kubernetes
服务编排
服务依赖
服务发现
基于 Nginx 的服务发现
基于 注册中心的服务发现
自动扩缩容
容器运维平台DCP
5 DevOps 全新的研发流程
0 条评论
下一页
