用 Proxy 配合部署方式来兼容 semantic versioning 的版本管理，版本格式有主版本号、次版本号、修订号、版本号递增同时需要备注，规则如下：
主版本号：当做了不兼容的 API 修改时，需要递增主版本号。
次版本号：当做了向下兼容的功能性新增时，需要递增次版本号。修订号：当做了向下兼容的问题修正时，需要递增修订号。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
9.5 对微服务的支撑
融数数据 DevOps 体系主要解决的问题是有效地识别和管理元数据，以便高效、自动化、高质量地将系统动态组装并运行起来，该体系架构如图 9.10 所示。
下面结合图 10.10 对 DevOps 体系做几点说明。
抽象了部署的最小单元——包。
每个微服务都是由包及其配置组成的，前面提到，服务框架做了代码和配置分离，因此这里可以将包和包的配置分离，提供运维便利性。
逻辑环境包括了微服务、微服务配置及运行微服务所依赖的 Host 或者 Host Group。
版本化逻辑环境，方便回滚。
该体系中的服务组件=（可运行代码 + 配置）&（依赖 + 配置）&（基础设施 + 配置），如图 9.11 所示。
从部署的角度讲，无论包还是包的集合（往往是组成一个独立业务域的独立功能）都需要依靠版本才能进行整体部署，可以部署在不同的逻辑环境上，也可以部署在同一个逻辑环境上，如图 9.12 和图 9.13 所示。
9.6 DevOps 平台总体架构
DevOps 平台通过构建平台将代码编译成物理二进制包，再使用元数据对这个二进制物理包进行描述，形成逻辑包，且将部署、依赖和二进制包本身的元数据统一存储到元数据服务中，最终通过统一环境管理平台读取元数据，按需拉取相应的逻辑包对应的物理包，放置到目标环境的相应目录下。之后通过进程管理调用相应的服务启动相关微服务，在部署的过程中，由逻辑环境管理绑定 VIP 到微服务的 Proxy 上，将信息注册到 service inventory 服务上，这样 Proxy 和服务 Endpoint 等的运行时信息（例如 IP、端口、版本等）就可以被收集到 service inventory 服务上。在真正调用服务时通过内建的 Zipkin 可以收集服务调用链的情况，并同 inventory 服务的元数据信息进行匹配，便可以准确地知道服务调用的关系，从而达到真正的分布式治理；而客户端调用只需要知道服务所在的逻辑环境信息就可以自动完成服务寻址，这个服务地址就是 Proxy 绑定的 VIP 地址，从而简化客户端调用。DevOps平台要做的就是保证 Proxy 的健壮性，由于 Proxy 只是简单的反向代理，不存储服务状态，因此只需要做故障漂移就可以了，如图 9.14 所示。
