生鲜加工项目架构方案取舍

项目复杂度:

• 高可用-需要:服务不能动不动挂掉,集群部署,监控告警这些都需要.

• 高性能-不需要:因为该生鲜加工系统不是那种ToC系统,比如秒杀系统,不会要求高性能.

• 高扩展-需要:高扩展是指的业务的高扩展,随着业务功能的增多以及需求的变更,后续修改的地方要少,影响范围要小.

• 低成本-需要:比如:现在就是复用供应链的数据库,生鲜加工项目的数据库不是单独建新的库,生鲜加工的表都是建在供应链数据库中(订补货业务也是共用的供应链的数据库).之所以这么做就是考虑低成本.

服务拆分

• 方案1：基于成本的质量属性考虑

  • 优点:成本低,简单.

  • 缺点：扩展性不好,所有业务逻辑基本耦合在这1个服务,这个服务有问题,基本上生鲜加工所有功能都不可用.

 

• 方案2:基本业务功能拆分服务

  • 优点:职责分明,业务功能解耦,业务拓展性好.

  • 缺点:拆分太细,调用链路变长,资源成本增加,增加运维维护部署复杂度.

 

• 方案3:基于业务流程拆分服务

  • 优点:提高灵活性和可维护性

  • 缺点:服务拆分太细,链路太长,资源成本及运维维护成本过高.

• 最终方案:基于业务功能+成本+可靠性

  • 将财务服务合并到"后台服务"中,减少不必要的资源投入,而且后续财务的功能迭代不频繁.

  • 将领料退料按照业务操作,把生成领料/退料任务功能放到"后台服务",领料/退料的领取,完结动作放到PDA服务中.

  • PDA和智能秤不能合并到1个服务,因为智能称和PDA都是核心业务操作,要保证这两者的操作都可靠,不能因为PDA功能有问题而影响到智能称的操作.所以两者要拆分开独立部署.

架构演进:

• 业务背景:

  • 随着业务功能的增多,发现有部分功能可以复用,比如:领料,退料功能，这两个功能会生成对应的领料/退料任务,而且对于这些任务,涉及到多个服务的调用,比如PDA要查询,领取,完结任务,后台服务要生成任务,这些服务都会涉及到任务的使用,所以后面的架构想独立1个任务中心服务,对于任务的操作需要统一经过任务中心.任务中心提供统一的api接口.

• 优点：

• • 这个任务中心服务封装了各种任务化业务场景的变化，提高了任务功能的可复用性及可拓展性.

• 缺点:

  • 拆成任务中心后,调用链路会变长,服务器成本和运维成本会增加,而且现有的任务化场景不是特别多,业务规模暂时不是特别大.

• 结论:

  • 基于成本+调用链路+业务规模考虑,现在暂时不考虑任务中心的拆分.