1.4 解耦与服务化

对解耦与服务化的关系进行深入思考，尝试理解其本质，明确什么是目的，什么是手段，有助于在做决策时分清主次。

解耦和服务化是什么关系？解耦是为了使架构变得灵活（比如灵活部署、灵活扩展、灵活调用），反之则“牵一发而动全身”。服务化不是解耦的手段，但解耦会为服务化打下坚实的基础。

微服务是由松耦合的、有相应语境的元素构成的一种面向服务的架构，松耦合意味着可以独立更新这些服务。更新其中一个服务并不会改变其他的服务。

企业应用架构向“微”服务演化时，如果以解耦为基础考虑服务化，就会水到渠成。“微”不是“比小还小”，而应该理解为“单一职责”。在遵循“单一职责”原则的基础上，解耦将变得容易一些。

下面借此机会探讨一个问题，进而给出一个不严格的“单一职责”的度量方法。在一般情况下，对于特定的语言环境，比如 Java 和 C#，代码行数较少时通常很难实现多个业务功能这个说法是否是对的呢？如果答案是肯定的，那么可以尝试用子程序（函数、过程、方法）的代码行数对软件工程师遵循“单一职责”原则的程度进行度量。

程序设计风格较好时才能获得高可读性、高质量、高性能。一个子程序的代码行数最好不要超过某个数值[9]。对于不同的编程语言，建议对开发小组的子程序代码行数进行统计，经过一段时间的积累得出合适的经验值。一般，这个代码行数的经验值是和小组的生产能力相关的。

不是所有的系统都适合进行服务化，即使不走服务化道路，降低耦合度也是好的。