在进入 Cloud-Native 微服务的世界前, 我们必需要真正了解的一些事

我们总是从 Cloud-Native 微服务的文章中、演讲中, 看到、听到关于单体 (Monolithic) 的系统是如何的不易维护、不易快速的独立发布。Cloud-Native 微服务是如何的容易扩展、快速的独立发布、容易维护等等。

然而, 我想, 我们应从产品开发的视角, 认真且客观的看待 Cloud-Native 微服务与单体 (Monolithic) 的系统; 以避免我们从单体 (Monolithic) 系统的地狱走向 Cloud-Native 微服务的地狱。

• Cloud-Native 微服务会不会取代单体 (Monolithic) 的系统?
  • 当然不会。
  • 而且是永远的不会。
• 单体 (Monolithic) 的系统目前的问题，在 Cloud-Native 微服务会不会发生？
  • 当然会。
  • 太多的团队，转型到 Cloud-Native 微服务后，同时深陷单体 (Monolithic) 系统的地狱与 Cloud-Native 微服务地狱中。
• Cloud-Native 微服务是为了解决单体上的问题？
  • 不能说不是，但当你这么想时，你就会有很大的概率做错事，而同时深陷 Cloud-Native 微服务地狱、单体 (Monolithic) 系统地狱中。

Cloud-Native 微服务最重要的思路是告诉我们：

软件可以不再只是 “系统”, 而是可以是 “服务”。

系统可以保证企业内的运作正常。

但，假如只是用系统的思维去构建直接为用户提供服务的系统，有时候是没问题的，但有的时候是, 版本的计划、开发，赶不上变化，变化赶不上ㄧ通电话的。

所以，我们要做些改变⋯

要做些改变, 并不是代表著我们要按着课本上的定义去做产品；去定义什么是单体 (Monolithic) 系统？什么是 Cloud-Native 微服务？

要做些改变, 我们应将架构区分出：

• “不易变”、甚至是 “不可变”
• “易变”、“常变”

根据架构上的 “变化” 的质量属性，将产品分成:

• 那部分是 “系统”
• 那部分又应该是 “服务”

图一

如图一所示, 产品团队先将产品识别出:

• 核心 (Core) 的业务领域
• 通用 (Generic) 类型的子业务领域
• 支撑 (Support) 类型的子业务领域

图二

如图二所示, 产品团队与领域的业务专家, 再将各业务领域; 核心 (Core) 的业务领域、通用 (Generic) 类型的子业务领域、支撑 (Support) 类型的子业务领域; 中的 “不易变” 甚至是 “不可变” 与 “易变”、“常变” 的业务场景给区分出来。

• “不易变” 甚至是 “不可变” 的业务场景, 将会构成产品的 “系统”
• 易变”、“常变” 的业务场景, 将会构成产品的 “服务”

别忘了，有相当多的产品只要有 “系统” 就够了。

会不会有产品只有服务，微服务的实现？有的。但，相当、相当、相当的不建议这样的产品架构。

所以，Cloud-Native 微服务除了需关注团队的成员是否具备 Cloud-Native 微服务的关键技术外，更难的一点是:

• 要花很多的时间识别 “系统”、 “服务”

然后，才能明白什么时候应该或不应该引入 Cloud-Native 微服务。