OCP-部署顺序

This commit is contained in:
huanqing.shao
2019-09-25 23:50:33 +08:00
parent 57bdecd3ab
commit d213d72dca
4 changed files with 100 additions and 6 deletions

View File

@ -0,0 +1,69 @@
---
vssueId: 85
layout: LearningLayout
description: Kubernetes教程_使用Kuboard在Kubernetes上部署Spring_Cloud微服务平台OCP_open_capacity_platform微服务能力开放平台_部署eureka-server
---
# 部署顺序
## 部署顺序及其原因
本教程将在 KUbernet是上部署 Spring Cloud - Open Capacity Platform 微服务架构的如下模块:
* 服务注册中心 eureka-server -- **【中间件层】**
* 用户中心 user-center -- **【微服务层】**
* 认证中心 auth-server -- **【微服务层】**
* 服务网关 api-gateway -- **【API网关层】**
* 后台中心 back-center -- **【展现层】**
他们之间的依赖关系如下图所示:
![image-20190925213741256](./sequence.assets/image-20190925213741256.png)
本教程将按照如下顺序部署这些微服务模块:
1. 服务注册中心 eureka-server
2. 用户中心 user-center
3. 认证中心 auth-server
4. 服务网关 api-gateway
5. 后台中心 back-center
在决定按照什么顺序部署这些微服务组件时,需要考虑的因素有:
* **依赖关系**
* 0 依赖(不依赖任何其他模块)的最先部署
* 按依赖链条顺序部署
* 上图的依赖顺序为eureka-server <-- (auth-server / user-center) <-- api-gateway <-- back-center
* 依赖链条末端的最后部署
* **分层关系**
* 一个模块可以依赖处于下一层的模块
* 一个模块可以依赖处于同一层的模块
* 尽量避免跨层依赖例如 back-center 直接依赖 auth-server
* 展现层API网关层微服务层持久层的组件都有可能依赖中间件层在本例中API网关层的 api-gateway 微服务层的 auth-serveruser-center 都依赖于中间件层的 eureka-server
* **解耦关系**
* 如果从服务注册/服务发现的角度来审视服务调用者 api-gateway服务提供者 auth-server/user-center服务注册中心 eureka-server 三者的关系
* 服务注册中心 eureka-server 必须先于服务调用者和服务提供者存在否则调用者和提供者都有可能启动失败
* 服务提供者先于服务调用者存在遵循了依赖关系
* 服务调用者可以先于服务提供者存在并正常启动此时如果服务提供者完成启动并向注册中心注册服务调用者后续才发现提供者的存在并进一步向服务提供者发送接口调用请求此时服务注册中心使得我们可以向一个已经运行多时api-server已存在的情况下添加新的微服务比方说 product-center
::: tip
按照解耦关系这几个微服务模块的部署顺序也可以调成为
1. 服务注册中心 eureka-server
2. 服务网关 api-gateway
3. 用户中心 user-center
4. 认证中心 auth-server
5. 后台中心 back-center
:::
## 服务编排工具的特点
### docker-compose
需要严格定义不同模块之间的依赖关系依赖链条前序的模块没有完成启动将不会尝试后续模块的启动
### Kubernetes
Kubernetes 不定义模块之间的依赖关系你把控制器Deployment/StatefulSet/DaemonSet 按任意顺序部署到 Kubernetes Kubernetes 就开始尝试为你维持期望的 Pod 副本数如果依赖模块不存在被依赖模块会启动失败是的但是没关系Kubernetes 会先等一下然后再尝试启动直到被依赖模块出现以后依赖模块正常启动为止请参考 [重启策略](/learning/k8s-intermediate/workload/pod-lifecycle.html#重启策略)
::: tip
在测试验证阶段我们仍然严格按照期望的顺序进行部署否则虽然 Kubernetes 会不知疲倦地尝试维持期望的 Pod 副本数但是开发者仍然期望快速看到正常运行的结果
:::