企业级微服务架构设计实践需要从宏观到微观层面的思考,主要分为业务架构、应用架构、技术架构和开发设计方法论。
要建设企业的信息系统首先要明确系统的需求,而要制定系统需求则首先要明确系统对于企业来讲要解决哪些问题,哪些参与对象以及如何参与,然后再考虑如何使用信息化手段来优化提升生产力,这就是业务架构需要解决的问题。
主要明确业务操作的业务主体,业务功能,和业务边界,这里是对业务功能的理解与设想。业务领域的理解需要使用领域驱动设计的思想做战略层面的设计,明确各领域的职责,划分好领域的边界。
领域的划分并没有一个统一的标准,是根据企业的实际情况综合利弊而得出的,主要的原则是高内聚低耦合,将此业务领域强关联的业务包括进来,将其它领域的业务剥离出去。对于一些模棱两可的业务归属,需要认真对待,分析业务结果的本质再去判断如何归属。如果出现太多的类似业务存在,需要考虑之前的业务领域的识别是否正确。
业务领域功能设计是一个持续的过程,是应该有一个能力地图的,是有对此领域所提供的能力有一个长线的规划。只有这样才能当某项业务操作流程出现的时候才清楚如何去设计功能归属。
业务流程形象的表述就是多个业务操作之间业务结果的传递。从整个业务系统的宏观层面上看,业务结果是在各业务领域间传递的,业务流程的设计需要保持业务结果的独立性和复用性,对传递方式要求规范性和通用性。从业务领域的微观层面上看,业务结果是在各业务操作间传递的,业务流程的设计需要保持简便性。
这部分是业务架构的价值所在,深刻认识业务领域作用,透视众多业务流程,理清业务操作本质,把握业务发展轨迹,形成业务建设原则,构建业务架构模型。
业务的抽象需要深刻理解业务操作背后的业务逻辑,切勿简单地去实现现有的需求,充分考虑业务模型的通用性和多变性,去适配未来业务的不断发展。需求细节的变化是多种多样的,但为了实现目标的述求基础上是不变的,应从此出发,站在业务解决问题的角度出发来建立业务模型。
应用架构需要定义整个产品有哪些业务系统,它们是如何集成的,内部是怎么划分的,它们是怎么联系起来的。
主要包括两种方式,一种是阻断式的同步方式,强关联操作;另一种是触发式的异步方式,是弱关联操作。
用于流程操作中必需的步骤,强一致性,主要使用远程接口调用。此种方式要求调用与被调用方都必须及时响应,反应迅速,系统耦合度较高,执行流程较复杂。在系统设计中尽量减少此类方式的调用,必须调用时需要关注被调用方的响应时间。
用于流程操作中本应用不关心的其它操作,应用只需要把消息发出,需要使用此消息的应用进行订阅,主要使用消息中间件。此种方式使用的是异步方式,不要求订阅方及时响应,系统耦合度低,默认情况下没有一致性要求,可实现最终一致性。在系统设计中尽量使用此类方式,以便提高整个系统的响应速度和结构的稳定性。
行为标识的传输:包括行为对象的类型,行为对象的状态以及行为对象的标识代码
{"code":"XP0000000000000D6001","notice":"PRODUCT","noticeAction":"MODIFY"}
这种方式传输的内容简单,量小,格式统一,订阅方接收到消息后需要再次通过远程接口查询行为对象,此处结果可以制定化,但增加了额外的调用开销且需要保持双方通讯稳定性
行为对象的传输:传递的内容是整个行为对象,而行为的识别可由消息路由去配置
{"code":"XP0000000000000D6001","name":"XXX","statue":"MODIFY","id":"XXX" ...}
这种方式传输的内容体积较大,格式不一致,订阅方接收到消息后可直接得到行为对象,无须再次请求接口,但行为对象的格式是固定的,无法制定化,为了适配更多的订阅方需求往往需要把整个对象传递出去,传输消耗大,如果消息在消息服务器中堆积较多可能严重影响服务器性能。
两种形式有不一样的应用场景,可根据需要选择。一般情况下如果行为对象本身内容较小,为了避免二次请求可以直接传输行为对象,如果行为对象内容较大,可只传输行为标识。