【系统架构设计师】论文：论SOA在企业集成架构设计中的应用

论文：论SOA在企业集成架构设计中的应用

论文一

摘要

2021年10月, 本人所在保险公司启动了超级销售 APP 项目，该项目通过运用先进的销售工具、客户管理、营销活动管理等功能以达到提升销售人员的效能,加大业务驱动的目标。我在该项目中担任系统架构师, 主要负责系统的架构设计工作。 本文以该项目为例, 主要论述面向服务架构中的具体应用。 通过服务提供者，对外提供服务的描述、定多和发布，设计遵稍原子性、通用性、兼容性等原则 ;通过服务注册中心 ,实现服务管理用于服务的注册与注销, 注册记录服务的名称、IP、端口等相关信息，服务查询提供服务实例查询; 通过服务消费者，从注册中心查询服务提供者的地址, 通过该地址调用服务提供者的接口, 简化业务实现过程，提高开发效率。基于以上技术的应用，项目成功上线，获得用户一致好评。

正文

本人所在的保险公司分支机构遍布全国，已设立分公司 36 家,机构总数超过2100 家，和营业机构蓝盖全国各个省份，系统员工人数超6 万人。因保险生态体系的变革 , 各保险公司都在积极科技转型 , 公司基于新业态发展通过 “线上化、数字化、智能化”加速推进“三新三聚焦”的战略转型。故启动了超级销售 APP项目建设,本项目旨在建设业界领先的面问营销员的,具有前瞻性和可扩展性的，寺合主流技术的保险销售一体化平台，聚焦核心作业功能，体现支持、服务、提效和赋能。系统主要实现功能车险、非车险出单、业绩管理、客户管理、营销活动、商业计划书、续保管理等。通过两个视角挖掘,营销员视角，集获客、展业、服务、个人成长为一体, 作业辅导始终伴随的创新工作模式、 挖掘潜在销售机会，提高工作效率，促进职业能力发展; 管理视角,综合管理招募、培训、业绩、活动、提供营销指导和线索及客户服务锦塞，降低消息传递成本、提升营销员团队整体产能和绩效。

该项目于 2019 年 10 月正式启动, 我担任系统架构师角色, 负责系统总体架构设计工作。 系统分析过程中,为了实现业务的功能需求,除了内部微服务之间的通全交互，还有外部与我司周边 17 个业务系统进行通信交互，获取相关的数据进行处理后才能完成相关流程。其中主要系统有核心、影像、销管、收付费、集中收蒜、ECIF、客户画像、增值服务等多个业务系统。为了实现在区多系统间建立统一的通信标准，降低系统间的耦台度, 提高系统的复用度, 按照面向服务架构的设计思想就是一种理想的方案，来实现系统间交互的设计。

S0A 是一种应用架构模式，在这种架构中，所有功能都可以定义封装为独立的接口对外提供服务，服务之间通过交互和协调完成业务的整体逻辑。SOA 实现方式包括服务提供者、服务消费者、服务注册中心， 通过采用底层传输、服务通信协议、服务描述、服务层、业务流程、服务注册层等相关约束提供支撑。原则上提供的接口服务必须都是无状态、高可用、易于水平扩展节点的。SOA 作为一种粗粒度、松耦合的架构， 具有松散耦台、粗粒度服务、标准化的接口、位置和传输协议透明、服务的封装和重用、服务的互操作等几个特点。这种松散耦台和跨技术实现, 使各服务在交互过程中无需考虑双方的内部实现细节、实现技术、以及部署在什么平台上, 服务消费者只需要提出服务请求， 就可以发现并调用其他的软件服务得到响应。

架构分析阶段明确使用面问服务的架构解决内部微服务之间相互通信的管理调度，与周边系统交互采用企业服务总线 【ESB) ，有效提高系统的透明性、高可用性，下面基于服务提供方、服务消费方、服务注册中心论述其应用过程。

