架构师备考论文-面向服务的架构设计与应用

找了一圈尾巴

已于 2024-11-05 14:02:54 修改

阅读量1.1k

点赞数 25

分类专栏：架构师备考文章标签：系统架构

于 2024-10-20 22:44:50 首次发布

本文链接：https://blog.csdn.net/weixin_41645817/article/details/143100563

版权

架构师备考专栏收录该内容

51 篇文章

订阅专栏

题目

摘要

正文

题目

在面向服务的架构（Service-Oriented Architecture，SOA）中，服务的概念有了延伸，泛指系统对外提供的功能集。例如，在一个大型企业内部，可能存在进销存、人事档案和财务等多个系统，在实施 SOA 后，每个系统用于提供相应的服务，财务系统作为资金运作的重要环节，也向整个企业信息化系统提供财务处理的服务，那么财务系统的开放接口可以看成是一个服务。

请围绕“面向服务的架构设计”论题，依次从以下三方面进行论述。

（1）概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。

（2）说明面向服务架构的主要协议和规范、标准，详细阐述每种协议和规范、标准的具体内容。

（3）说明面向服务架构的设计原则，详细阐述每种设计原则的具体内容。

摘要

2022年3月，我加入了公司新公交支付平台项目的研发团队，担任架构师一职，主要负责项目的整体架构设计及架构评审工作。该项目旨在全面升级现有的支付系统，以提升服务效率和用户体验。在系统架构升级方面，我们沿用了老支付系统采用的面向对象服务的架构。为了更好地支持公司中台战略，我们将老支付系统中高度可复用的组件，如ESB（企业服务总线）和EDI（数据交换平台）组件，独立出来，交由专门的团队进行优化和升级，使其成为公司级的中台服务组件。在这一架构下，支付团队的主要任务是高效复用这些中台组件，并专注于开发与公交业务紧密相关的支付、对账、清算等核心功能模块。经过半年的努力，项目于2022年9月正式上线。由于我们精心规划，新支付平台无缝兼容了老系统面向外部的粗粒度服务接口，确保了用户在平台切换过程中无任何感知，实现了平滑过渡。此次平台升级获得了公司领导和用户的高度认可。

正文

近年来，随着IT技术的快速迭代，互联网+时代推动着各行业迎来新一轮技术革命。2022年初，公司以打造新一代公交行业支付平台为目标，致力于打造一款以云原生技术为背景的，面向租户的Saas化公交支付平台。这一平台依托互联网门户，融合了云原生、大数据分析和小程序等前沿技术，旨在对现有庞大的支付系统进行深度升级。项目总投资达2000万，计划在2022年底完成新老支付平台的全面切换。我有幸在2022年3月加入该项目研发团队，并担任架构师，负责新平台的架构设计与评审工作。在系统架构升级中，我们以用户无感知切换为目标，保留了老平台的面向服务架构，并复用了其对外提供的粗粒度接口。但是在内部系统交互方面，我们引入了基于RESTful风格的HTTP交互，以及更细粒度的接口和模块，以替代原先紧密耦合的业务流程。这种微服务化的架构改造，为支付平台后续集成云原生架构提供了便利，确保了平台的弹性、容错和高可用性等关键非功能特性。项目中一个重要的转变是，我们将原本仅支持支付平台B2B业务对接的ESB（企业服务总线）和EDI（数据交换平台）组件独立出来，不再仅作为支付平台的专属组件。这些组件将转型为公司中台战略的一部分，成为可复用的服务资源，未来将为公司所有项目提供支持。这一举措不仅提升了资源利用率，也促进了公司整体技术架构的标准化和模块化。

