在进入 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 微服务。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区