当今世界，信息技术正在推动着社会生产力的发展，随着行业业务发展的多样化、多需求化，新的理念、技术、IT术语层出不穷，例如：移动互联、物联网、云计算、大数据、人工智能等，这些词语的出现一定程度上促使电子政务、智慧医疗、数字化农业、移动办公、智能家居等治理理念不断涌现并得到大力发展，今天小编就来说说关于soa的技术路线?下面更多详细答案一起来看看吧!
soa的技术路线
当今世界，信息技术正在推动着社会生产力的发展，随着行业业务发展的多样化、多需求化，新的理念、技术、IT术语层出不穷，例如：移动互联、物联网、云计算、大数据、人工智能等，这些词语的出现一定程度上促使电子政务、智慧医疗、数字化农业、移动办公、智能家居等治理理念不断涌现并得到大力发展。
事实上，很多技术词汇在很早的时候就已经出现过，由于特定时期的外部环境原因并没有被大众熟知或技术在当时没有得到普及，导致那些词汇还没有来得及火起来就被埋没。随着社会环境、科技大趋势的发展，有些技术词汇重新包装、炒作，然后又开始慢慢火起来，甚至形成所谓的风口。
曾经被热炒关注的SOA（Service Oriented Architecture面向服务架构）一词好像也已经走向落寞，不再被人提起，但事实并非如此，其实SOA因为理念的不断推进、产品的不断完善，已经告别概念阶段，走向落地，很多企业也改变了对SOA架构理念的看法，趋于认可并计划实施。虽然SOA已经落地，但对于很多人来说它仍是神秘的，具有多种定义和展现的。那么，今天就来与大家一起探讨SOA的内涵与外延。
SOA基本概念百科上给出的定义是：SOA（Service Oriented Architecture ）面向服务的架构，它是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种各样的系统中的服务可以以一种统一通用的方式进行交互。
看了上述的解释，相信很多人还是不能完全理解SOA究竟是什么，它能解决什么问题？事实上，对于SOA不同的厂商有不同的定义，有人说它是一种架构体系，有人说它是一种方法论，有人说它是一种治理理念。横看成岭侧成峰远近高低各不同，仁者见仁智者见智。
而我认为：与其一定要给SOA一个通俗易懂的解释，不如弄清楚SOA这个概念是在何种情况之下产生的，之后我们把答案反过来想，既然SOA可以解决这些问题，那么SOA的概念就能变得简单易懂些。
SOA产生原因在这里，暂且把SOA的由来归纳为两个方面，一个为技术方面的需求，另一个是业务层面的要求。
1.技术方面
>>>>屏蔽异构性
所谓异构性，指的是存在于计算机软硬件之间的异构性，包括服务器、CPU、操作系统、开发环境、数据库等，因为企业所构建的基础设施都是来自不同厂商、使用不同平台、不同语言的，它们之间是不兼容的，而屏蔽系统间的异构性成为SOA产生的一大原因。
>>>>服务可复用
相同领域的系统在结构上存在着相似性，每次整合开发都从头开始太过耗时耗力，这时服务可复用显得尤为重要，而SOA的重要特征就是以服务为核心，通过服务组件来实现更高层次的重用，因为服务是通过标准封装，服务组件之间的组装、编排和重组，来实现服务的复用。而且这种复用，可以在不同企业之间的服务复用，是动态可配置的重用。
>>>>可互操作性
因为网络协议和通信机制的不同，系统间的相互集成受阻，不同软件设备之间没有统一的协议标准及规范，平台之间不能相互移植、相互操作，而基于SOA架构的平台产品可以很好的实现系统间的互操作。
通过上述的需求，我们可以分析出，SOA将各个应用系统中的不同功能通过接口方式联系起来，它可以屏蔽硬件平台、操作系统、编程语言的异构性，并以一种统一的、标准的、通用的方式进行交互，同时基于SOA构建的架构，可以使企业的IT系统更灵活、能更快地应对企业业务需求的变化。
2.业务方面
>>>>信息孤岛
随着企业自身经营管理水平与业务执行效率的要求越来越高，信息化建设是提高管理水平的重要支撑，随着信息化系统的不断增多，企业的IT架构逐渐走向僵化，一系列问题也接踵而至，如：企业现有的各应用系统的基础平台和技术架构不统一、各系统分散部署、数据相互孤立形成信息孤岛等，这时应用系统间的数据共享与功能集成需求日趋频繁，信息系统间的有效整合，提高系统间的数据交互、信息共享水平以及业务处理效率变得尤为重要。
>>>>资产复用
随着企业信息系统越来越多，在治理面前必将精减或新增一些信息化系统，过程中不可避免会替换甚至是除掉一些平台或功能相似的系统，如果每次治理或开发都要推到重来，在时间和成本上是不可控的，所以复用IT资产也是推动SOA发展的重要动力。
>>>>业务发展
激烈的竞争和产业变革，需要企业不断调整其组织、流程和商业模式，以获得竞争优势，但基于以往传统模式构建的企业信息化架构，僵化的IT系统面对企业业务的变化，无法快速做出响应，造成系统无法为业务提供良好支撑的现象，稳定可扩展的基础业务框架及应用支撑平台，为企业的业务发展、随需应变提供重要的支撑。
SOA基本特征1.技术特征
SOA的目标在于让IT系统变得更有弹性、灵活以及能够更快地响应不断改变的企业业务需求，具体技术特征归结如下：
2.业务特征
SOA的业务特征来自于企业对业务方面的实际需求和管理，如：解决信息孤岛、业务协同、数据集成、后续业务支撑等，这里将分层次说明。
>>>>数据集成
数据集成主要针对企业信息系统底层的数据同步性、时效性问题，解决数据来源的唯一性、真实性、实时性，这里包括数据治理和数据集成两部分。
数据治理通过一组标准和方法转换异构操作数据，保证一个企业内的基础数据（组织、人员、岗位、客户、供应商、物料等）在整个企业范围内保持一致性、完整性、准确性。数据集成一般通过消息队列技术或者Web服务等，将散布在企业各个系统中的数据，以一种松散耦合、集中呈现的方式进行统一管理，促进数据在企业范围内互联互通。
>>>>应用整合
应用整合主要针对企业业务变化适应性和信息孤岛问题，通过对系统功能的服务化编排，实现快速调整的弹性应用。应用整合提供面向服务所需的软件基础设施环境，为分散服务提供了交互、组合和治理的基础架构，集成企业内部各个IT 应用系统，并使之互相协同工作，形成一个更大的整体系统。要求不只是实现系统间的技术集成整合，还要实现业务之间的有机整合。
>>>>业务协同
业务协同通常也称之为流程集成，主要针对企业业务逻辑在多个信息系统之间流转的问题，具体体现为跨异构系统的流程集成，以业务流程为中心，帮助企业各业务环节与客户需求对齐的管理方法，有效整合人力、信息等资源，实现跨系统、跨部门、跨组织的企业运营，支撑企业实现业务的“纵向贯通”与“横向集成”，帮助企业实现从战略到运营端对端的跟踪、反馈与优化。
>>>>统一入口
统一入口即门户集成，主要针对企业交互访问层集成问题，把企业内部原有的零散系统中的信息、应用、服务通过统一认证、页面集成、菜单集成、数据门户等技术整合在统一的访问平台，提供企业范围内的统一授权和身份认证，基于单点登录、个性化配置方式，为企业IT架构提供一个标准的、可扩展的Web 应用基础框架。平台支持多端登录，即PC门户、移动门户，移动门户同样提供统一身份认证、单点登录、信息/页面/应用集成等功能，通过移动门户可以访问PC端系统大部分功能，用于满足出差在外流程审批、办公不受时间地点限制。
SOA架构模式首先看一下什么是SOA架构，SOA架构是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。
SOA架构泛化来看映射的是整体企业架构，企业架构又分为业务架构和IT架构，IT架构又分为应用架构、数据架构、技术架构。在SOA项目中，借鉴企业架构之道，并通过SOA技术架构和应用架构将业务系统构建和整合、并纳入整体企业IT治理体系中，企业IT治理体系图如下所示：
1.SOA企业架构
企业架构是指对企业事业信息系统中典型的、普遍的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动来理解、分析、设计、构建、集成、扩展、运营企业信息化系统。当今很多企业的信息化建设都是早期为满足当时的业务运转而设计与实施的，但是随着业务和技术进步，以及需求变化，现有的IT系统难以支撑业务快速发展的步伐，很多企业开始尝试使用SOA架构重构企业架构。
在进行重构之前，需要梳理企业架构中几个重要的方面：组织机构、业务流程、IT设施，如下图所示：
在了解以上几点后，对其进行标准化、规范化及合理管控。首先，通过SOA制定统一的标准规范，将原有的系统进行改造，统一接口，进行系统重构，应用集成；其次，对于不能满足集成标准的系统，必要时根据SOA架构标准进行整改、甚至重建。后续新建的应用系统都基于SOA标准规范进行建设，避免重蹈覆辙，保障统一的企业IT架构治理体系、满足业务发展的整体需求。
2.SOA技术架构
ESB企业服务总线所在的服务层，作为企业信息化的龙骨，保障业务系统的互联互通，所有的业务最终都可以保留为接口服务的形式，同时基于ESB实现服务的注册、接入，服务操作使用、服务编排、服务安全、数据传输等功能。
BPM流程平台所在的流程层，主要提供流程引擎、流程编排、流程监控等功能，用于实现异构系统间的流程运转。左侧MDM主数据管理主要提供企业内组织、人员、岗位、供应商等基础数据的统一治理，作为企业信息化数据治理的基石，保障企业内部各应用系统的各基础数据的一致性、真实性、准确性。
最上层Portal门户平台所在的展现层，作为企业信息化的统一访问入口，实现统一认证、单点登录、工作台、菜单/页面集成、信息聚合等，主要为各种应用系统的功能、流程、服务提供统一的交互层的集成平台。
开发平台提供统一的开发框架及开发环境，内置技术组件和服务，可以用于快速构建符合SOA架构的应用系统。
3.SOA应用架构
SOA应用架构部分与传统的应用架构不同，此部分通常称为SOA集成解决方案，主要考虑系统整合重用功能，及对业务治理的需求设计及后续的实施方案。
SOA集成解决方案需站在企业顶层位置，对企业IT情况进行了解规划，从而构建适合企业业务发展的应用架构，解决方案分别从以下三点入手：
通过SOA综合集成方案（即数据集成、应用集成、流程集成、门户集成）的支撑，构建统一、集成化的企业IT架构，实现企业业务功能及流程的整合优化，支持平滑升级，为企业后续信息化建设持续打下基础，实现总部、区域公司、基层业务单元等良好协同，提升运营效率、支撑业务发展、促进业务升级与创新。
SOA如何落地分析了这么多SOA的深层次含义，那么SOA将是如何运用到企业中的呢？要想真正实现价值，一定需要：支撑SOA的集成中间件产品、符合SOA架构的应用系统、构建SOA体系的方法论和最佳实践。从SOA兴起到快速发展，国内外出现了很多中间件厂商如BEA、IBM、Oracle、JBoss、数通畅联、普元、东方通、中创等，下面就来了解具体有哪些落地产品。
1.SOA国内外现状分析
SOA的兴起源于国外，而且很多定义都是从国外延续过来的，早期SOA在国外的发展是较快的，在国外SOA概念深入普及的同时，国内也兴起了对SOA的研究与实践。
国外现状
在国外，从主机时代、PC时代，到了现在的网络时代，积累了大量的应用系统。所以国外的SOA理论以及产品的发展一直快于国内，在SOA技术兴起初期，很多国外中间件产品进军国内，一度曾经火热大卖，但如今也几乎销声匿迹，分析后归结于以下几点：
国内现状
对于国内，很多企业在认识SOA理念这件事情上，变得理性，不再认为SOA理念是虚无缥缈的、夸大的、无法落实的，这预示着SOA将正式走向普及。虽然SOA在国内已经得到企业的认可及应用，但在普及的过程中没有出现大火特火的现象，相对来说较为平稳，同样的将这种情况分析后归结于以下原因：
另外有一个有意思的现象，有些OA协同领域厂商看到SOA市场潜力和价值，对自有主打协同产品进行扩展，贴上SOA整合集成的标签，承接SOA集成项目，但由于产品基因以及人才队伍缺失，通常项目最终实现效果较差，达不到全面整合、整体协同的目标。
2.SOA整合套件的构成
那么，如何才算将产品形成闭环或者一个完善的SOA产品线，究竟是由哪些产品构成的呢？根据架构模式中的架构层次，一般包括各种不同网络应用系统之间的消息通信、服务集成和数据集成功能的中间件产品，常见的几种集成中间件产品为：企业服务总线、门户集成平台、身份管理平台、主数据管理平台、流程集成平台等。
上图中的产品组合可以称之为是一幅较为完整的SOA整合套件，产品间相辅相成，灵活组合，彼此之间组成不同的解决方案，满足绝大多数应用场景。如：IDM（MDM） ESB Portal企业应用中心项目、IDM ESB统一身份认证管理项目、ESB MDM数据治理项目、ESB MDM Portal BPM MAP 综合集成项目等，可根据企业项目的不同需求/性质，将产品组合搭配，最终形成特定的、符合企业自身业务的、能够适应企业当前以及未来发展的最佳解决方案。
3.SOA项目的最佳实践
SOA项目的最佳实践这里主要指SOA项目的实施方法论，即交付体系，由于每个SOA厂商对SOA的概念理解不同，自然实施方法论也各不相同，这里我不准备介绍标准的实施方法论，而是想介绍一套符合国内企业情况的项目实施方法论。
因为一直耕耘于SOA综合集成领域，数通畅联经过对多家大型企业系统集成成功实施的经验总结，同时结合国内外先进的实施方法和实施工具并根据我国企业的实际情况，提炼出一套标准的、科学的实施方法，不但能提高系统实施的效率，也能保障项目的成功交付率。
注：但凡是项目就一定有失败的风险，软件项目更甚，应用集成项目尤为突出，后续将有专题来讲解SOA集成项目的风险与应对。
项目前期阶段主要为商务阶段，包括销售公关、售前技术讲解、合同签订等事宜，合同签订后PMO项目负责人将与项目实施人员一同进入项目，根据客户内部组织、业务目标、运营流程、项目需求等信息，进行项目整体规划和协调，并对项目实施过程把控、监督，推进项目至蓝图确认里程碑。
项目准备
这一阶段是项目的计划和准备阶段，主要活动包括：
项目蓝图
项目准备阶段过后，主要进入需求调研与计划设计阶段：
项目实施
本阶段主要根据独有的项目实施方法开展工作，通过完备的管控方法及产品功能实现客户的需求。
项目验收
验收阶段主要工作是对项目整体实施工作的回顾和总结，对实施工作的认可，也是对双方高层领导的一个工作汇报，验收合格后，转入系统维护期。
因为SOA理念的特殊性，很多时候会被人拿来与新技术做比较，今天在这里笔者也将当今较火的几个词语，云计算、微服务、大中台与SOA之间的关系做个简单的分析。
1.SOA与云计算
众所周知，提到云计算一定会提到以下几个层次的服务：基础设施即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS）。
在SOA架构中，首先可以考虑SOA集成套件本身的应用集成能力，数据集成能力，流程引擎能力等，PaaS平台既是一个在线开发环境，也是一个在线运营环境，不管是对于开发或执行，在SOA中谈到的数据服务、业务服务、流程服务，展现服务等都可以作为PaaS层在线开发的时候的能力单元。而这些能力单元在线进行服务编排和组装又可以借助SOA套件中BPM产品的BPEL和规则引擎来完成，所以SOA平台提供的ESB，BPM等产品技术，可以被看作是云计算PaaS平台层中的整体能力的重要组成。
而PaaS平台除了是提供标准统一框架、接口、环境的技术平台，也是服务于行业用来实现特定业务环境功能或服务的产品平台，通过Portal门户平台、MAP移动应用门户分别作为框架PC端和移动端的业务承载平台，通过ESB企业服务总线WEB/REST服务及管理控制台注册代理其它系统提供的WEB服务、REST服务，提供面对业务系统的运营支撑（资源的管理、分配、监控状况），面对用户的业务支撑（系统的功能、使用状况），通过BPM流程平台实现业务间特定的流程审批跳转等，这些产品的组合使用来实现PaaS平台的核心技术支撑。所以云计算一定程度上促进了SOA内涵的丰富， SOA在云计算体系中PaaS层面也发挥着重要的作用。
2.SOA与微服务
微服务是当下比较火的一个词语，微服务架构是一项在云中部署应用和服务的新技术。微服务架构是否可以取代SOA架构，一直都是备受争议的话题，其实这两种架构在原则上确实相当近似。微服务主要是经过组件分离各自拥有独立的生命周期，并且按需进行扩展，这种方式打破了组件之间的技术依赖，这就允许每个服务各自选择最合适的技术进行实现，即不同的服务甚至可以采用不同的编程语言来实现，一定程度上微服务使技术方案变得更加灵活；微服务架构可以简单理解为SOA without ESB，不带ESB的SOA架构。
对于复杂的大型的项目来说，将一个整体治理的问题进行分解，用不同的方案实现，就略显笨重，因为要兼顾的技术和语言太多，服务本身的调用、日志流量的监控、安全性等事宜叠加起来放大项目的复杂度。SOA架构强调的是整体企业IT架构，而企业IT架构包括应用架构、数据架构、技术架构，SOA架构及方法论帮助企业制定正确的IT架构战略，将企业系统划分为不同的服务，增强系统间的灵活性的同时，为企业搭建一个统一的IT治理体系。微服务架构更多则侧重于应用架构，或者说应用开发的技术架构。可以从下图看出SOA架构与为微服务架构的关联与区别。
3.SOA与大中台
大中台一词是最初由阿里提出的，意在为电商产品提供快速设计方法和系统性后端服务，那么大中台一词是如何提出的呢？因为阿里平台与商家的关系，虽然相互之间是独立的主体，但因为业务上的合作，已经分不清彼此。对于电商来说前端就是一线业务，需要适应瞬息万变的市场环境，并可以敏捷的、灵活的、快速的做出决策；而这时就需要一个强大的中台，包括运营数据能力、技术能力、支撑能力、产品能力等。
在这里之所以拿SOA与大中台做比较，是因为在分析大中台的技术及业务特点后，发现两者存在相同之处。大中台符合电商行业的特性，可以同时运用在许多电商平台的设计和服务中，有效省去许多互联网电商的设计、开发和运营成本，同时基于电商行业的业务要求，提供了一套完整的后台服务、客服系统、运营系统、仓储物流系统等，在此平台上电商企业只需要少数个性化的建设即可。
从SOA角度来看，大中台技术在一定程度上与SOA中的开发集成方案相似，示意图如下：
SOA开发集成方案在面向行业平台项目中具体实现思路为：采用SOA整合套件作为基础技术框架及应用支撑平台（ESB、Portal、BPM、MDM），梳理、制定出面向行业业务的标准接口和管理体系，根据标准接口规范集成行业的典型应用系统，不满足或者特殊业务功能可以根据行业/企业具体需求使用DP开发平台来快速定制开发，然后集成于整个平台中。基于SOA开发集成模式实现行业化的平台类项目，来保障项目平稳落地、敏捷升级扩展。
总结来讲，随着云计算、微服务、大中台的兴起，有人认为这些技术最终会取代SOA技术，很多人认为SOA已经走向衰落，但作为专业的SOA产品套件和解决方案的提供厂商，我们认为这些技术一定程度上推动了彼此的发展，随着科技、社会的发展不断地演变，SOA架构理论及产品必将更加符合当今时代要求、与时俱进不断扩展外延丰富内涵。
本文由数通畅联原创，欢迎转发，仅供学习交流使用,引用请注明出处！谢谢！
