0
0
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 微服务是为了解决单体 (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: 协作,可视化, 轻量级的微服务设计
