微服务架构 : 从既有的架构迁移到微服务的策略 ( 二 )

全世界没有任何的一个系统, 可一步到位的, 就达到微服务核心概念中, 所谈及的架构上的要求。 我们真正应该要做的事是: 找出将既有架构迁移到微服务的策略、方法、实践与技术。 本篇文章便是先来探讨下: 将既有架构迁移到微服务的策略。

前言

在微服务的核心概念中, 最重要的核心概念便是:

边界上下文 (Bounded Context); 每一个微服务拥有各自的某一端到端业务场景 (功能)与数据 (数据库) 。

微服务基于 "边界上下文 (Bounded Context)" 的核心概念, 最主要的目的便是: 使得每一个微服务均可拥有各自的资源, 而可独立的发布、部署、运作, 进而可使产品的架构, 可更容易的随著外部的使用者、业务量而扩展 。

然而, 很明显的, 全世界没有任何的一个系统, 可一步到位的, 就达到微服务核心概念中, 所谈及的架构上的要求。

我们真正应该要做的事是: 找出将既有架构迁移到微服务的策略、方法、实践与技术。

本篇文章便是先来探讨下: 将既有架构迁移到微服务的策略。

本文

当将既有的架构迁移到微服务时, 常见的作法便是:

A. 只将既有架构的功能模块拆解成粒度较小的功能模块:

这样的作法, 其实, 实质上的意义是不大的。因为, 即使拆解成粒度较小的功能模块, 并且拆解后的各功能模块能互相的解藕, 但, 拆解后的各功能模块, 也许仍需共用数据库。所以, 当数据库即使只是修改某个数据表结构的某几个字段时, 也需同时修改多个功能模块。毫无疑问的, 这不仅会使产品开发的效率低落。拆解后的各功能模块, 在执行持续部署时, 将会有极大的概率会在某个阶段中断。同时, 也会为产品的架构引入新的风险, 甚至是致命的伤害。

B. 将既有架构的功能模块拆解成粒度较小的功能模块的 "同时", 也将既有数据库拆解; 使拆解后的各功能模块, 在拆解后, 便可拥有各自的数据库:

这样的作法, 所会带来的最大的问题是: 日后, 不论是发现拆解后的各功能模块, 粒度是过小或过大, 而需合并或再拆解功能模块时, 都将会有极大的概率, 会花费相当大的工作量在数据库的迁移上。

在将既有的架构迁移到微服务时, 架构师必需要考虑下列两个因素:

1. 我们其实是没法在一开始的时候、一步到位, 就能设计出正确、适当的微服务粒度的; 正确、适当的微服务粒度, 绝对是要经由不断的演进与学习而获得的。

2. 数据库的迁移风险极大; 一定要谋定而后动。

从既有的架构迁移到微服务的策略是：

I. 先以产品架构的性能、可靠性与安全性为首要的考量; 先拆解出粒度大的功能模块。

II. 再考量持续部署的独立性与对业务应变的能力, 而将必要的功能模块再拆解成粒度较小的功能模块。

III. 确定了所拆解的功能模块是正确、适当的微服务粒度后; 同时兼顾了性能、可靠性、安全性、持续部署的独立性与对业务应变的能力; 再进行数据库的拆解与迁移; 使各功能模块 (微服务) 真正拥有各自的数据库。最终, 使各功能模块 (微服务) 真正拥有正确、适当的边界上下文 (Bounded Context) 。

结论:

架构师应该一直铭记在心:

微服务正确、适当的边界上下文 (Bounded Context), 绝对是要经由不断的演进与学习而获得的; 没有标准答案, 没有一步到位的。

图一: 微服务经由容器; 如: Docker; 拥有各自的资源。各微服务便可独立的发布、部署到各个的节点上, 并在各节点上能独立的运行

图二: 微服务的边界上下文 (Bounded Context) 经由单一的容器; 如: Docker; 构建完成。也就是说, 单一的容器内, 包含著微服务所需的所有资源, 如: 操作系统、应用伺服器、数据库、应用系统

图三: 为使微服务的数据库的架构, 有更好的扩展性、可靠性, 而将微服务的数据库独立在另一个容器里; 如: Docker