天天都在谈SOA和微服务，但你真的明白什么是服务吗？_jbo竞博官网

2023-11-04 09:47:41

专注于Java领域优质技术，接待关注作者：李东 极客时间近几年来，我一直从事着和面向服务相关的底层软件研发事情，逐渐的形成了一些自己的看法，其中我以为比力重要的看法就是服务需要一个更准确细致的界说。简朴来说，服务的本质就是行为（业务运动）的抽象。为了更好的论述新服务的观点，并利便与传统的SOA中界说的服务有所区别，我将新的服务命名为S++（Service Plus Plus），接下来我会通过对比S++与SOA和微服务的区别、S++与面向工具的差异来说明这个新的观点。为什么要重新界说服务呢？其中一个原因就是服务从差别的角度看其实是纷歧样的，我们举个例子。

服务到底是什么样子的？这个问题很有意思，有点儿横看成岭侧成峰的感受。是的，传统的无论是SOA界说的服务还是微服务界说的服务，一个服务只会有一个最全面的界说，这样的界说太庞大了，最后只有技术人员能看得懂。那么如何让业务人员也能看得懂呢？一般来说就是文档在起作用，可是文档有个问题就是只能看没法改，任何对业务服务的修改最终必须还要通过技术人员。

所以，传统的服务界说是业务和技术混杂在一起的，能不能有一种方法让所有人看到的服务都是一个样子而且都能看懂都能修改呢？这就是S++要做的事情，S++通过服务的业务与技术分散彻底将传统服务中和业务无关的技术身分剥离出去，放到服务的外延中去，让服务内在成为纯粹的业务形貌。另外一个原因是，从服务流程梳理人员的角度看，传统的服务抽象度是不够的。

举个例子，一个业务流程需要完成先在帳户上扣款然后再缴费这样的业务。对于流程编排人员来说，缴费这个服务可不是一个服务，首先有许多种现存的缴费种类（电话费、水费、煤气费….），而且未来另有许多种可能的种类。我们不行能在一开始就包罗所有的业务可能，可是我们又必须在一开始就包罗所有的业务可能，否则我就会陷入不停的修改之中。因此，为解决这个矛盾我们需要一个越发抽象的服务界说，在流程中只需要挪用抽象的业务服务，这就是S++需要解决的另一个主要问题。

S++与传统SOA和微服务的差异在观点和界说上的差异对于SOA，推进结构化信息尺度组织（OASIS）和开放团体（Open Group）均给出了正式界说。OASIS将SOA界说为：A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.Open Group将SOA界说为：Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation. Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.A service:Is a logical representation of a repeatable business activity thathas a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)Is self-contained May be composed of other servicesIs a “black box” to consumers of the service业界基本的认知是，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++来说，服务的界说是不需要依附于工具的，上述例子中服务消费者只需要引入hello服务的抽象界说hello(Sting personID)。当这个抽象的服务会见发送到ESB（如果没有ESB就需要服务提供者具备多态容器的功效）上以后，ESB会凭据预先约定好的服务界说和服务Cast规则举行运行时刻服务实例的选择。

对于传统IT开发人员来说，这一历程更像业务的历程（通过一个业务字段的内容来判断挪用哪个业务流程），其实对于SOA服务的开发人员来说，这个历程是透明的，因为服务界说人员在界说服务的时候已经约定了多态的规则，因此这一部门业务已经被技术化从而可以被技术平台直接实现。在SOA架构中，类似的业务功效技术化的必备功效另有一些，好比传统的冲正被用于全局事务一致性以后就必须技术化。

S++相对于微服务，在耦合性上也是有很大差异的。由于微服务将应用拆分到足够小，甚至可以小到一个工具一个应用，这样原本存在于工具间的业务逻辑一定就会造成微服务之间相互挪用，从而形成应用间耦合性；S++认为工具间组合逻辑应该交由一个S++容器去完成，这样就将微应用之间的耦合消除掉了，可是同时也发生了一个业务逻辑调理中心。S++与面向工具的差异关注领域的差异面向工具关注的是工具的内在属性，只要内在属性一致，我们在建设工具模型的时候都将其抽象成一类工具，所以内在属性的是形貌工具的不行更改要素。

这种特性使得OOAD的方法很是适适用于建设系统内部数据模型，通过对系统内部实体的抽象和形貌，我们可以获得系统完整的数据结构和模型，而系统的功效就通过对这些工具的增删改查和盘算等行动来完成。而面向服务则否则，面向服务并不体贴服务的内在逻辑，反而更体贴服务的外在表象，只要对外的体现是一致的，我们在建设服务模型的时候就将其抽象为一类服务。

好比缴费类服务，无论是缴水费还是缴电费，其外在的表象都是一致的，从行为模式上我们就可以抽象一个缴费的服务。面向工具中工具内在的属性是不行更改的要素，那么面向服务中组成行为的输入输出内容则成为不行更改的要素，好比打球这种行为，必须要有球也必须要有到场者。

