众所周知，SOA是面向服务（Service）的架构。所谓服务，就是应用程序中各个拥有不同功能的单元，而SOA架构就是要为各个功能单元之间定义良好的接口与契约，使其彼此间产生联系，从而在有限的资源条件下达成特定目标。
由于接口和契约都是中立的，也不依赖于任何一种开发语言，因此关于“怎样实现SOA？”这个问题，从来没有过固定答案。也因为此，关于SOA的争论与探索从未停止。
随着网络时代发展，新的商业模式和其身后大小林立的互联网公司们正在试图颠覆一切，使得微服务架构模式的设计、开发和部署被人津津乐道。基于这种现状，有人说，微服务会终结SOA；也有一些声音认为：微服务依然是 SOA 架构思想的一种实现，只是十几年前就横空出世的SOA意味着过去时，而微服务则是现在进行时。
 
互联网模式下的开源，属于巨头的游戏
其实对于大多数企业而言，计较架构之间的从属关系和寿命长短并无意义；而如何通过更科学、合理的架构真正利用好互联网的力量，为用户提供更有价值的服务，进而获得快速发展，才是真正值得思考的问题。
在这个过程中，由于可以根据企业需求随时调整技术与业务应用，不少企业都将开源技术视为解决问题的良方。但随着开发工作进展，高昂的维护成本、人力成本压力开始显现——如果没有技术“牛人”和资金的充足储备，利用开源技术打造业务应用系统并非易事。因为随着需求变化，相关系统也会产生各种调整，这不仅对IT人员的水平有着极高要求，还要求企业平时必须有足够人才积累。而这对于绝大部分企业来说都是可望不可及的。
换而言之，开源是少数互联网巨头才能持续的游戏，并不具备大规模复制能力。
 
剖析互联网模式下的微服务架构——服务组合迎来黄金时代
条条大路通罗马。同样是为了满足互联网模式下的业务快速扩展与收缩，微服务架构显然更具实践价值——它将复杂的应用分解为一个个彼此独立的微服务，由单个微服务去完成某个特定功能。这样做的好处是：单个服务的开发、部署、维护变得容易，各服务间更能够进行快速组合和重构，成为一个系统。这也符合互联网应用强调小型、快速、轻量化的特征。因此微应用既是值得提倡的模式，也是属于未来的必然选择。
事实上，正缘于互联网+转型大势与微服务的力推，服务组合的黄金时代已真正到来。值得一提的是：SOA当时已预见这一趋势，并通过ESB在“大服务”（WebServices时代的SOA，便于对照）时代较妥善的解决了服务组合问题。
但来到互联网+环境下，ESB已是难以为继。因为在“微服务”时代，内部服务与外部需求的衔接成为企业关键诉求，即要对外部大量业务性的微应用提供支撑。而“大服务”时代的产物ESB只能很好完成内部服务的组合与梳理，其挂接的大量单一业务逻辑的服务并不能满足外部的业务支撑需求——后者需要细粒度业务服务的组合，形成直接面向业务支撑的新服务，而这个组合量是巨大的。
另外，由于微服务和大服务对服务的理解与定义完全相同一致，因此在互联网模式成为主流后，微服务和大服务一样，都解决不了把复杂系统分解后所产生的应用如何组合，服务如何组合这些问题。在微服务架构下，每个应用都对应一个业务单元。而通常业务都是多个单元之间合作的，所以带来的问题是：只要把应用按对象拆开，组合就无处安放，一定面临着系统间流程调度的问题。如果建立统一的流程调度中心，则与去中心架构理念有违；而即便是成功的ESB实施，基本上也不含组合流程的功能，原因就是调度中心无论从业务上还是从性能上都不稳定。
基于这一现状，能否能真正支撑稳定的内外服务组合已成为对架构的关键要求，同时也是实现互联网模式的一个关键点。而打开这扇大门的钥匙，就存在于对服务的重新定义以及如何实现服务的多态性之中。
 
S++实现跨系统的组合
基于长期积累的技术实力与服务经验，业内领先的整合IT服务商神州信息创新提出了S++（Service Plus Plus）架构，首次明确了服务是对行为的抽象和归纳这一概念。
在S++架构下，服务的内涵得到了进一步提炼：所有与服务的具体实现者无关的服务属性，都属于服务的内涵范畴。因此只要具有相同要素的服务，都是一种行为。而且，服务不但具有空间的唯一性，还具有时间的唯一性，比如古代的餐饮服务与现代的餐饮服务，其实在要素上几乎没有差别。可以被提炼为一种服务。
S++与面向对象的方式最大不同之处在于：当一个消费者调用一个抽象服务的时候，消费者不需要知道具体要调用哪一个派生服务，从而实现跨系统的多态调用；同时，针对异构系统，由于不需要实现远程对象的调用，所以消费者不需要加载任何与派生类相关的信息，从而保证了异构系统间多态调用的实现。这意味着S++为组合业务提供了更优化的实现模式，由此也更好实现了SOA业务敏捷性这一终极目标。
通过S++实现业务组合的过程中，可以建立组合服务应用，并且在应用中实现服务的多态性，而无需业务系统配合。举例说明，假设组合应用中某流程需要调用服务A，服务A具有A1、A2、A3这三个派生服务，那么在组合应用中引入所有这些服务的定义就可以实现业务流程的多态性。将多态性的实现从业务系统中剥离出来的好处是，当A1、A2、A3分属于不同的业务系统时，仍然可以很好的实现，同时不会影响业务系统的稳定性。
 
S++的应用策略
对待新建系统和存量系统，企业内部有着不同的技术需求：存量系统要稳定，不进行大的架构和技术改变，同时尽量发挥作用；而新建系统则希望在稳定可靠的基础上尽可能采用先进技术和架构，以适应未来发展要求。这样的一种策略，必然会造成企业内部系统都是异构的。
从现况看，企业既会关注当期的新建系统的统一应用开发架构，同时也会关注未来异构系统之间的应用集成架构建设，以此在互联网+转型过程中更好发挥企业的能力与优势。而基于S++理念，对架构进行建设或调整，可称得上是有的放矢。希望采用崭新商业模式的企业，完全可以与专业厂商协作，利用更加高效和低廉的工具来帮助自己轻松跨越技术门槛，步入擅长的业务领域。
 
S++将成企业全面云化的基础
随着Docker技术的出现和快速发展，PaaS的应用范围得到了极大扩展：PaaS可以基于Docker进行伸缩，而Docker内部的应用就被屏蔽掉了，所以传统的存量系统可以被部署到PaaS云中，从而实现企业全面云化。
基于这一必然趋势，可以预见的是企业全面云化会导致在PaaS内部管理大量的应用集群，而且很多存量系统之间还是同步的耦合方式，必然会造成云平台本身的可靠性和稳定性降低，同时大大提高运维管理的成本。而S++的特性，使得它能很好地帮助企业建立全面云化的应用架构。