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

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

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

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

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

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

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

所以,我们要做些改变⋯

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

要做些改变, 我们应将产品的架构区分出:

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

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

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

 

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

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

 

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

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

 别忘了,有的产品是只要有 “系统” 就够了。

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

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

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

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

 

相关阅读:

Cloud-Native 微服务的世界里, 你不能忽略的关键人物与解决方案

Cloud-Native 产品级敏捷 2.0: 协作,可视化, 轻量级的微服务设计 

Cloud-Native 微服务架构元素卡

Cloud-Native 微服务设计元素卡

Cloud-Native 微服务开发元素卡

 

 

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据