分布式服务一篇概览

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

一、关于 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：

相关内容拓展：（技术前沿）

近 10 年间，甚至连传统企业都开始大面积数字化时，我们发现开发内部工具的过程中，大量的页面、场景、组件等在不断重复，这种重复造轮子的工作，浪费工程师的大量时间。

针对这类问题，低代码把某些重复出现的场景、流程，具象化成一个个组件、api、数据库接口，避免了重复造轮子。极大的提高了程序员的生产效率。

推荐一款程序员都应该知道的软件 JNPF 快速开发平台，采用业内领先的 SpringBoot 微服务架构、支持 SpringCloud 模式，完善了平台的扩增基础，满足了系统快速开发、灵活拓展、无缝集成和高性能应用等综合能力；采用前后端分离模式，前端和后端的开发人员可分工合作负责不同板块，省事又便捷。

免费体验官网：https://www.jnpfsoft.com/?infoq

还没有了解低代码这项技术可以赶紧体验学习！

六、服务治理

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

熔断降级、流量控制支持：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

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