微服务架构思维笔记模板_ProcessOn思维导图、流程图

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 全新的研发流程