diff --git a/learning/k8s-practice/ocp/eureka-server.md b/learning/k8s-practice/ocp/eureka-server.md new file mode 100644 index 0000000..c35c82b --- /dev/null +++ b/learning/k8s-practice/ocp/eureka-server.md @@ -0,0 +1,24 @@ +--- +vssueId: 84 +layout: LearningLayout +description: Kubernetes教程_使用Kuboard在Kubernetes上部署Spring_Cloud微服务平台OCP_open_capacity_platform微服务能力开放平台_部署eureka-server +--- + +# 在K8S上部署eureka-server + +本文假设您已经完成了 [在Kubernetes上部署SpringCloud-OCP](/learning/k8s-practice/ocp/) 教程的前序步骤： +* [准备OCP的构建环境和部署环境](/learning/k8s-practice/ocp/prepare.html) +* [构建docker镜像并推送到仓库](/learning/k8s-practice/ocp/build.html) + > 也可以使用 ocpsample 已经推送上去的 docker 镜像 + +## 理解eureka-server + +本章节参考 eureka-server 的 [代码仓库](https://gitee.com/owenwangwen/open-capacity-platform/tree/2.0.1/register-center/eureka-server)，并着重从容器化部署的角度来理解 Spring Cloud eureka-server 以及 OCP 中 eureka-server 的配置文件。 + +...待续...2019年9月25日 23:05 + +## 确定部署方案 + +## 部署eureka-server + +## 查看部署结果 diff --git a/learning/k8s-practice/ocp/index.md b/learning/k8s-practice/ocp/index.md index a8124b7..39ae900 100644 --- a/learning/k8s-practice/ocp/index.md +++ b/learning/k8s-practice/ocp/index.md @@ -18,12 +18,13 @@ Kuboard 网站将陆续 **连载** 如何使用 Kuboard 在 Kubernetes 上部署 该系列连载文章的目录如下： * [准备OCP的构建环境和部署环境](./prepare.html) -* [构建OCP并推送到 docker registry] -* [部署 eureka-server] -* [部署 auth-server] -* [部署 user-center] -* [部署 api-gateway] -* [部署 back-center] +* [构建docker镜像并推送到仓库](./build.html) +* [部署顺序](./sequence.html) +* [在K8S上部署eureka-server](eureka-server.html) +* [在K8S上部署auth-server] +* [在K8S上部署user-center] +* [在K8S上部署api-gateway] +* [在K8S上部署back-center] * [导出部署配置] * [在新的名称空间导入部署配置] diff --git a/learning/k8s-practice/ocp/sequence.assets/image-20190925213741256.png b/learning/k8s-practice/ocp/sequence.assets/image-20190925213741256.png new file mode 100644 index 0000000..c69e62c Binary files /dev/null and b/learning/k8s-practice/ocp/sequence.assets/image-20190925213741256.png differ diff --git a/learning/k8s-practice/ocp/sequence.md b/learning/k8s-practice/ocp/sequence.md new file mode 100644 index 0000000..06e52c3 --- /dev/null +++ b/learning/k8s-practice/ocp/sequence.md @@ -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-server、user-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 副本数，但是开发者仍然期望快速看到正常运行的结果。 +:::