服务粒度大小多少合适

[DraperHXY]

SOA
Service-Oriented Architecture 面向服务的架构，将应用程序的不同功能单元(服务)进行拆分，并通过服务之间定义良好的接口和契约联系起来。

“服务”并不仅仅是一个按照标准暴露出 API 的对象，也不是面向对象编程的“放大版”。确实，如同面向对象给过程式编程带来了另一层次的抽象和思维，面向服务也给面向对象编程带来了另一层次的抽象和思维。

确实，面向服务的运动根本不是关于技术的！它是一个面向业务的运动，里头的抽象正是关于企业如何看待自身组织中变化不息的方方面面，以及如何用松耦合的方式将它们组织起来，从而造就出平缓而可预测的成本变动。这就是说我们要重新思考我们看待 IT 能力的方式，而不是简单地以同样的方式暴露出同样的资源，而仅仅是采用了新的接口或者中间件。

一般我们开发程序都避免不了自顶向下和自底向上的两种开发方式（或者两种都有）

从业务过程或者业务模型开始着手，然后将之递归分解成子过程或者子模型，直到达到某些条件，再继续分解就会违反这些条件位置。或者架构师从系统开始着手，从已有的 API 和访问点中暴露出服务的接口，以这些接口为基础创建出新的服务和契约，然后将它们组合起来，直到满足业务过程中的需求

适当的面向服务分析和设计方式应该从以下五个关键方面分别考虑粒度和原子性的问题：服务的可复用性、效率、事务性、可消费性（Consumability）和可见性。一开始从复用的角度看应该成为复合服务的，实际上可能出于事务性的考虑而应该成为原子服务。类似地，出于可见性和安全审查的考虑似乎应该成为细粒度服务的，可能因为效率的关系而应该改用粗粒度。这份服务粒度表格仅仅是一位高效的企业架构师腰带上挂着的又一把工具。

所以决定粒度大小的并不是一成不变的，一个粗粒度的服务在特定的环境下非常适合，并不意味在其他环境也是最好的。服务是跟着他们的应用程序一起演变的。