一、服务提供者的实现
服务提供方使用WebService 设计实现生成 WDSL 对外提供描述与定义。作为本系
统需要考虑两个方面。一方面需要系统内部微服务之间提供的服务通信, 综合考虑服务粗粒度、松耦合、进行服务的设计，避免服务通信和期间，信息量过大,，服务之间交互过于频繁, 尽量的减少服务被调用的数量。同时采取服务迷断机制使用Hystrix 组件完成,其内部提供了断路器开关装置, 当某个服务单元发生故障，监控向调用方法返回一个符合预期的、可处理的备选响应, 而不是长时间的等待或者抛出调用方法无法处理的异常, 以此避免雪崩效应。另一方面外部系统服务之间服务通信, 采用三种方式实时同步的通信方式因数据处理罗辑及不可预测原因引起的通用服务熔断降级处理; 企业服务总线 ESB 配置超时时间, 作为郊余的防范机制; 微服务压力大的应用程序采用服务路由及负载均衡元余服务器; 在将对于交互实时性要求并不高的服务, 改为消息订阅的这种异步交互方式, 降低了问题发生的概率。

二、服务注册中心的实现
系统使用微服务使用的 Spring 的 Eureka 组件搭建注册中心 ,服务提供方和消费方都在注册中心进行发布注册, 服务交互时通过注册中心获取对方的服务地址信息，然后发起 RPC 远程调用。原则上提供的接口必须都是无状态、高可用、易于水平扩展节点的。其次，它通盖了主要领域目前分为出单、 业绩等部分功能的业务组装， 实现对于一些复用性较强,与具体业务并无多大关系的内容, 会尽量复用公共服务部分所提供的标准接口，尽量最大程度的实现基于现有业务的组合，而不必来一个业务，从头开发一个业务。系统与外部集成采用企业服务总线(ESB) ,外围系统交互涉及 17 个如核心、影像、销管、 收付费、集中收款、ECIF、客户画像、增值服务、续保、理赔、标的库等。ESB 提供了连接企业内部间现有系统的功能，服务注册命名管理,提供消息路由及寻址服务,支持多种数据格式转换,提供日志和监控功能。通过系统内服务注册中心， 系统外的企业服务总线双重机制，集中服务的管理及监控，有效提高系统的透明性、高可用性。

三、服务消费者的实现
应对市场变化业务需求变更频繁, 同时对技术能力提出更多挑战, 我们在实现一个功能时往往我们会优先考虑是否有现成的一个接口服务能满足要求, 而不需要二次开发以此提高开发效率,减少代码元余。以续保跟踪微服务为例, 内部调用公共模块需要登录校验获取相关数据权限, 外部系统调用续保系统获取该营销员名下车险到期保单数据,如果全部在一个微服务内实现, 不但增加了太量的郊余代码,同时需求变化将导致所有微服务更改将极太提高项目风险,对于到期保单数据的清洗放在业务系统实现也增加应用数据库的压力。所以项目阶段集成设计时要合理的设计目前接口两种形式，SOAP 优点在于格式统一符合标准，缺点是文件格式复杂占用带宽; REST 协议使用 JSON 方式数据格式简单易于读写，格式压缩占带宽小。基于上述特点采用 REST 协议 ，通过在服务注册中心管理服务注册, 查询服务中心来调用屏项地址端口等信息简化分布式部署, 调用外部系统服务通过企业服务总线授权配置转换协议类型配置授权访问, 通过合理调用提供方服务，简化实现逻辑，提高了系统的开发效率。

总结

整个项目历时9个月的实施,于 2022年6月完成验收并顺利上线，日均出单保费规模达到干万级别，赢得了恨好的用户口碑也在业界内树立了标杆。

实践证明面向服务架构的应用, 改变了从技术和成本的关注逐渐到业务和价值的关注, 通过 SOA 能够很好的将业务和技术融合起来, 使技术和结构更好的为实现业务和价值服务。项目在实施过程中不足的地方需要反思总结经验, 例如数据安全方面, 接口服务涉及到敏感等数据信息如泄漏将造成不可估量的损和, 可采用内网网络采用对称加密数据, 互联网络使用私钥、公钥加密同时使用白名单防止数据劫持，保证数据的安全。在本项目中基于以上 SO0A 技术的应用，有效缩短项目开发实施周期，加大复用程度，降低开发成本，增强了系统的可扩展性。