服务的这种特性使得SOAD的方法更适合于在系统间建设交互模型，这样通过一个外在的流程引擎就可以通过合理的组织行为的顺序就告竣了业务的目的。从这一点上来看，现在的IT系统存在着大量的冗余。好比开户这个行为，各行各业的业务系统都有，都是差别的实现，可是其实有差异吗？肯定有，可是我要说的是这种差异都是人为造成的，或者说都是系统内部的差异，从外在行为上来看，不都是一小我私家来到你的柜台或虚拟柜台认证注册一下吗？从行为的抽象角度看，我管你内部是填一张表还是两张表吗？我管你需要几多环节审批吗？其实一旦面向服务的看法被更广泛和深入的认知后，一定会有专业的账户治理机构泛起，所有行业的应用需要开户的时候都市直接挪用公共的开户服务，这是社会分工的一定趋势。

我在这里斗胆的预测一下，未来垂直行业的应用提供商一定会逐步消失，取而代之的是种种专业服务提供商+跨行业应用（或服务）提供商。上图建设了一个理想的云端企业IT模型，其中大部门的应用系统都来自专业的公司提供的公共云服务，企业通过自己的服务建模对云服务举行裁剪，并建设自己可能存在的奇特内部应用。然后，通过对内外部的服务能力举行编排组合，从而快速形成自己的业务。

多态性的差异我们都知道，OOAD之所以能成为现今软件界广为接受的一种方法论，有一个关键点在于工具的多态性对系统稳定性带来的利益。多态性解决了业务流程中不停变化的业务分支发生的代码维护的价格，在面向历程的一段代码中，任何实体发生增加和改变都市导致这段代码需要被修改，于是随着系统的快速膨胀，这种修改变得成本庞大甚至无法蒙受；而OO的方法巧妙的通过多态性解决了这个问题，所以才会有越来越多的超大系统泛起，用于解决越发灵活变化的庞大业务需求。面向工具的多态主要解决工具实体属性的扩展和利用方式的差异，也就是说工具属性是不行修改（或重载）但可以增加，工具的方法（利用方法）可以重载。

那么类似的，S++的方法也希望为跨系统的应用带来稳定性。好比，在传统BPM的一段流程中，任何行为自己发生增加和改变都市导致流程自己的修改，成本也会随着系统的增大而变得不行忍受。举个例子，通过一个简朴的流程去完成查余额然后缴费，传统的BPM需要对所有的缴费方式设立相应的业务分支，一旦有新增的缴费方式泛起就必须修改这个流程，增加新的分支；而服务多态性则只需要挪用缴费的抽象服务，详细的缴费服务是凭据运行时刻的数据由服务的多态性自动完成匹配的。在服务多态性中，与OO差别的是，由于服务自己就是行为所以没有所谓方法的重载，服务被重载的只有服务对外表达的属性。

好比缴费服务中，待缴账号是抽象服务的属性，而被实际服务重载后，就酿成电话号码（缴电话费）、水表序号（缴水费）等等实际的行为到场者了。如果实现了服务的多态性，就可能解决传统的组合流程会随着业务变化而需要修改的问题，从而可能改变传统的业务开发方式，使得大规模使用组合流程引擎开发业务逻辑成为一种可能的选择。小结S++通过对传统服务的界说举行扩展，重新界说了服务这个最基本的观点，第一个plus加入业务与技术分散，第二个plus加入服务多态这两个新的特点。这使得S++继续了SOA和微服务的优点，更进一步的降低了服务的庞大度、提高了服务的抽象度，使得服务越发易于治理和使用。

后面我们会看到，基于S++界说衍生出的种种特点在业务和架构层面临传统技术造成的庞大打击和革新，一定使S++替代传统的SOA和微服务，成为未来企业应用开发和集成技术的主流。作者先容李东，14岁开始学习盘算机语言，作为课外兴趣自学了BASIC和汇编，使用放假期间编写了贪吃蛇、打飞碟等游戏。

高中、大学期间继续自学软件编程，曾将C和汇编联合使得从高级语言中能够挪用绘图功效，并模拟Borland C++开发了一套适合学校机械的图形化开发情况的原型。93年大学结业后在西门子合资公司作为交流机软件安装人员事情两年，然厥后到JInfonet公司先后到场4GL的研发和JReport的研发。作为JReport的第一代主要研发人员，编写了从原型一直到3.0版本的焦点引擎部门。

2000年与合资人一起建立了Bi-Soft公司，主营业务是商业智能软件Bi-Pilot，卖力整个产物的研发及治理事情，从最基本的查询一直到多维分析模型和引擎都是产物的涵盖规模。2007年Bi-Pilot被神州信息收购合并，李东开始在神州信息研发SmartESB产物，用SOA的方法论为客户提供底层产物服务。

本文来源：jbo竞博官网-www.reinafresh.com