尤娜系统的第一次飞行中换引擎的架构垂直拆分改造

Posted 2022-03-27 编程一生

从前，有一个简单的通道系统叫尤娜……

JettyServletWebServerFactory factory = factory.setPort( // connections
threadPool.setMaxThreads( threadPool.setMinThreads( threadPool.setIdleTimeout( factory.setThreadPool(threadPool);

设置maxThreads主要是两点考虑和限制：

1>JVM设置时有Xss参数代表每个线程分配的内存资源大小。我设置为128K。这样，最大5000*128K占不到1G内存。堆内存设置为3G。内存共8G，还有足够的内存可以使用。

2>线程数多会影响上下文切换，如果CPU密集型处理可能会影响响应速度。但是目前线程主要是在等待IO，也没有很强的时效性要求，所以设置成5000问题不大。

编者按

我打算写这样一个系统故事是因为也是咱们用户群里提到《弹力设计三大纪律，怎样让稳定性KPI高大上？》这样的文章对实操帮助不大，实际中还是不知道怎么做，希望我可以出一些实战性的文章。大家希望我写什么样的文章也可以加我微信 brmayi ，注明：入群。一起进群讨论。

关于设计和架构，我是这么理解：做架构是一个在不同阶段做不同权衡的过程，任何一个决策都有其背景。首先我想把实际工作的内容做输出需要授权，也和咱们不同人遇到的问题不一定契合。而如果我能通过一个系列，这个系列的系统是慢慢孵化的，其实可以覆盖系统演进过程中的很多场景。大家可以代入性思考，这个问题自己会怎么去解决，而别人是怎么解决的，都有哪些考虑点。这样经过几次思考，慢慢强化架构意识，还可以感受到架构在其中的作用。也建议大家在读文章的时候注意里面的数据。

最后，帮好朋友做招聘。铁哥们，人超好~~

给朋友的联系方式来张大图，
也可以直接发送简历到朋友邮箱：
[e-mail]

微服务架构改造整体方案与案例分析：技术导入

本文在上一篇的基础上，介绍在向微服务架构转型过程中的第二个阶段，即技术导入阶段。在向微服务架构转型过程中，技术的导入是相对比较容易的一个阶段。

        （1）提取核心微服务

建立微服务技术体系的第一步是抽取和实现系统中的核心微服务。在移动医疗系统中，我们根据上一篇移动医疗系统子域中的服务拆分结果可以提取很多微服务，其中绝大多数都是纯粹面向业务、通过名称简单就能理解的服务，不是本书介绍的重点，这里不再展开。除了这些基础的业务服务之外，这里以系统集成服务为例介绍系统的核心微服务。

移动医疗系统在系统集成上存在两种集成服务，一种是部署在医院环境的医院集成服务，该集成服务与医院内部的各种系统进行交互；另一个是移动医疗系统自身的平台集成服务，负责从医院集成服务中获取医院数据并做相应处理和回写。集成服务的整体结构如下所示：

上图中，医院集成服务视不同医院会有不同的实现方法。而对于平台集成服务而言，其本质上体现的是一种总线思想。代表各个医院系统的医院集成服务都挂载到平台集成服务这条总线上，而来自用户的具体请求将通过总线中的路由机制路由到目标医院，并进行平台基础服务与各个医院集成服务之间的数据转换，从而完成整个业务请求的链路管理。同时，平台集成服务对于上层服务而言还起到统一入口、统一格式和系统解耦的作用，所有集成操作统一由一个入口调用，所有集成操作具有一致的入参和出参，并且实现业务逻辑与集成服务之间的分离。平台集成服务的组成结构如下图所示。

对于移动医疗系统而言，两种系统集成服务的抽取有助于更好的设计系统的整体架构，是现有系统向微服务机构改造的重要一步。其他的各种业务功能也可以根据需要做相应的操作，把原有的实现逻辑逐步提取到新的微服务中。

（2）整体架构设计

在微服务架构改造的第二阶段，微服务系统与现有系统并存，因此在整体架构设计方案上，需要考虑新的微服务架构如何与现有系统进行集成的场景。关于这种场景的对应方法可以在一篇中进行参考。在平台集成服务和医院集成服务构建完成之后，系统的整体架构表现为如下图中所示的效果。

在上图中，我们可以看到医院系统位于整体架构的底层，为系统业务开展提供原始数据。医院系统通过医院集成服务与平台集成服务进行对接，平台集成服务在图中扮演服务总线的角色。在平台集成服务的上层，新的微服务系统与现有系统将在一段时间内并存，两者同时依赖于平台集成服务。位于整体架构图上端的是各种客户端系统，一部分通过API网关与微服务进行交互，而另一部分则与现有系统进行直接交互。

（3）技术体系的建立

至此，我们已经从现有系统中分离出来了很多微服务，而且采用上图中的整体架构完成了微服务系统与现有系统之间的并存，后续通过持续的服务绞杀应该就可以把现有系统中的功能逐步迁移到新的微服务系统中。除了服务迁移，在微服务架构构建的第二阶段，我们还需要进一步考虑微服务架构实现上的一些关键要素，从而完成技术体系的建立。在本节中，我们将从服务可靠性、数据一致性和服务监控等角度来根据系统需求找到这些关键要素的实现方法。

关于服务可靠性的更多讨论我们放在后续的文章中进行展开。在移动医疗系统中，除了Spring Cloud等框架为我们提供的服务容错等内建机制，我们也综合使用了服务隔离、服务降级等策略。

在隔离技术上，移动医疗系统综合应用线程隔离、进程隔离、读写隔离等方式保证服务的稳定性。线程隔离确保当一种业务的请求处理发生问题时，不会将故障扩散到其他线程池，从而保证其他业务可用；进程隔离上讲通信模块与各个业务系统进程隔离，避免相互影响；而读写隔离则主要针对数据的读写服务隔离，我们专门设计了搜索服务用于实现读写分离。

下图展示了在移动医疗系统中基于服务分级思想所构建的部分业务体系，我们使用服务分级方法把这些业务服务分成3个级别。我们可以参考，对于这样一个用于预约挂号的移动医疗系统而言，用户登录和账户管理、预约挂号、支付等涉及到核心业务链路以及金钱方面的服务应该是优先级最高的业务功能，因为缺少这些功能，用户就肯定不会使用该款产品。而医院信息查询和历史记录分析等功能则并不属于核心业务链路，有些可以暂时关闭，有些则可以采用离线的方式进行处理，并不一定需要保证服务100%的在线率。其它的诸如服务监控、后台信息管理则属于辅助性功能，完全可以根据需要进行降级管理。

移动医疗系统中数据一致性的需求来源于以下几个方面。

• 新老系统数据耦合

移动医疗系统中，新的微服务系统与现有系统之间存在一定的数据耦合，需要考虑两个系统之间的数据同步问题。

• 分布式服务数据一致性

用户在预约挂号的同时需要进行支付操作，根据我们在第一阶段中的服务边界划分结果，预约挂号服务属于“就诊”子域，而支付服务属于“支付”子域，这就构成了典型的分布式服务之间的数据一致性问题。

• 统一化数据查询需求

对大多数业务系统而言，查询是一种高频操作且要求具备很高的灵活性，通常需要进行数据聚合。对于预约挂号场景而言，需求可能更为复杂，因为部分业务数据是通过平台集成服务从医院系统中获取，我们需要对这些来自外部的数据和系统自身的业务数据进行处理并提供统一化查询入口。

针对这些数据一致性需求，我们在向微服务架构改造的过程中，采用了如下实现策略。

• 数据复制

在中，我们介绍了数据分离的实现方式，并通过数据复制完成不同系统之间的数据同步。可以认为数据复制是共享数据库模式的一种改进，比较适合于新老系统之间存在的数据耦合场景。

• 支付服务

用户通过预约挂号入口提交订单并支付场景中，我们重点对支付服务做了数据一致性上的设计。我们采用了中介绍的可靠事件模式完成事件的发送和消费，也提供了人工干预模式以实现“兜底”方案，即当用户支付失败或出现任何异常时，我们可以通过客服人员手工进行支付或退款的方式完成业务流程闭环。另一方面，因为在预约挂号场景中，支付所产生的金额最终是转到医院系统内部，所以我们同样提供了对账服务，供双方进行定期对账并自动处理账目上的金额问题。

•  搜索服务

为了更好的对数据进行集中化处理并支持读写分离操作，在移动医疗系统向微服务架构的转变过程中，我们引入了垂直化搜索引擎机制并构建了独立的搜索服务，搜索服务的基本结构见下图。

在上图中，一方面，微服务系统可以往搜索引擎中添加数据和搜索数据，一般会有不同的服务分别负责数据的写入和数据的读取，从而实现读写分离。这点对于现有系统同样适用。另一方面，我们也看到不同数据库中的数据也可以通过数据同步的方式导入到搜索引擎中，从而供微服务或现有系统使用。

在移动医疗系统中，有一个服务需要从业务层面进行监控，这就是医院集成服务。由于网络原因或者医院本身提供的对外服务接口的不可用性，将会导致某些需要接入医院网络的服务不可用。当这样的情况发生时，为了提高用户体验，同时避免不必要的麻烦（如付费成功以后才发现医院的挂号服务不可用而引发的一系列后续繁琐的步骤），移动医疗系统需要及时发现哪些医院的服务不可，同时能明白的告知用户发生了什么。为此需要提供针对医院服务级别的监控机制。实现服务监控最常见的方法就是心跳检测，下图展示了一种心跳检测的示意图。

移动医疗系统后台通过ping-pong机制来检查医院服务的可用性，具体的检查时间可根据具体情况设置。同时把ping-pong检测的结果放入分布式缓存中，这样当平台上提供的某些服务需要和医院交互时，直接通过检查缓存就可以发现医院服务是否可用，提高了实时响应性。

    至此，开发技术导入部分介绍完毕。下一篇文章中我们将介绍向微服务架构转型过程中的最后一部分内容，即研发过程转变。