一、问题背景模块耦合严重的痛苦2018年我接手了一个自研MES项目前任团队写了大概15万行C#代码但几乎所有模块都直接调用数据库一个简单的改工单状态操作牵扯到5个不同的类改一个Bug影响三个模块简直是家常便饭。那个系统上线后光是一个修改工艺路线的需求开发测试部署整整用了3周而且上线后还引入了2个新Bug。这种耦合到骨髓的架构逼得我们不得不启动重构。二、技术原理分层架构与领域驱动设计成熟MES通常采用三层/四层架构表现层Web/APP/大屏→ 业务服务层领域模型应用服务→ 数据访问层Repository模式→ 基础设施层消息队列/缓存/文件。每层只对上下层负责领域模型保持技术无关性。DDDDomain-Driven Design核心概念聚合根Aggregate Root是领域对象的统一入口比如工单WorkOrder就是一个聚合根所有对工单的操作都通过WorkOrderService进行保证聚合内的一致性约束。三、实战从三层到微服务的演进过程第一步纵向拆分。按业务领域工单、库存、SPC、设备拆分为独立服务每个服务独立数据库Database per Service。工单服务只关心工单相关逻辑不再直接读写库存表。第二步依赖倒置。数据访问层定义为接口IWorkOrderRepository基础设施层实现具体逻辑上层业务代码只依赖接口不依赖实现。这一步花了2个月但效果立竿见影——换数据库从改2周变成改2天。第三步事件驱动。用RabbitMQ做服务间解耦工单状态变更发布事件库存服务订阅事件后自动更新彻底消灭跨服务的同步调用。图1MES架构从网状耦合左到清晰分层右的演进图2MES架构重构前后关键指标对比四、完整代码服务注册与接口调用示例以下代码展示服务注册中心和依赖注入的配置以及工单服务的标准调用流程。使用反射自动扫描并注册服务实现类减少手工配置。MES架构示例服务注册中心from abc import ABC, abstractmethodfrom typing import Dict, Type, Anyimport inspect# 1. 定义仓储接口依赖倒置class IWorkOrderRepository(ABC):abstractmethoddef get_by_id(self, wo_id: str) - Dict[str, Any]: passabstractmethoddef update_status(self, wo_id: str, status: str) - bool: passabstractmethoddef list_by_state(self, state: str) - list: passclass ISpcRepository(ABC):abstractmethoddef save_control_chart(self, data: Dict) - bool: pass# 2. 服务容器简单DI容器class ServiceContainer:_services: Dict[Type, Type] {}_instances: Dict[Type, Any] {}classmethoddef register(cls, interface: Type, impl: Type):cls._services[interface] implclassmethoddef resolve(cls, interface: Type) - Any:if interface not in cls._instances:impl cls._services.get(interface)if not impl:raise ValueError(fService {interface} not registered)cls._instances[interface] impl()return cls._instances[interface]classmethoddef auto_register(cls, base_package):# 反射扫描自动将接口的实现类注册到容器for name, obj in inspect.getmembers(__import__(base_package)):if inspect.isclass(obj) and hasattr(obj, __bases__):for base in obj.__bases__:if base ! ABC and issubclass(base, ABC):cls.register(base, obj)# 3. 应用服务用例编排层class WorkOrderService:def __init__(self):self.repo ServiceContainer.resolve(IWorkOrderRepository)def change_route(self, wo_id: str, new_route: str) - Dict:wo self.repo.get_by_id(wo_id)if not wo: raise ValueError(fWO {wo_id} not found)if wo[status] not in [released, pending]:raise ValueError(fCannot change route at status {wo[status]})success self.repo.update_status(wo_id, route_changed)return {success: success, wo_id: wo_id, new_route: new_route}为什么这样写IWorkOrderRepository接口定义数据访问契约使业务层与具体数据库解耦ServiceContainer通过简单DI容器实现依赖注入支持接口替换如测试时注入MockRepoauto_register用反射自动扫描符合开闭原则新增服务无需修改注册代码。五、效果对比指标重构前重构后系统响应时间450ms85ms代码重复率38%11%月度Bug数12次2次新需求交付周期21天3天六、实施建议第一不要一开始就想做微服务。先在单体应用内做好模块化拆分Namespace/Assembly分离验证领域边界后再考虑服务化。第二API版本管理要提前规划。v1/api/workorders和v2/api/workorders的路由分离避免升级时影响旧客户端。第三引入Swagger/OpenAPI做接口文档自动化防止接口文档过时引发的扯皮。七、进阶方向KubernetesDocker容器化部署支持各服务独立扩缩容Istio服务网格实现熔断、限流、链路追踪GraphQL统一API网关解决REST API过度获取/不足获取问题低代码平台集成让工艺工程师通过配置而非代码来调整业务流程。 互动话题你们FAB的设备综合效率OEE目前大概在什么水平最大的损失来源是哪一块在实施OEE改善项目时有什么坑是特别容易踩的欢迎评论区分享觉得这篇文章有收获欢迎收藏、点赞支持您的支持是我持续输出的最大动力本文首发于blog.csdn.net/yeflashzhihui