论文二

摘要

2021年8月，我参与了胶凝砂砾石坝施工质量监控系统的开发工作，该系统旨在帮助水利工程建设法人单位、施工企业、监理机构及相关政府部门解决水利工程建设施工质量监控和工程项目管理等问题。我在该项目中担任系统分析师，主要负责该系统的系统分析及设计工作。本文以胶凝砂砾石坝施工质量监控系统为例，

主要论述了SOA在企业集成架构设计中的具体应用。服务提供者主要完成服务的设计、描述、定义和发布等相关工作；服务注册中心保证该系统各个模块、服务的相互独立性与松耦合；服务请求者通过WebService技术调用服务。实践证明，通过以上技术的应用有效实现了资源共享和系统间的互操作性，提高了系统的灵活性，最终系统顺利上线，获得用户一致好评。

正文

胶凝砂砾石坝是在面板坝和碾压混凝土重力坝基础上发展起来的一种新坝型，其特点是采用胶凝砂砾石材料筑坝，使用高效率的土石方运输机械和压实机械施工。与常规坝型相比，胶凝砂砾石坝在适用性和经济性方面具有独特的优势，可以就地、就近取材，不需设置集料筛分，施工进度快，施工工序简单高效，因而要求施工过程紧凑，高峰期筑坝效率要求高，这给施工质量控制带来了一定的困难和风险，需要综合考虑影响施工质量的各方面因素，尽量采用自动化监控手段，加强实时质量监控力度，这使胶凝砂砾石坝施工质量监控系统应运而生。

2021年8月，我参与了胶凝砂砾石坝施工质量监控系统的开发工作，担任该系统的系统分析师，主要负责该系统的系统分析及设计工作。该系统的主要功能模块包括采料监控、运料监控、拌合监控、碾压监控和温湿度监控等。旨在帮助水利工程建设法人单位、施工企业、监理机构及相关政府部门，解决水利工程建设施工质量监控和工程项目管理等问题，通过信息技术和施工信息现场采集、实时传输、统一存储、科学分析和在线处理，及时生成质量监控报表和发布质量预警信息，提高水利工程建设管理和科学化、现代化和信息化，落实法人负责、监理控制、施工保证、政府监督等各项职能。因此，要满足该系统的需求，选择一种合适的架构技术至关重要。

SOA是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，服务之间通过交互和协调完成业务的整体逻辑。SOA指定了一组实体，包括服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约，这些实体详细说明了如何提供和消费服务。服务提供者提供符合契约的服务，并将他们发布到服务代理。这些服务是自我包含的、无状态的实体，可以由多个组件组成。服务代理者作为存储库、目录库或票据交换所，产生由服务提供者发布的事先定义的标准化接口，使得服务可以提供给在任何异构平台和任何用户接口使用。这种松散耦合和跨技术实现，使各服务在交互过程中无需考虑双方的内部实现细节、实现技术、以及部署在什么平台上，服务消费者只需要提出服务请求，就可以发现并调用其他的软件服务得到答案。SOA作为一种粗粒度、松耦合的架构，具有松散耦合、粗粒度服务、标准化的接口、位置和传输协议透明、服务的封装和重用、服务的互操作等几个特点。

该系统要求开发周期短，系统灵活性高等，结合SOA的特点，我们最终采用了面向服务的、基于SOA的企业应用集成。下面具体论述其应用过程。

