《架构整洁之道》之服务:宏观与微观

一、面向服务的架构

“只要使用了服务，就等于有了一套架构”这种思想。显然是错误的。
如前面所说，架构设计的任务就是找到高层策略与低层细节之间的架构边界，同时保证这些边界遵守依赖关系规则。所谓的服务本身只是一种比函数调用方式成本稍高的，分割应用程序行为的一种形式，与系统架构无关。

二、服务所带来的好处

1.解耦合的谬论

很多人认为将系统拆分服务的一个最重要的好处就是让每个服务之间实现强解耦。毕竟，每个服务都是以一个不同的进程来运行的，甚至运行在不同的处理器上。因此，服务之间通常不能访问彼此的变量。其外，服务之间的接口一定是充分定义的。

从一定程度上来说，这是对的。确实，服务之间的确在变量层面做到了彼此隔离。然而，它们之间还是可能会因为处理器内的共享资源，或者通过网络共享资源而彼此耦合的。另外，任何形式的共享数据行为都会导致强耦合。

2.独立开发部署的谬论

无数历史事实证明，大型系统一样可以采用单体模式，或者组件模式来构建，不一定非得服务化。因此服务化并不是构建大型系统的唯一选择。

解耦合谬论已经说明拆分服务并不意味着这些服务可以彼此独立开发、部署和运维。如果这些服务之间以数据形式或者行为形式相耦合，那么它们的开发、部署和运维也必须彼此协调来进行。

三、运送猫咪的难题

涉及横跨型变更问题，它是所有的软件系统都要面对的问题，无论是服务化还是非服务化。

四、对象化是救星

通过对SOLID设计原则的仔细考虑，我们应该一开始就设计出一系列多态化的类，以应对将来新功能的扩展需要。

五、基于组件的服务

服务按照SOLID原则来设计，按照组件结构来部署，这样就可以做到在添加/删除组件时不影响服务中的其他组件。

每个服务都有自己内部的组件结构，允许以衍生类的方式为其添加新功能。

六、横跨型变更

系统的架构边界事实上并不落在服务之间，而是穿透所有服务，在服务内部以组件的形式存在。

为了处理这个所有大型系统都会遇到的横跨型变更问题，我们必须在服务内部采用遵守依赖关系原则的组件设计方式。

服务内部的组件的设计必须符合依赖指向规则。

七、小结

• 服务化可能有助于提升系统的可扩展性和可研发性，但服务本身并不能代表整个系统的架构设计。
• 系统的架构是由系统内部的架构边界，以及边界之间的依赖关系所定义的，与系统中各组件之间的调用和通信方式无关。
• 一个服务可能是由一个独立组件，以系统架构边界的形式隔开。一个服务也可能由几个组件组成，其中的组件以架构边界的形式互相隔离。
• 极端情况下，客户端和服务端甚至可能会由于耦合得过于紧密而不具备系统架构意义上的隔离性。