近几年来，我一直从事着和面向服务相关的底层软件研发工作，逐渐的形成了一些自己的看法，其中我觉得比较重要的看法就是服务需要一个更准确细致的定义。简单来说，服务的本质就是行为（业务活动）的抽象。
为了更好的阐述新服务的概念，并方便与传统的SOA中定义的服务有所区别，我将新的服务命名为S++（Service Plus Plus），接下来我会通过对比S++与SOA和微服务的区别、S++与面向对象的差异来说明这个新的概念。
为什么要重新定义服务呢？其中一个原因就是服务从不同的角度看其实是不一样的，我们举个例子。
服务到底是什么样子的？这个问题很有意思，有点儿横看成岭侧成峰的感觉。是的，传统的无论是SOA定义的服务还是微服务定义的服务，一个服务只会有一个最全面的定义，这样的定义太复杂了，最后只有技术人员能看得懂。那么如何让业务人员也能看得懂呢？一般来说就是文档在起作用，但是文档有个问题就是只能看没法改，任何对业务服务的修改最终必须还要通过技术人员。
所以，传统的服务定义是业务和技术混杂在一起的，能不能有一种方法让所有人看到的服务都是一个样子而且都能看懂都能修改呢？这就是S++要做的事情，S++通过服务的业务与技术分离彻底将传统服务中和业务无关的技术成分剥离出去，放到服务的外延中去，让服务内涵成为纯粹的业务描述。
另外一个原因是，从服务流程梳理人员的角度看，传统的服务抽象度是不够的。举个例子，一个业务流程需要完成先在帳户上扣款然后再缴费这样的业务。对于流程编排人员来说，缴费这个服务可不是一个服务，首先有很多种现存的缴费种类（电话费、水费、煤气费….），而且未来还有很多种可能的种类。
我们不可能在一开始就包含所有的业务可能，但是我们又必须在一开始就包含所有的业务可能，否则我就会陷入不停的修改之中。因此，为解决这个矛盾我们需要一个更加抽象的服务定义，在流程中只需要调用抽象的业务服务，这就是S++需要解决的另一个主要问题。
在概念和定义上的差异
对于SOA，推进结构化信息标准组织（OASIS）和开放团体（Open Group）均给出了正式定义。OASIS将SOA定义为：
Open Group将SOA定义为：
业界基本的认知是，SOA是一种架构模式，是一种面向服务的思维方式。 对于服务的定义，Open Group认为服务是一种可重复的业务活动的逻辑上的描述，是一种自包含的、可组合的“黑盒子”。
微服务在服务定义上，与传统的SOA差别不大，在实现上强调应用的颗粒度足够小，当然小到什么程度也是争论的一个话题。在我看来，微服务“微”的并不是服务，其实微的是应用（后面我们会谈到，服务的颗粒度是和需求相关的，是不能随意变大变小的）。
S++认为，服务是一种对行为（业务活动）的抽象，这种抽象不仅仅是简单的屏蔽掉业务活动内部的细节，同时需要对相同类型的活动进行归纳形成统一的行为模型。所以S++包含两个层面的抽象：
1、从具体的业务活动出发，屏蔽业务活动的内部细节，将业务活动中所有与业务表达无关的技术内容剔除掉，从而形成一个纯粹的、与技术实现无关的、与业务细节和流程无关的、自包含的业务描述。我将这个过程称为业务与技术分离的过程。
2、从多个经业务与技术分离后的业务描述进行归纳，剔除非要素的业务描述，抽象合并同类的业务要素，从而形成更加形式化的抽象业务模型。这个过程称之为服务多态建模的过程。
实现方法差异
从实现上看，SOA允许各种不同的技术来表达SOA的架构理念包括WebServices、REST、DCOM、CORBA、JAVA RMI等等，其中业界比较流行的方法是WebServices方法。从理论上讲，架构的实现是与技术无关的，但是从实践上看并不是所有技术都能很好的实现某种架构的。
以WebServices为例，WebServices事实上属于传统的面向对象技术的一种衍生技术，即所谓面向接口的技术（类似的比如Java的Interface概念）。这会导致在实现过程中系统间依然是以对象为载体的交互模式，这就必然带来系统间的耦合。
从S++的定义看，由于引入了更高层次的抽象，完全采用传统的面向对象的技术来实现势必就行不通了。所以，必须有专用的S++容器承载S++服务以及处理S++的多态模型转换。当然，S++同时必然也兼容了传统的面向对象的技术，对于用传统技术构造的业务系统而言，S++化的过程是透明的无需做针对性的改造。
微服务更强调实现的轻量化，架构上采用点对点去中心化，在协议上尽量选择更轻量的协议，以便提高系统的性能，这与微服务架构的颗粒度有很大关系。在S++看来，任何协议都属于服务的外延部分，并不影响服务内涵的定义，就像我们从不同角色去看骑大象一样，对于不同的服务访问者和实现者来说，采用不同的协议和技术手段都是可能的。从这个角度看，SOA和微服务都是S++的一种实例或实现。
从架构上看，S++认为只要有需求，那么中心点是必然也必须存在的，性能问题不能成为借口。架构是为应用服务的，不同的应用适用不同的架构，比如服务组合必然会引入一个局部的中心节点，不能为了技术需要而牺牲应用的需求和架构的平衡性。这一点上，S++与传统的SOA和微服务都是有差异的，S++推荐的架构是介于SOA与微服务之间的多中心架构，根据业务需求划分不同的区域，在每一个区域中根据自己应用的特点选择不同的技术。
耦合性差异
传统的SOA虽然在服务的定义上与面向对象有很大差异，但并没有自己专门的实现方法，所以真正去实现SOA架构的时候依然使用的是面向对象的方法。现存的SOA实现方法，大抵是基于远程对象来进行服务的封装和调用的。
我们知道，要访问远程对象的客户端必须在编译时刻引入远程对象的stub类，而且由于面向对象中多态的实现必须由调用者来决定，所以服务访问者必须包含所有可能的stub类才能够在运行时刻实现多态。一旦服务提供者增加了一种新的派生对象，服务消费者必须在编译时刻引入这个新类的stub才能访问，这就导致了服务提供者与服务消费者之间的紧耦合。举个例子：
一个消费者需要调用 Person.hello()服务，Person是个抽象的类，服务提供者实现了Man和Women两个具体类。对于服务消费者来说，多态的实现必须在消费者端进行确定，必须在程序中明确指明Person p = new Man();或者Person p = new Women();如果服务提供者增加了OldPerson这样一个新的对象时，服务消费者是无法访问的，因为此时的运行时刻不包含OldPerson的stub类。
反之，对于S++来说，服务的定义是……
由于附件上传及字数限制，部分图片、内容无法显示，全文详情请见：
http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000253&idx=4&sn=d8c2bc457cb1608eab1c464e8a307912#rd
欢迎大家一起交流。
扫描以下二维码，获取更多更精美文章！
关注我们微信订阅号（ uniguytech100） 与服务号（uniguytech），获取更多更精美文章！
也欢迎加入【大家技术网讨论QQ群】，群号码：256175955，请备注你个人的介绍！让我们一起聊聊it的那些事！