许多人谈到 "微服务" 又是在纠结一个二十多年前的老问题; “粒度”; 什么是微服务划分的 "粒度"?
二十多年来, 许多人都在以一个 "标准答案"；粒度; 在做软件开发。很遗憾的是，当你一直以所谓的 “标准答案” 在做软件开发时, 你却永远是在用所谓的 "错误答案" 在做软件开发。
如何识别可自适应变化的 “微服务”，重点不在争论什么是 “原子” ? 什么不是 “原子”? 真正的重点在于要有方法论、实践从下列的两个面向去思考；深度的去思考; 而不是只拿表面的定义硬套……
① 假如，你已决定用 Docker 去承载你的微服务，那你就必需深刻的去理解 Docker 在运行上的极限在那儿? Docker 的坑在那儿? 这些信息 （知识）都将成为你在设计微服务架构时，必要的输入。
② 根据外部使用者的视角，划分出 “核心业务” 的 “Bounded Context”。根据 “核心业务” 的 Bounded Context 与由 ① 项所获得的架构约束，识别出 “核心业务微服务”。
在每个 PI ，根据核心业务微服务在运维与外部业务上所产生的变化， 持续的 “演进” 出更多的微服务。
软件开发永远都是一个 “演进 （学习）” 的过程。软件的开发，永远没有一个标准答案……
所以，软件开发即使是在微服务的时代，也一定是要用不断 “演进” 的方式， 深度的去思考， 如何构建一微服务的架构……
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/featuresoft/article/details/47210409
