分布式服务一篇概览

分布式服务开发复杂于服务间交互，协调，治理等。服务的复杂性由应用本身转移到了网络交互层。

一、关于 12-factor 问题

在开发分布式服务时，我们通常会考虑如 12-factor 问题，如配置中心、无状态化、日志等。

一个代码库：支持多人协作开发的代码集中管理平台。

一个依赖库：服务依赖发布、存储、隔离等管理。

一个配置中心：集中的配置管理中心，服务，协调多服务应用。

可插拔的支持服务：如数据库、消息中间件、三方服务等。

构建、发布、运行过程管理：服务发布管理。

每一个服务实例都是一个无状态的工作进程。

服务通过绑定特定的端口对外提供服务。

通过增减服务实例类型及数量来实现服务伸缩。

快速启动，优雅关机增强服务健壮性。

尽可能的保持开发、测试及生产环境一致性。

事件流形式处理日志，分离影响。

脚本或命令行式的服务管理工具支持。

二、总览

借用一张图：

 

三、服务发现

当由多个服务实例提供服务时，客户端需要知道都有哪些可调用服务，服务的具体位置以及怎么调用。

分布式协调服务：服务注册与发现。如 Eureka(AP)、Consul(CP)、Zookeeper(CP)、Nacos(CP + AP) 及 Etcd (CP)等。

示例 Nacos 架构图：

四、API 网关

客户端及服务端之间是多对对关系，对于涉及到统一权限管理、路由负载、日志、监控等支持性功能需求，网关服务处理相对更加合适。如 Spring Cloud Gateway、nginx、OpenResty、zuul、APISIX 等。

示例 Spring Gate Way 工作流程：

五、配置中心

独立的服务配置可以和服务集成在一起，对于分布式多服务模式，灵活、集中的配置管理则非常必要。

配置中心一般需要提供配置添加、删除、更新管理，环境管理、灰度管理、版本控制等。如 Apollo、 Nacos、Spring Cloud Config 等。 

Apollo vs Spring Cloud Config：

功能点	Apollo	Spring Cloud Config	备注
配置界面	一个界面管理不同环境、不同集群配置	无，需要通过git操作
配置生效时间	实时	重启生效，或手动refresh生效	Spring Cloud Config 需要通过Git webhook， 加上额外的消息队列才能支持实时生效
版本管理	界面上直接提供发布历史和回滚按钮	无，需要通过git操作
灰度发布	支持	不支持
授权、审核、审计	界面上直接支持，而且支持修改、发布权限分离	需要通过git仓库设置，且不支持修改、发布权限分离
实例配置监控	可以方便的看到当前哪些客户端在使用哪些配置	不支持
配置获取性能	快，通过数据库访问，还有缓存支持	较慢，需要从git clone repository，然后从文件系统读取
客户端支持	原生支持所有Java和.Net应用， 提供API支持其它语言应用， 同时也支持Spring annotation获取配置	支持Spring应用，提供annotation获取配置	Apollo的适用范围更广一些

六、服务治理

分布式服务涉及多服务间协调共同对外提供服务。相对来说，会有更多的不可控因素影响其可用性，如服务间调用超时、流量过载等，因此服务治理也是一门必修课。

熔断降级、流量控制支持： Spring Cloud Circuit Breaker、 Resilience4J、 Sentinel、 Hystrix。

Sentinel 示例：

七、链路追踪

分布式服务使得问题追踪变得很困难，需要综合请求路径上不同服务节点表现来定位问题。因此首先需要有一条链，一条从请求调用入口到服务底层再到返回的完整追踪链路。

支持组件如： Spring Cloud Sleuth、 Zipkin、 SkyWalking。

示例 SkyWalking 架构图：

八、日志

汇总所有服务日志顺序综合展示。包括日志收集，传送，落库存储及展示等。

典型如 ELK，logstash 负责收集日志数据及传送，ElasticSearch 负责存储，Kibana 负责 查询展示。

数据采集存在多种可选收集器：如 filebeat(更轻量)、logstash、Fluentd 等。

九、监控

(Prometheus | Zabbix)+ Grafana 

1、Promethueus

开源系统监控报警系统。负责收集，存储时间序列监控数据并展示。整体架构图如下：

2、Zabbix

开源的分布式监控解决方案。

3、Grafana

提供查询，多维度可视化展示，报警等功能。

 

十、附加订阅