微服务下技术实践思考业务与应用架构设计

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

一、架构" title="业务架构">业务架构思考

要建设企业的信息系统首先要明确系统的需求，而要制定系统需求则首先要明确系统对于企业来讲要解决哪些问题，哪些参与对象以及如何参与，然后再考虑如何使用信息化手段来优化提升生产力，这就是业务架构需要解决的问题。

1. 业务领域识别

主要明确业务操作的业务主体，业务功能，和业务边界，这里是对业务功能的理解与设想。业务领域的理解需要使用领域驱动设计的思想做战略层面的设计，明确各领域的职责，划分好领域的边界。

领域的划分并没有一个统一的标准，是根据企业的实际情况综合利弊而得出的，主要的原则是高内聚低耦合，将此业务领域强关联的业务包括进来，将其它领域的业务剥离出去。对于一些模棱两可的业务归属，需要认真对待，分析业务结果的本质再去判断如何归属。如果出现太多的类似业务存在，需要考虑之前的业务领域的识别是否正确。

业务领域功能设计是一个持续的过程，是应该有一个能力地图的，是有对此领域所提供的能力有一个长线的规划。只有这样才能当某项业务操作流程出现的时候才清楚如何去设计功能归属。

2. 业务流程梳理

业务流程形象的表述就是多个业务操作之间业务结果的传递。从整个业务系统的宏观层面上看，业务结果是在各业务领域间传递的，业务流程的设计需要保持业务结果的独立性和复用性，对传递方式要求规范性和通用性。从业务领域的微观层面上看，业务结果是在各业务操作间传递的，业务流程的设计需要保持简便性。

3. 业务模型建设

这部分是业务架构的价值所在，深刻认识业务领域作用，透视众多业务流程，理清业务操作本质，把握业务发展轨迹，形成业务建设原则，构建业务架构模型。

业务的抽象需要深刻理解业务操作背后的业务逻辑，切勿简单地去实现现有的需求，充分考虑业务模型的通用性和多变性，去适配未来业务的不断发展。需求细节的变化是多种多样的，但为了实现目标的述求基础上是不变的，应从此出发，站在业务解决问题的角度出发来建立业务模型。

二、应用架构思考

应用架构需要定义整个产品有哪些业务系统，它们是如何集成的，内部是怎么划分的，它们是怎么联系起来的。

1.应用划分

  • 业务需求 ：应用的划分很大程度来源于业务架构的分析，是业务模型的结果显现。

  • 技术现状 ：考虑到实际技术的支撑情况，需要去平衡性能与稳定性的要求。一些应用服务的特点是业务简单，响应容忍度低，受众面广，稳定性高；一些应用服务的特点是业务复杂，响应容忍度高，受众面小，有接受一定的故障率。

  • 物理环境 ：在一些复杂的网络环境中，可能会出现一些服务需要和不同网络环境中的其它服务进行交互的需求，从而导致应用的拆分。

  • 安全要求 ：应用服务中所涉及的安全等级有可能不一样，有一些是对外的服务，有一些是对内的API，它们的安全认证方式也不一样。

  • 系统迭代 ：由于系统的不断升级可能会出现不兼容的情况，由于人员的更迭老版本维护起来越来越吃力，由于技术架构的革新出现不适配的情况

2. 应用交互

主要包括两种方式，一种是阻断式的同步方式，强关联操作；另一种是触发式的异步方式，是弱关联操作。

2.1 强关联交互

用于流程操作中必需的步骤，强一致性，主要使用远程接口调用。此种方式要求调用与被调用方都必须及时响应，反应迅速，系统耦合度较高，执行流程较复杂。在系统设计中尽量减少此类方式的调用，必须调用时需要关注被调用方的响应时间。

2.2 弱关联交互

用于流程操作中本应用不关心的其它操作，应用只需要把消息发出，需要使用此消息的应用进行订阅，主要使用消息中间件。此种方式使用的是异步方式，不要求订阅方及时响应，系统耦合度低，默认情况下没有一致性要求，可实现最终一致性。在系统设计中尽量使用此类方式，以便提高整个系统的响应速度和结构的稳定性。

2.3 消息传输的形式

行为标识的传输 ：包括行为对象的类型，行为对象的状态以及行为对象的标识代码

 {"code":"XP0000000000000D6001","notice":"PRODUCT","noticeAction":"MODIFY"}

这种方式传输的内容简单，量小，格式统一，订阅方接收到消息后需要再次通过远程接口查询行为对象，此处结果可以制定化，但增加了额外的调用开销且需要保持双方通讯稳定性

行为对象的传输 ：传递的内容是整个行为对象，而行为的识别可由消息路由去配置

 {"code":"XP0000000000000D6001","name":"XXX","statue":"MODIFY","id":"XXX" ...}

这种方式传输的内容体积较大，格式不一致，订阅方接收到消息后可直接得到行为对象，无须再次请求接口，但行为对象的格式是固定的，无法制定化，为了适配更多的订阅方需求往往需要把整个对象传递出去，传输消耗大，如果消息在消息服务器中堆积较多可能严重影响服务器性能。

两种形式有不一样的应用场景，可根据需要选择。一般情况下如果行为对象本身内容较小，为了避免二次请求可以直接传输行为对象，如果行为对象内容较大，可只传输行为标识。

以上是 微服务下技术实践思考业务与应用架构设计 的全部内容， 来源链接： utcz.com/z/515300.html

回到顶部