每天都在談SOA和微服務，但你真的理解什么是服務嗎？

近幾年來，我一直從事著和面向服務相關的底層軟件研發工作，逐漸的形成了一些自己的看法，其中我覺得比較重要的看法就是服務需要一個更準確細致的定義。簡單來說， 服務的本質就是行為（業務活動）的抽象。

為了更好的闡述新服務的概念，并方便與傳統的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 that

• has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)

• Is self-contained May be composed of other services

• Is 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的方法論為客戶提供底層產品服務。

 

閱讀原文