颗粒度问题的核心矛盾：SOA不关心颗粒度，微服务关心却没有通用标准

面向构件的设计理论上很完美，但操作上有一个绕不开的难题：到底 该把什么东西设计成一个构件？在SOA架构风格下，构件应该对应 “服务”，但”服务应该多大”这个颗粒度问题，从SOA到后来的微服务 都没能真正解决好。作者指出这个问题为什么重要：如果颗粒度划分 过细，构件之间的通信机制会被拖垮，最终形成一张混乱的网状通信， 让迭代升级变得异常复杂；更关键的是，纯粹从技术自由度出发去 拆分服务，这套逻辑技术人员还能接受，但根本无法传递给业务人员—— 业务人员会完全看不明白IT到底在做什么，这直接违背了业务架构 “促进业务与技术深度融合”的首要责任。作者接着比较了现有主流 架构方式在颗粒度问题上的实际表现：SOA本质上并不真正关心颗粒度， 一个遗留系统可以被直接封装成一个服务，一个很小的功能也可以被 单独服务化，两者在SOA里的地位是一样的——SOA更像是一个集成 架构，负责统一内部通信方式、解决异构系统集成，颗粒度这个难题 往往被直接压给企业总线去扛；微服务倒是很关心颗粒度问题，但 很难判断服务的”合适大小”——服务太大内聚性不好，太小则通信 过于复杂、效率下降，目前微服务领域也只有一些参考性原则，并 没有形成通用标准。这个对比说明，颗粒度不是某个具体架构风格 “没做好”的偶然缺陷，而是面向构件设计这条路本身长期存在的 一个未解难题。