论面向服务的架构设计

20250315-创作

题目

请围绕“论面向服务的架构设计”论题，依次从以下三个方面进行论述。
1、概要叙述你参与分析设计的软件项目以及你在其中所承担的主要工作。
2、论面向服务的架构设计基于Web service的面向服务架构实现过程，SOA具有哪些特征，支撑软件功能重用。
3、具体阐述你参与的软件项目是如何以面向服务的架构为指导实施的，在实施过程中遇到哪些问题，是如何解决的。

摘要

    我司自主研发的某省预约挂号系统以后简称预约挂号系统，该系统集众多功能于一体，旨提高系统服务效率和患者体验，由于系统用户量的逐年递增，系统面临性能和可用性的严峻挑战。为了让系统能够持续稳定的运行，我司决定在2023年3月进行预约挂号系统的的全面升级工作，计划一年，投资800万。我担任该项目的系统架构设计师，主要工作是系统架构的整体设计。目前预约挂号系统迫切需要提高性能和可用性，我们选择了面向服务的架构设计，其接口、协议统一等特点也对架构的重用性友好。我们通过对系统需求分析、设计和实施等3个大阶段，完成了对预约挂号系统的全面升级工作，系统的性能和可用性得到了显著提高，获得了项目组成员和领导高度认可。

背景

    随着信息化时代的到来，各大医院纷纷拥抱线上系统，我司为顺应时代潮流，开发了一款功能全面的预约挂号系统，该系统涵盖了预约挂号、体检预约、报告查询和名医抢号等核心功能。然而随着用户基数的逐年攀升，系统面临着前所未有的性能瓶颈和可用性的挑战。为了保证系统的持续稳定运行，我司毅然决定2023年3月开始对预约挂号系统进行全面升级工作，计划一年，投资800万。我担任系统架构设计师，主要工作涵盖了系统架构的整体设计、技术栈精准选型和核心阶段的评审工作。面向服务的架构设计有协助企业集成、数据共享、打破信息孤岛、对外接口统一、服务化和构件粒度等特点，非常适合预约挂号系统的升级工作。我们经过了分析、设计和实施阶段，完美升级了预约挂号系统。也正因使用了面向服务的架构设计，系统经受住了千万级的用户量和名医抢号时期的性能要求，得到了领导和组员的高度认可。

理论 

    面向服务的架构设计有构件为粒度的服务化、接口统一、协助企业集成、资源共享和打破信息孤岛等特点。接下来描述一下具有哪些特征，以及如何支撑软件功能重用的。
    1、粗粒度：面向服务架构设计是以构件为基础，解耦构件，还有独立部署、易扩展等优点。对于预约挂号系统而言，其业务、功能繁杂，需要对其以业务的垂直领域进行划分和开发构件，且构件需满足单一职责，只提供自己业务领域内的服务。
    2、接口统一：面向服务架构设计要求对外开放的接口统一，方便构件之间通信，还有沟通方式简单、通用的通信协议等优点。预约挂号系统业务庞大，拆分业务将产生多构件，且构件需要多副本部署以保证预约挂号系统的性能和可用性，所以接口规范必须保证构件之间统一交互。
    3、服务化：面向服务架构设计要求服务化的模式，架构中存在服务消费者和服务提供者，构件需以提供服务为原则，尽量少的与其他构件耦合。预约挂号系统中业务模块众多、划分结构复杂，需要明确各个构件的职责，以方便开发理解和运维部署。
    4、协助企业集成：面向服务的架构设计结构统一，包括UDDI、WSDL、SOAP、Web service这四个结构，企业开发系统时只需满足架构的设计方式即可得到最终系统，易理解、流程简单。
    5、资源共享和打破信息孤岛：面向服务的架构设计以资源共享的方式设计，公司各部门之间或者公司与公司之间，所拥有的服务都可相互通信，解决信息孤岛的问题。就我们项目而言，各个构件之间需要通信，需要以共享自己的信息，方便消费者请求服务提供者，让整个系统连接起来。
    6、面向服务架构设计中粗粒度、接口统一和资源共享等特点很好的满足了构件重用。在预约挂号系统中，公共服务的服务发现构件和支付服务，这些通用服务被我们放入构件库，方便以后系统重用。

