架构师提升篇：分布式系统中，如何提升系统性能？

Posted 2020-10-07

在分布式系统中，平衡业务计算的压力分布，减少网络上的数据流动，是一种提升性能的手段，请看下面的例子。

1）案例背景

某“机械设计研究所”历史上在管理模式上采用传统的层次化垂直结构。但是近年来，随着用户对产品更新换代的要求越来越快、质量要求越来越高，在竞争日益剧烈、外部压力日益增大的形势下，该所在管理模型上重新定位，打破长久以来形成的垂直结构，形成一种趋向于水平集成的业务模型，使企业能更专注于自己的业务特长，在产品研发时，能更好地利用国内更先进的技术力量，以实现合作方异地协同设计。

为此需要构建一个基于互联网的符合合作方异地协同设计的信息管理平台，使得部件设计合作方能够在早期就介入产品的研发过程，及时获取产品信息和变更通知，并将相关的信息及时反馈到企业，缩短主要设计部门和合作方的沟通时间，提高合作方在新产品设计中的响应能力，实现各方共赢。这个合作方异地协同设计管理平台需要有下面一些特点：

具有开放性和可伸缩性，为实现产品的异地、异构设计提供强大支持。

需要实现业务与分布式数据源整合，

需要根据业务发展的需要，实现业务方法的重新编排

需要有效管理各合作方协同设计过程。

通过这个“合作方异地协同设计信息管理平台”，使研发工程中设计、制造、测试、维护等职能的综合协调，新产品开发更加有序和有效。

2）初步设计

本设计将面临如下挑战：

合作方的参与是不稳定的，系统需要具备可伸缩性的特点。

业务流程是不稳定的，会根据项目与合作方的特点加以改变。

合作方的数据格式具有多样性，是没有办法实施规范的。

异地合作的通信只能采用互联网，对带宽有一定限制。

合作设计信息量比较大，对性能有比较高的要求。

为了应对这些挑战，根据需求分析的要求，初步考虑系统采用面向服务的架构，该系统需要提供三个大的子服务：

项目管理与过程管理子服务（PM&PM）；

工程图档与文档管理子服务（ED&DM）；

配置管理与变更管理子服务（CM&CM）。

这三个子服务相互支持，共同完成合作方协同设计中项目管理、图档管理、版本管理以及图档修改串行化的业务要求。据此构建了初步的概念性架构。这个架构从业务层面来看，分成完全自治的三个子服务，并且让合作方的数据以服务的形式提供出来，使整个业务和数据具有很强的可变化性和可伸缩型，其初始架构关系如下图所示。

这个架构具有如下一些优点：

有利于协调不同的异构数据模型：由于合作方业务的复杂性，使得数据模型间语义与结构存在巨大差异。通过数据总线的集中管理与映射，有利于协调不同的服务领域间的异构数据模型，并且系统具有可伸缩性。

便于实现面向服务的集成（SOI）：通过使用面向服务的架构来解决集成与互操作的问题，将有利于达到根据服务契约对传统系统进行包装，创建当前系统集成所需要的新服务的目的。

有利于应对业务的变化：当合作方或者业务发生变化的时候，只需要修改“服务编排”层的业务，就可以方便的实现变更。

本系统通过一个企业服务总线（ESB）和数据总线（Data Bus）统一管理数据使用者的权限、格式转换以及其它方面的问题，以确保数据的安全性和使用上的方便性。

针对这个案例来说，在合作方位置遥远、业务非常复杂而且繁忙时，把所有的服务都集中在中央服务中心是不合适的，这样会严重影响服务的性能。为此，把服务按照不同的级别进行分布式配置, 通过合理布局来解决性能问题，如图下所示。

在这个设计方案中，服务分成两个不同的层次：

中心服务：这种服务所处的位置在全局数据中心服务器上，其维护的状态是全局性的，更多的是关注各个合作方之间的协调的业务。在需要多个分布式服务站点参与时，中心服务中的服务职责可以居中协调共同完成业务处理。这种布局的好处在于：一般来说，在同一空间（合作方）中会有大量内部相互协调的操作，而合作方之间的协调在总量上要少得多，这就可以大幅度减少应用服务的网络流量，提高系统的整体性能。

栈服务：这种服务的所谓全局状态是有区域性的。例如在同一个合作方范围内，相当多的业务处理都是在内部进行的，其全局状态也只是指的这个合作方范围内而言。我们可以把这类服务（也可能是半服务）在物理上直接置于合作方本身的数据中心，至于这个合作方数据中心提供服务的方式是采用内网还是外网并不重要（大多数情况下这种处理都是置于内网）。

本文出自 “中科院计算所培训” 博客，谢绝转载！