分布式服务开发复杂于服务间交互,协调,治理等。服务的复杂性由应用本身转移到了网络交互层。
在开发分布式服务时,我们通常会考虑如 12-factor 问题,如配置中心、无状态化、日志等。
一个代码库:支持多人协作开发的代码集中管理平台。
一个依赖库:服务依赖发布、存储、隔离等管理。
一个配置中心:集中的配置管理中心,服务,协调多服务应用。
可插拔的支持服务:如数据库、消息中间件、三方服务等。
构建、发布、运行过程管理:服务发布管理。
每一个服务实例都是一个无状态的工作进程。
服务通过绑定特定的端口对外提供服务。
通过增减服务实例类型及数量来实现服务伸缩。
快速启动,优雅关机增强服务健壮性。
尽可能的保持开发、测试及生产环境一致性。
事件流形式处理日志,分离影响。
脚本或命令行式的服务管理工具支持。
借用一张图:
当由多个服务实例提供服务时,客户端需要知道都有哪些可调用服务,服务的具体位置以及怎么调用。
分布式协调服务:服务注册与发现。如 Eureka(AP)、Consul(CP)、Zookeeper(CP)、Nacos(CP + AP) 及 Etcd (CP)等。
示例 Nacos 架构图:
客户端及服务端之间是多对对关系,对于涉及到统一权限管理、路由负载、日志、监控等支持性功能需求,网关服务处理相对更加合适。如 Spring Cloud Gateway、nginx、OpenResty、zuul、APISIX 等。
示例 Spring Gate Way 工作流程:
功能点 | Apollo | Spring Cloud Config | 备注 |
---|---|---|---|
配置界面 | 一个界面管理不同环境、不同集群配置 | 无,需要通过git操作 | |
配置生效时间 | 实时 | 重启生效,或手动refresh生效 |
Spring Cloud Config 需要通过Git webhook, 加上额外的消息队列才能支持实时生效 |
版本管理 | 界面上直接提供发布历史和回滚按钮 | 无,需要通过git操作 | |
灰度发布 | 支持 | 不支持 | |
授权、审核、审计 | 界面上直接支持,而且支持修改、发布权限分离 | 需要通过git仓库设置,且不支持修改、发布权限分离 | |
实例配置监控 | 可以方便的看到当前哪些客户端在使用哪些配置 | 不支持 | |
配置获取性能 | 快,通过数据库访问,还有缓存支持 | 较慢,需要从git clone repository,然后从文件系统读取 | |
客户端支持 |
原生支持所有Java和.Net应用, 提供API支持其它语言应用, 同时也支持Spring annotation获取配置 |
支持Spring应用,提供annotation获取配置 | Apollo的适用范围更广一些 |
开源系统监控报警系统。负责收集,存储时间序列监控数据并展示。整体架构图如下:
开源的分布式监控解决方案。
提供查询,多维度可视化展示,报警等功能。