最近经常与人探讨服务颗粒度的问题，大家总是觉得这个问题难以捉摸，各种各样的方法论、模型让人困惑。那么从S++的方法来看，服务的颗粒度是怎么确定的呢？
让我们先从服务治理开始，从几个典型的例子来看如何梳理服务。
服务治理的目标是建立理想的业务模型，其方法就是通过理解业务、划分业务、定义业务最终完成业务模型的建立。在治理之前，你可以对业务有所了解，也可以完全不懂，但治理之后你一定是个业务专家。
S++提出服务的抽象过程是业务与技术分离的过程，其推论是抽象后的服务具有时空不变性。所以，我们对于存量系统的服务治理就依赖于S++的方法，其检验的手段就是是否能够得到具有时空不变性的服务。
具体来说，S++认为服务的核心不变要素是行为，可变化的是参与者、技术和展现形式，对于存量系统来说可以应用减法，剥离掉非核心行为部分，剩下的就是具有时空不变性的服务。
下面我们以银行的几个核心交易为例来说明如何通过S++的方法来建模。下图是银行的现金交易接口和转账交易接口（简化后），后面将会看到这两个接口如何被抽象为服务。
从服务的行为来看，我们首先可以剥离的是：
查询行为是业务状态的展现，非业务本身。
查询类行为的特点是输出参数丰富。如下例：
校验行为是对业务的技术保障，非业务本身。
校验类一般输出参数比较简单，并常带有布尔返回值或字符串型验证码。
管理行为是对业务参与者的维护，非业务本身。
管理类通常带有明确的数据库表增删改特征，如下例：
接下来我们对剩下的业务接口进行分析，对接口进行业务与技术分离，按照如下方式：
分离纯技术要素
技术要素通常和系统的实现方式有关，和业务本身是无关的，一般包括但不限于：各种序列号、和操作员相关的内容、系统及渠道相关信息、各种验证码、会话及token信息、签名及加密信息等等。例如：
分离业务参与者
参与者是参与业务行为的人、组织和物，一般来说是实体。包括但不限于：各种自然人和法人、组织机构、产品、账户等。
分离原子行为
将剩下的业务行为分离成一个或多个不可分割的原子行为。
这些原子的业务行为就是我们的治理方法得到的具有时空不变性的服务，很显然有的业务行为从有银行开始就存在了，而且在可预见的未来这些行为不会发生任何本质上的变化。
经过服务的业务与技术分离，我们得到时空不变的服务，同时也得到很多可以变化的要素。定义服务的过程就是将参与者与一个或多个业务原子行为进行组合，形成组合行为。
1、现金存款是金融账户发生现金交易的收费服务行为
2、信用卡还款是金融账户发生的、可能有银联参与的、信用卡的现金交易
3、现金转账是金融账户与交易对手金融账户发生现金交易的收费服务行为
4、委托贷款是由委托人（委托人可以是政府部门、企事业单位及个人等）提供合法来源的资金转入委托银行一般委存账户，委托银行根据委托人确定的贷款对象、用途、金额、期限、利率等代为发放、监督使用并协助收回的贷款业务，其中银行收取一定的手续费，将款项从委托人账户转入借款人账户，并起息。
上述定义的服务中，所有下划线的红字部分就是参与者和业务原子服务。
我们通过S++的方法论，对存量的业务系统接口进行分析抽象，最后定义出服务模型，这个过程中我们就可以从一个完全不懂业务的人员变成一个业务专家。进一步的，我们可以基于已经得到的原始服务模型进行再抽象，通过S++服务多态建模的方法得到更加抽象的形式化服务定义。
抛开服务的建模过程去谈服务的颗粒度是没有价值的，基本上每个人都可以说出服务具有某种颗粒度的原因。但是，通过S++服务建模过程，我们可以理性的认识到，服务的颗粒度是由客观的业务行为本身所决定的，这种客观性不会因为我们组织机构的变化、技术架构、业务架构、实现方式等等原因而变化。一定有某些业务行为是原子的不可分割的业务行为，所以服务必然存在最小颗粒度（也就是下限），但不存在上限。
我们经常谈论，微服务到底应该有多“微”？业界有大量的方法论，有的玄而又玄、有的简单务实，文章看到这里我相信大家也能知道S++对微服务颗粒度划分的方法了。
S++认为，微服务的最小颗粒度是具有时空不变性的不可拆分的原子服务。系统颗粒度是不是越小越好呢？答案是肯定的，能达到最小的颗粒度，意味着我们在业务上的分工合作达到了最高的程度，换句话说我们在IT行业实现了大工业生产的能力，对比大工业生产我们可以看到现代工业已经将整机的生产分解成无数的标准件生产与组装的过程，所谓标准件就是类似于我们说的具有时空不变性的不可拆分的原子服务。
因此，我们不要用什么辩证的方法来看待颗粒度问题，也不要用所谓务实的方法来看待颗粒度问题，唯一影响我们使用最小颗粒度的障碍就是技术能力。类比大工业生产，如果不是工业革命、技术爆炸，如此细致的分工根本无法实现，只有技术达到了才会有大工业、才会有随之而来的管理方法。
那么，阻碍微服务原子化的技术都有哪些呢？
我们沉醉于面向对象的方法论已经几十年了，从SOA理念出现到现在，没有任何一个SOA系统不是基于面向对象的方法来实现的。理论与实现方法论之间的鸿沟，阻碍了业界对面向服务的正确理解，不能能够放弃对象这个载体就不可能实现真正的面向服务的系统。微服务也不例外，再多的新概念也无法改变人们对服务本质的认知。
传统的SOA到目前为止，业界都无法达统一的认识。ESB被很多厂商庸俗化为纯粹的接口路由，不关注服务治理、没有服务抽象只有接口的罗列，服务之间相互依赖耦合，服务组合由前端定义等等。
各种“务实”的实施方法论阻碍了SOA进一步的发展完善，甚至到现在连服务的本征化（服务的自包含）都无法做到。连SOA的组合都实施不了，还在妄谈微服务化，微服务化带来的大量组合如何实现？
了解S++理论的应该知道，服务组合的稳定性和效率是微服务化的技术关键。稳定性指的不是系统的可靠性，是由服务时空不变性以及S++技术特点决定的代码稳定性，这种稳定性决定了系统的可维护性，决定了系统可以持续、以增量的方式演化和进步，决定了不会因为新的业务变化而修改已有的业务流程。做不到这一点，微服务化就是一个大量堆积人力的工作，没钱就玩不起。
服务组合的效率，不是简单通过缩短交易路径，不是简单的通过改善通讯方法就能解决的。通讯效率在海量的微服务组合中对效率的影响只是九牛一毛，真正的影响是一个单一的事务被拆分成多个跨异构系统的事务的组合。解决不了这个效率问题，微服务就无法实现真正的原子化，只能通过传统SOA的方法（也就是多个原子服务在一个本征业务服务中直接实现，不通过组合方式）来实现，这样的微服务与传统SOA根本还是换了一个说法而已。
原文地址：http://11534574.blog.51cto.com/11524574/1877478