实践 

    预约挂号系统通过面向服务架构设计的实施过程分为三个大步骤：分析、设计和实施阶段。

    分析阶段。预约挂号系统已经运行多年，系统架构是单体应用架构，所有业务都耦合在一起，系统的性能和可用性随着时间的推移也越来越差，所以需要结合系统的性能和可用性两大特点完成系统的设计。我们通过分析业务场景得出用例图，通过分析用例图发现，业务有医院、用户、订单、支付和三方医院，业务流量都集中在医院、订单和支付业务中，所以可对原有业务进行拆分，通过扩展服务器的方式分担单台服务器的流量解决性能问题，通过多副本部署解决每块业务的可用性问题。该阶段我们还定义了接口规范、开发手册，得到了需求规格说明书。

    设计阶段。该阶段我们按照面向服务架构分为了四大块分别是Web service、UDDI、WSDL和SOAP。
    1、Web service模块，我们通过用例图对业务进行拆分，划分为医院对应机构服务、用户服务、预约挂号对应订单服务、支付服务、公共组件对应公共服务和三方医院对接对应三方服务。通过使用通信图描述了预约挂号系统中各个构件的交互关系，由此我们发现服务较多沟通复杂，我们采用了微服务分层的策略，将业务服务下沉，新生成了聚合器微服务，要求底层业务服务只提供自己业务领域的业务数据，不与其他服务沟通，业务逻辑都在聚合器微服务中处理，与外部交互也一样。针对业务的质量场景机构服务、订单服务、支付服务的业务访问较为频繁，需要根据用户量进行负载均衡和多副本策略部署服务，以减轻请求的压力和服务的可用性，其他业务服务需两副本保证性能和高可用。
     2、UDDI模块，服务之间沟通也需要统一，面向服务的架构设计中提供了服务发现的几种场景，其中服务注册表和服务总线最为经典，我们选择了服务注册表的方式，因为公司对Nacos、Eureka比较熟悉。预约挂号系统所涉及的所有微服务统一注册到注册中心服务中，消费者通过从注册中心获取服务的信息，从而完成对服务提供者的请求。
     3、WSDL和SOAP，虽然有服务注册中心，但服务注册的信息还是要统一，方便消费者解析服务的信息。我们定义了WSDL的内容，包含了接口的请求、响应参数格式、位置信息和所使用的SOAP协议等。在定义SOAP时，我们设计了把服务器分为内外网，内网通过HTTP协议通信，外网则使用HTTPS的安全访问方式通信。
     4、最后，我们通过活动图描述构件中各业务场景的行为，通过状态图描述用户预约挂号场景中状态的流转等等得到了精准的设计模型。

    实施阶段。该阶段我们进行了服务构件获取组装、测试、运行维护等3个步骤。
     1、根据设计模型，我们对老系统的代码进行了拆分工作，把系统分为了机构服务、用户服务、订单服务、公共中心和支付服务等底座基础服务提供业务数据。中间层系统分为聚合器服务和三方服务等能与其他服务沟通，由于聚合器服务为新产生，需要进行开发，公共中心的服务发现替换成组件库的Nacos构件，其他微服务构件都可以从老系统中拆分出来。
     2、得到最终系统的各个构件后，接下来就是对各个组件进行单元测试，发现拆分过程中的问题。单元测试完成后把各个构件按照部署图连接起来部署到测试服务器中进行集成测试，而后在进行系统测试，每个阶段出问题都会进行评审和阶段迭代。
     3、最后上线预发系统，走金丝雀的发布模式运行一段时间，然后上线运行。

结尾 

    得益于面向服务架构的设计的使用，在2024年2月初正式开发完成了预约挂号系统，3月1日正式上线，精心推广了一个月，又收获了大量的用户，且系统经受住了千万级用户的考验，特别是在名医抢号环节面对高并发的情况下，轻松应对数万级别的用户请求，显著的提高了预约挂号系统的性能和可用性，得到了项目组成员的赞扬和领导的高度认可。然而在开发初期，组员对业务模型的错误理解，严重阻碍了项目进程的推进，针对这一问题，我们迅速作出反应，通过项目组间人员的灵活调配，完美的解决了这一短板。未来，我们准备将老数据库中的数据迁移至新库，经过此次项目成功实施，我们对数据库迁移策略充满信息，并将以更高的要求和标准实施方案。对我个人而言，这次项目的实施是一次不可多得的机会，我的技能和经验得到了显著的提升。

总结经验：
    1.在设计阶段没有描述如何重用。
    2.重用过程：获取构件、创建构件库、使用构件。
    3.Web service：重用支付构件、用户构件。
    4.UDDI：重用redis、Eureka、Nacos。
    5.中间件：重用redis、ES。
    6.新开发的构件放入构件库。