微服务架构 (二): 从既有的架构迁移到微服务的策略
来源:互联网 发布:软件导刊是核心吗 编辑:程序博客网 时间:2024/05/09 20:46
2016.8.9, 深圳, Ken Fang
在微服务的核心概念中, 最重要的核心概念便是: 边界上下文 (Bounded Context); 每一个微服务拥有各自的某一端到端业务场景 (功能)与数据 (数据库) 。
当将既有的架构迁移到微服务时, 常见的作法便是:
A. 只将既有架构的功能模块拆解成粒度较小的功能模块:
这样的作法, 其实, 实质上的意义是不大的。因为, 即使拆解成粒度较小的功能模块, 并且拆解后的各功能模块能互相的解藕, 但, 拆解后的各功能模块, 也许仍需共用数据库。所以, 当数据库即使只是修改某个数据表结构的某几个字段时, 也需同时修改多个功能模块。毫无疑问的, 这不仅会使产品开发的效率低落。拆解后的各功能模块, 在执行持续部署时, 将会有极大的概率会在某个阶段中断。同时, 也会为产品的架构引入新的风险, 甚至是致命的伤害。
B. 将既有架构的功能模块拆解成粒度较小的功能模块的同时, 也将既有数据库拆解; 使拆解后的各功能模块, 在拆解后, 便可拥有各自的数据库:
这样的作法, 所会带来的最大的问题是: 日后, 不论是发现拆解后的各功能模块, 粒度是过小或过大, 而需合并或再拆解功能模块时, 都将会有极大的概率, 会花费相当大的工作量在数据库的迁移上。
在将既有的架构迁移到微服务时, 架构师必需要考虑下列两个因素:
1. 我们其实是没法在一开始的时候、一步到位, 就能设计出正确、适当的微服务粒度的; 正确、适当的微服务粒度, 绝对是要经由不断的演进与学习而获得的。
2. 数据库的迁移风险极大; 一定要谋定而后动。
所以, 从既有的架构迁移到微服务的策略是:
I. 先以产品架构的性能、可靠性与安全性为首要的考量; 先拆解出粒度大的功能模块。
II. 再考量持续部署的独立性与对业务应变的能力, 而将必要的功能模块再拆解成粒度较小的功能模块。
III. 确定了所拆解的功能模块是正确、适当的微服务粒度后; 同时兼顾了性能、可靠性、安全性、持续部署的独立性与对业务应变的能力; 再进行数据库的拆解与迁移; 使各功能模块 (微服务) 真正拥有各自的数据库。最终, 使各功能模块 (微服务) 真正拥有正确、适当的边界上下文 (Bounded Context) 。
架构师应一直铭记在心:
微服务正确、适当的边界上下文 (Bounded Context), 绝对是要经由不断的演进与学习而获得的; 没有标准答案, 没有一步到位的。
- 微服务架构 (二): 从既有的架构迁移到微服务的策略
- 微服务架构设计(一):核心概念&从既有的架构迁移到微服务的策略
- 微服务实践(七):从单体式架构迁移到微服务架构
- 微服务实践(七):从单体式架构迁移到微服务架构
- 微服务实践(七):从单体式架构迁移到微服务架构
- 微服务实践(七):从单体式架构迁移到微服务架构
- 微服务实践(七):从单体式架构迁移到微服务架构
- 微服务实践:从单体式架构迁移到微服务架构
- 微服务实践(七):从单体式架构迁移到微服务架构
- 微服务实践(七):从单体式架构迁移到微服务架构
- 从单体架构迁移到微服务,8个关键的思考、实践和经验
- 从单体架构迁移到微服务,8个关键的思考、实践和经验
- 从单体架构迁移到微服务,8个关键的思考、实践和经验
- 【转载】从单体架构迁移到微服务,8个关键的思考、实践和经验
- 从0开始的微服务架构:(二)如何快速体验微服务架构?
- 微服务到单体架构的演变
- 微服务架构的学习
- 企业的微服务架构
- OpenCV的安装配置详解
- 最新Myeclispe 8.6注册码到2019年
- kernel 内存 I/O
- HDU 1051 Wooden Sticks 经典贪心
- android app 使用 eclipse 更换图标
- 微服务架构 (二): 从既有的架构迁移到微服务的策略
- JavaScript学习总结(九)——Javascript面向(基于)对象编程
- UVALive2701 UVA1189 POJ1426 ZOJ1530 Find The Multiple
- 给ScrollView添加一个横向的进度条
- POJ 2002 Squares hash
- hdu 5819 Joint Stacks
- 九度OJ 全排列
- 代码实现Linux ls命令
- 高仿拉手网-客户端+服务器完整教程