分布式服务一篇概览

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

一、关于 12-factor 问题

在开发分布式服务时，我们通常会考虑如 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、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的适用范围更广一些