SOA架构设计的案例分析

Posted 2021-12-03 watm

SOA为面向服务架构，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。微服务是在 SOA 上做的升华，强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想。

SOA架构的特点为：系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范，解决的核心问题是【有序】；系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用，解决的核心问题是【复用】；业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务，解决的核心问题是【高效】。

微服务架构特点为1.通过服务实现组件化（不再协调其他服务部署）2.按业务能力来划分服务和开发团队3.去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。4.基础设施自动化（devops、自动化部署）的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理。

在下面SOA组件图中，服务和服务消费者(客户端)之间存在多个约束，当一个服务显式暴露后，客户端能够通过绑定定位到该服务，相当于两者签订了合同，规定了合同内容和如何实施，具体合同的描述是通过消息方式进行：

 

 

面向服务的架构SOA更加贴近业务客户，也更适合业务伙伴之间流程整合，各个行业已经诞生自己行业特点的SOA，例如电信联盟的NGOSS，已经成为电信行业业务支撑系统BOSS的标准。SOA不但是技术用语，也是业务销售用语，通过服务这个中间概念，可以实现业务和技术之间的无缝转换，如今SOA已经和REST RDD以及云计算等新技术方法结合。

服务提供者和服务消费者，这两者之间有一个合同约定，这非常类似我们现实生活中签订的服务合同，A单位和B单位分别是服务的提供者和消费者，两者签订了一个服务合同，规定A为B提供某项服务。服务就是提供一些公共需求的设施，通过一个工作过程能提供帮助，使用，让使用者受益。服务两个重要特点：自治和管制，自治代表服务不能被外部势力牵制，比如如果一个服务内部处理中需要调用外部资源或等待外部流程结束，这种等待不能影响服务本身的调用，如果一个服务分为显式对外和隐式内部两个部分，那么自治是针对隐式内部，意味着我们不能在具体一个服务中直接使用同步代码实现复杂功能。

实现服务真正自治，实际就是解决类之间依赖耦合的问题，消息是一种方式，但是基于消息又有两种通讯方式，基于请求响应和基于事件的EDA。

从服务自治可以看出，为什么要提出服务必须自治，因为服务是受管制的，在实际业务活动中，不同服务是被不同部分管理，比如定价服务归属财务部门系统，库存归属仓库系统，涉及系统之间调用协调不能自己使用同步RPC，而是需要消息。

在实际应用中，很多单位使用SOA主要看中其能够无缝整合新旧系统,称为EAI企业应用整合，下图是苏宁的一种SOA图，使用ESB企业服务总线这样的消息系统整合了新旧各种系统。

 

 

 

SOA使用者要根据自己业务进行模块划分，进行领域建模设计，根据DDD领域驱动设计将业务分解为一个上下文模块，然后再用服务作为对外接口，内部封装的是DDD聚合根，而传统SOA作法是内部封装的是数据表的DTO，从而导致SOA服务内部腐烂堵塞，违背SOA自治和可用性等原则约束。

 

参考链接：

SOA架构和微服务架构的区别

SOA面向服务架构

SOA百度百科