我们常常听到关于在 SOA 部署中服务的粒度应该有多大的讨论。对于其他更传统的架构方式，粗粒度和细粒度的激烈争论已经持续了很多年，换言之，这并不是 SOA 独有的问题。这也是不存在普适方案的又一例证：有时候大小很重要！最近的一份报告又给这个激烈的争论火上浇油：
“服务”并不仅仅是一个按照标准暴露出 API 的对象，也不是面向对象编程的“放大版”。确实，如同面向对象给过程式编程带来了另一层次的抽象和思维，面向服务也给面向对象编程带来了另一层次的抽象和思维。
报告里继续展开论点：
确实，面向服务的运动根本不是关于技术的！它是一个面向业务的运动，里头的抽象正是关于企业如何看待自身组织中变化不息的方方面面，以及如何用松耦合的方式将它们组织起来，从而造就出平缓而可预测的成本变动。这就是说我们要重新思考我们看待 IT 能力的方式，而不是简单地以同样的方式暴露出同样的资源，而仅仅是采用了新的接口或者中间件。
跟过去几年中围绕这个主题的其他讨论一样，这份报告强调了跟服务粒度相关的困难，报告中将细粒度的服务定义为“针对一个相对较小的功能单元，或者交换少量的数据”，而粗粒度的服务则是在单个交互中抽象了大量功能的服务。其他人已经讨论过决定服务的粒度为何是服务生命周期中的一个关键方面，因为它不但影响一组松耦合的服务之间的复合能力，还影响了单个服务的可复用性。
报告继续讨论了自顶向下和自底向上两种开发服务的方式（或多或少两种都是必需的）：
……从业务过程或者业务模型开始着手，然后将之递归地分解成子过程或子模型，直到达到某些条件，再继续分解就会违反这些条件为止。或者，架构师可以从已经实现的 IT 系统开始着手，从已有的 API 和访问点中暴露出服务的接口，以这些接口为基础创造出服务的契约，然后将它们组合起来，直到满足业务过程的需求。
无论你是在开发复合服务还是原子服务，都会对服务的粒度有所影响：
第一眼看起来似乎所有原子服务都是细粒度的，而复合服务是粗粒度的，但事实未必如此。由于粒度是对交互和业务适合程度的一种量度，而原子性是对过程分解的一种量度，因此很可能出现粗粒度的原子服务和细粒度的复合服务。
最后报告给出了一份粒度表格，里面列出了服务的粒度和原子性之间的取舍。对于过去几年中曾经做过服务开发的大多数人来说，最后的结论毫不意外：
……适当的面向服务分析和设计方式应该从以下五个关键方面分别考虑粒度和原子性的问题：服务的可复用性、效率、事务性、可消费性（Consumability）和可见性。一开始从复用的角度看应该成为复合服务的，实际上可能出于事务性的考虑而应该成为原子服务。类似地，出于可见性和安全审查的考虑似乎应该成为细粒度服务的，可能因为效率的关系而应该改用粗粒度。这份服务粒度表格仅仅是一位高效的企业架构师腰带上挂着的又一把工具。
那么，粒度大小重要吗？是的，而有时候更大并不意味着更好。而且，即使一个粗粒度的服务在特定的环境下非常适合，并不意味着它在别的环境下也是最好的。服务是跟使用它们的应用一起演变的。
查看英文原文： How Big Should A Service Be?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论