微服务的边界 (粒度) 是 "决策", 而不是个 "标准答案"
2016-07-09 09:41
197 查看
微服务的边界 (粒度) 是 "决策",而不是个 "标准答案"。
许多人面对微服务时,往往都会纠结着一个问题:微服务太小?太大?
其实,会纠结在这个问题上,最根本的原因便是误解了微服务粒度划分这件事的本质;微服务划分本身是 "架构设计"。也就是说微服务划分本身绝不是一个只讲"太大"或
"太小"标准答案的 "是非题"。而是需综合考量以下的因素,所作出的一个 "架构决策":
1. 市场业务的扩展性
2. 与已有架构间的冲突
3. 开发团队在开发上所可能面临的风险
4. 测试人员测试执行的效率
所以,请不要再简单粗暴的便脱口而出:你的微服务划得太细、太小...
而是应该将各微服务划分的方式,深度思考,周全的考量各方面的因素下,所作出的一个 ”最适合” 的架构决策,而不是一个人芸亦芸的 ”标准答案”。
许多人面对微服务时,往往都会纠结着一个问题:微服务太小?太大?
其实,会纠结在这个问题上,最根本的原因便是误解了微服务粒度划分这件事的本质;微服务划分本身是 "架构设计"。也就是说微服务划分本身绝不是一个只讲"太大"或
"太小"标准答案的 "是非题"。而是需综合考量以下的因素,所作出的一个 "架构决策":
1. 市场业务的扩展性
2. 与已有架构间的冲突
3. 开发团队在开发上所可能面临的风险
4. 测试人员测试执行的效率
所以,请不要再简单粗暴的便脱口而出:你的微服务划得太细、太小...
而是应该将各微服务划分的方式,深度思考,周全的考量各方面的因素下,所作出的一个 ”最适合” 的架构决策,而不是一个人芸亦芸的 ”标准答案”。
相关文章推荐
- nginx高并发优化——轻松应对1万并发
- 深入浅析JavaScript中的Function类型
- 版本更新 但是不能判断版本
- 牛人经验1(逻辑工程师必须寻求转型)
- ALE&IDoc& EDI(8)--Serialization
- php同名方法
- 论Android应用进程长存的可行性
- ALE&IDoc& EDI(7)--IDoc Extension
- ThreadLocal和线程同步机制的比较
- ALE&IDoc& EDI(6)--Filter & Conversion
- ALE&IDoc& EDI(5)--Inbound Function
- C++类和类的定义
- gvim配置--带YCM及Vundle的
- Launcher 3 源码分析笔记
- Apache禁止目录的自动目录列表(安全性)
- java servlet 搭建简易的服务器
- ALE&IDoc& EDI(4)--change point02
- HDU-1847-Good Luck in CET-4 Everybody!【sg定理】【博弈】
- ALE&IDoc& EDI(3)--change point01
- Longest Common Prefix