软件|如何实现微服务的规模部署与批量发布？( 二 ) |美好，一直在身

1）检查环境：检测系统环境是否正常，相关技术栈是否完备；
2）下载部署包：参考指定软件版本下载部署物料；
3）关闭服务监控：关闭服务监控，防止部署过程中产生大量报错信息，但部署监控必须开启；
4）服务下线：服务注册中心将该服务节点直接删除，或者调整该服务节点的路由权重为 0 来控制不再有新的请求进入该服务节点；
5）停止服务：发出进程关闭信息，通过“优雅停机”的方式在所有存量请求处理完毕之后，关闭服务进程；
6）部署服务：部署新服务的部署包；
7）启动服务：启动服务进程；
8）健康检测：检测服务是否正常启动，进程是否正常，并在服务注册中心中正常注册；
9）开启服务监控：服务启动成功并正常注册后，开启服务监控。
容器化部署模式
在容器编排领域， K8S（Kubernetes）已经成了事实上的王者。本节中，就以 K8S 为例，讨论如何进行 P2P 直连模式微服务的部署。
首先了解 K8S 的两个关键概念：Pod 和 Service 。

Pod：和常规的理解不一样， K8S 管理的基本单元不是容器，而是 Pod 。 Pod 是 K8S 中的最小管理单元， K8S 不直接管理容器，就算只有一个容器，也会给它分配一个 Pod ， Pod 里的容器数也可以为 0（其实不可能真正为 0 ，因为还有 K8S 自己创建的基础容器 Pause ，它负责网络及存储的管理）。
Service：可以通过给 Pod 打标签（Label）来对 Pod 进行分类和组织。一个 Pod 的若干个实例组成一个 Service ，可以认为 Service 就是对应一个 Pod 的副本集群，并通过 Service 来进行这些副本实例的负载均衡控制。一个 Service 由一个 IP 地址和一个 Label Selector 组成，副本控制器（Replication Controller）通过 Label Selector 来控制每个 Service 包含多少个 Pod 实例。简单地理解，可以把 Service 看成一个弹性组。

如果设定一个 Pod 的实例由基础容器 Pause 和一个业务容器组成，并且这个业务容器只运行微服务的某一个服务节点，就可以让 K8S 和微服务在“服务”这个概念上达成一致，如图 4.19 所示。

本文插图

图 4.19 微服务和 K8S 在架构上的映射及融合
如图 4.19 所示，微服务中的服务对应 K8S 中的 Service ，服务节点对应 Pod 中的业务容器。这样，只要将每个微服务打包成容器镜像，并在创建对应 Pod 资源的时候，将服务名称以标签的形式写入资源清单文件中，就可以利用 Label Selector 过滤出相关的服务 Pod ，并通过 K8S 进行上线、下线、扩容、缩容操作。
混合部署模式
与服务化类似，大部分企业的容器化之路也不是一蹴而就的。企业内部的 IT 环境会长期处于新旧混搭的状态，基础资源层除了 K8S 提供的容器服务，可能还存在 IaaS 云平台（公有云或私有云），甚至还存在传统的物理机。整个微服务集群混部在这些不同的环境中，新增加的 K8S 容器服务平台需要能与原有的资源平台共存，如图 4.20 所示。

本文插图

图 4.20 微服务集群的混部
以上架构会导致一个网络问题， Pod 的 IP 地址只在 K8S 容器集群里可见，无法和容器集群外的微服务交互，相当于 K8S 容器集群内、外形成了两个网络域。
为了解决这个问题，可以使用第三方开源的网络组件 Calico ，结合物理核心交换机做策略优化，基于 BGP 协议将容器集群的内、外两个网络连接在一起，使得 K8S 集群外的主机能访问到 Pod 的 IP 地址，网络架构如图 4.21 所示。