一、服务提供者
服务提供者主要完成服务的设计、描述、定义和发布等相关工作。经过对水利行业施工工程及施工工艺的深入研究，通过查阅《胶凝砂砾石坝施工指南》等相关资料，根据企业应用集成的要求，对胶凝砂砾石坝施工质量监控系统的业务流程进行梳理；综合考虑服务粗粒度、松耦合、自包含和模块化等特点进行服务的设计。为了避免服务通信期间，信息量过大，服务之间交互过于频繁，尽量的减少了服务的数量。同时，为了保证服务自身功能的完整性，尽可能的减少服务与系统之间的通信，在胶凝砂砾石坝施工质量监控系统的分析与开发过程中，先行设计，提取出了两个必要，急需的服务便于日后集成使用，其中包括拌合监控中标准拌合比对比服务和碾压监控中的碾压轨迹生成服务。

在标准拌合比对比服务中主要实现针对现有拌合配比与标准拌合比的对比，以判断现有拌合配比是否符合标准的工作。由于胶凝砂砾石坝就地、就近取材的特性，因此在不同的水利施工工地所使用的采料也不尽相同，标准拌合比对比服务预留了标准拌合比的输入接口，以适应不同的需求。在碾压轨迹生成服务中主要实现读取定位信息绘制碾压轨迹，以监控是否存在漏碾和欠碾的情况。由于受到胶凝砂砾石坝选址和机密程度的限制，定位信息可以选择GPS或者超宽带技术，但是两种定位的方式的数据格式并不相同，因此碾压轨迹生成服务的开发中预留了两种数据格式的接口来读取定位信息。

待完成服务设计之后，服务提供者采用WSDL进行服务描述，而后再利用UDDI技术将这些服务信息发布至服务注册中心，公布查找和定位服务的方法。

二、服务注册中心和服务请求者
在胶凝砂砾石坝施工质量监控系统采用了服务注册中心。服务注册中心比不是一个必选角色，但是为了保证该系统各个模块、服务的相互独立性与松耦合，在该系统中依然保留了服务注册中心。同时，服务注册中心的存在也使得服务请求者与服务提供者之间进一步解耦。在服务注册中心包含有已发布的标准拌合比对比服务与碾压监控中的碾压轨迹生成服务的描述信息，其描述信息主要包括服务功能描述、参数描述、接口定义、信息传递等相关信息。

三、服务请求者通过WebService技术调用服务。
当服务完成发布，在服务请求者要使用已发布的服务。利用Web Service技术在监控阶段，通过服务注册中心获取拌合监控中标准拌合比对比服务的相关功能，接口，参数及其返回值等相关服务信息；之后使用Web Service技术传递服务所需的标准拌合比等相关参数，进而调用该服务相关的运算、处理和分析。利用Web Service技术在拌合监控阶段，通过服务注册中心获取实时施工数据采集处理服务的服务定义和功能，接口，参数及其返回值等相关服务信息；之后根据施工工地的具体情况选择不同的定位方式，传递服务所需相关参数，最后实时施工数据采集处理服务运行结束返回的绘制碾压轨迹坐标点同样是利用Web Service技术传递至服务请求者。服务请求者接收到碾压轨迹的坐标点后最终完成碾压轨迹的绘制工作并在界面中将其呈现出来。在这期间服务请求者无需了解服务是如何对数据进行处理和分析的。

总结

整个项目历时10个月开发，于2022年6月完成交付，到目前运行稳定。通过在水利施工工地等恶略环境下的一段时间的使用，用户普遍反馈良好。总体来讲，选用SOA有如下优势：

• 1、系统更易维护。当需求发生变化时，不需要修改提供业务服务接口，只需要调整业务服务流程或者修改操作即可。
• 2、更高的可用性。该特点是在于服务提供者和服务请求者的松散耦合关系上得以发挥与体现。 这种没有绑定在特定实现上、具有中立的接口定义的特征称为服务之间的松耦合。松耦合有两个明显的优势，一是它的灵活性，其独立于实现服务的硬件平台、操作系统和编程语言；二是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
• 3、更好的伸缩性，依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。

实践证明，SOA技术的使用大大提高了系统开发效率，节省了开发和维护成本，使得系统具有更好的开放性、易扩展性和可维护性，从项目完工后的使用效果来看，达到了预期目的。

更多内容请见： 备考系统架构设计师-核心总结索引