面向服务的架构包含的主要协议和规范包括SOAP、WebService、UDDI、REST 等。其中SOAP 是一种基于XML 的通信协议，用于在网络上的不同应用程序之间进行信息交换。它定义了消息的结构和传输规则，支持多种传输协议如HTTP、SMTP 等。SOAP 的主要特点是平台无关性、语言无关性和可拓展性。WebService 是一种允许不同的应用程序通过标准的Web协议进行交互。WebService 可以使用SOAP 作为通信协议，也可以使用其它协议如REST。它提供了一种标准的方法，使得应用程序能够以松耦合的方式相互操作，从而实现跨平台、跨语言的数据交换和业务流程集成。UDDI 是一个用于描述、发布和发现Web服务的在线目录。它提供了一种标准的方法，使得企业可以发布自己的web服务，并允许其他企业查找并使用这些服务。UDDI 定义了服务的注册、查询和发布规范，使得服务提供者和服务消费者能够方便的找到对方。REST 是一种软件架构风格，用于设计网络应用程序的架构。它强调使用标准的HTTP 方法进行资源的访问和操作。

在新支付平台项目的架构设计过程中，我们继承了老支付平台的面向服务架构（SOA）的精髓，并在技术层面进行了创新和升级。其中包括原平台采用的SOAP、WebService和UDDI服务发现与消费机制，已被nacos中间件所替代。nacos作为现代的服务发现和配置管理平台，提供了更加高效和稳定的服务管理能力；在服务通信方面，我们集成了老平台的SOAP协议对接方式，但更推荐用户采用RESTful API升级对接方案。这一转变旨在构建更加灵活和轻量级的网络服务，以适应快速变化的业务需求；数据交换格式方面，我们优先使用JSON替代了XML。这一变更不仅提高了数据处理的效率，也简化了数据结构，使得接口交互更加简洁；对于新接口的定义我们则弃用了基于xmlSchema定义交互接口的方式，转而使用YAPI工具自动生成HTTP接口文档。这一做法为对接者提供了一个清晰、直观的API接口文档，极大地提升了开发效率和接口对接的准确性。

在架构设计上，我们不仅继承了老平台面向服务架构（SOA）的核心理念，而且更加严格地遵循了SOA的设计原则。在此基础上，我们着重采纳了微服务架构模式，以期为平台后续快速融入云原生技术打下坚实基础。SOA的设计原则主要包括以下几点：

提供粗粒度服务：新支付平台对外暴露的是粗粒度服务接口，如支付、数据查询和对账等。这些服务内部可能包含多个子功能，涉及复杂的系统交互和数据算法，但对于终端用户而言，这些细节是透明的。
明确定义的接口：我们提供的接口是标准化的，遵循严格的定义规则。老平台使用xmlSchema定义接口规范，并以xml报文模板形式提供。为了减轻网络通信负担，新平台在保留SOAP协议的同时，推出了统一的RESTful API接口，并采用更简洁的JSON格式进行数据交互。
自包含和模块化：新支付平台的每个服务都是独立的，不依赖于其他服务的内部实现。我们将应用程序分解为多个模块或服务，每个负责一项特定功能。采用微服务架构，我们进一步细化了模块和功能，实现了每个模块的独立开发和部署。
服务间松耦合：为实现自包含和模块化，我们采用了事件通信机制，通过消息中间件解耦服务间的依赖，从而提高了系统的灵活性和可维护性。
重用能力：我们将原本仅支持支付平台B2B业务的ESB和EDI组件独立出来，转型为公司中台战略下的可复用组件，以服务于公司所有项目。此外，微服务架构下的支付平台，每个模块都可作为独立服务对外提供，如支付服务、对账服务、数据查询服务等。

在本次项目中，我们面临了多项挑战，其中包括是否要全面采用微服务架构并实现去中心化的支付平台，以及如何在不影响用户的情况下顺利完成支付平台的切换。经过新支付平台团队深入的研究、讨论和不懈努力，我们最终确立了项目目标：作为一个B2B平台，支付平台需要依赖ESB组件来统一对外交互流程并确保系统的服务质量（QoS）。2022年9月，项目顺利上线。得益于新支付平台对老系统面向外部服务的粗粒度接口的完整保留，我们实现了平台的平滑切换，用户对此毫无察觉，得到了公司领导的高度认可。通过本次架构设计的过程，我对面向服务架构（SOA）有了更深入的理解，并且积累了宝贵的实践经验，这为我在未来的工作中奠定了坚实的基础。