这是一个创建于 393 天前的主题，其中的信息可能已经有所发展或是发生改变。
Boss 接了一个工厂的数字孪生项目，工厂主要是做铸件加工的，项目大概情况如下
甲方需要看到整个生产流程中工件的位置移动，操作等，以及根据调度算法（已有专家）的结果安排生产。
目前规划如下：
plc 将场景内各种传感器信息收集发送到数据收集的服务端。
目前遇到的问题是：
整个项目设计下来大概一共是 50 张表，大概是 7 个模块
甲方要求高可用（自有机房），弹性伸缩，容灾，开发这边想做微服务架构
是否需要微服务？
是否有必要上 k8s?或者 k3s?或者 Docker swarm ？
架构上是否有一些建议？
甲方需要看到整个生产流程中工件的位置移动，操作等，以及根据调度算法（已有专家）的结果安排生产。
目前规划如下：
plc 将场景内各种传感器信息收集发送到数据收集的服务端。
目前遇到的问题是：
整个项目设计下来大概一共是 50 张表，大概是 7 个模块
甲方要求高可用（自有机房），弹性伸缩，容灾，开发这边想做微服务架构
是否需要微服务？
是否有必要上 k8s?或者 k3s?或者 Docker swarm ？
架构上是否有一些建议？
 |
1
dacapoday 2023-03-30 23:28:36 +08:00
如果预期有多种不同的数据采集方式，每种方式流量存在动态变化，且未来需要新增更多种类的数据来源，可以考虑采用微服务。
另外也可以基于开发流程来考虑，RD 与 Servie 为 1:1 或 1:n 的关系，避免多人同时负责同一模块 (前提 已完成数据表建模，确定了依赖关系和边界)。最大化降低沟通成本，提高开发速度。 |
 |
2
v2eb 2023-03-30 23:53:27 +08:00
项目更新或软件配置修改导致错误, 硬盘或内存损坏, 电线被偷或被剪断, 突然停电, 火灾
不知道定义的高可用是什么😲 |
|
3
v2eb 2023-03-31 00:18:23 +08:00
|
 |
4
OldCarMan 2023-03-31 03:18:00 +08:00
个人觉得服务可能不会拆分得很复杂，但应该会很明确，比如，划分为：数据采集服务,数据聚合 /分析 /展示 /监控服务,后台管理服务等，并发量看同一时间流水线上有多少个产品在传动？同时如果对方不止一个工厂 /生产线，存不存在异地多点需要数据整合及查看服务？需不需要员工值班数据接入？进而关联到员工系统，存不存在材料 /产品的出入库环节，供应商管理环节，甚至财务管理等？
哈哈，扯远了。如果并发量不大，存储方面搞个消息队列+redis+数据库应该够了，如果并发量较大，数据存储周期长等，说不定要上个 tablestore ，但这个项目听起来大概率不需要，更像是一个 mini 版的物联网应用场景，回归微服务话题，个人觉得这种类型的项目上微服务是有必要的，即使看起来它的数据量应该不会很大，但服务划分还是挺明显的，并且微服务自身带来的问题不大可能会出现在你们这种项目上，另外甲方还要求“弹性伸缩，容灾”，采用微服务未来扩容，配合服务监控也更加顺理成章。 至于需不需要容器化部署，上面说的“弹性伸缩，容灾”几乎跟容器化部署也是绝配，你如果有成本担忧，个人建议可以先采用 docker 部署，如果后续有需要，转移到其他你说的 Docker swarm 或 k8s 也不麻烦。 |
 |
5
fengleiyidao 2023-03-31 08:09:49 +08:00
放在前几年，这东西肯定会叫“工业 IoT"，现在都改叫"数字孪生"了😂
|
 |
6
uilvn 2023-03-31 08:33:29 +08:00
工业数字孪生有非常成熟的解决方案了，比如石化盈科的 Promace
如果你是老板，建议直接二手转包出去，赚差价不比自己开发到吐血强 |
 |
7
HunterPan 2023-03-31 08:43:40 +08:00
这个老板原因花这么多钱嘛 哈哈
|
 |
8
WindProtect 2023-03-31 09:07:26 +08:00
@fengleiyidao 数字孪生是更早的吧。十年前我刚上学的时候老师就教过这概念，倒是 IoT 是后面出来工作才见得多。
|
 |
9
documentzhangx66 2023-03-31 09:20:11 +08:00
自有机房弹性伸缩？？？？？？
建议你们给甲方，仔细普及一下，啥叫弹性伸缩。不然概念的理解出现偏差，后期项目验收时，肯定会出现问题的。 |
 |
10
doubleTrees OP |
|
11
OldCarMan 2023-03-31 11:12:33 +08:00
@doubleTrees 微服务的作用不只是简单的为了解决并发量或者吞吐量的问题，你上面提到的“容灾”在某些场景下就是微服务的一个重要功能，单体应用出了问题，一锅端，微服务则还存在部分服务可用的可能性；
另外你说的弹性伸缩大方向也是基于微服务的解耦带来的哪里需要就扩容哪里，就比如你这个项目，最大可能需要多 pods 的服务应该是设备信息采集服务； 还有微服务扩展业务也比较敏捷，比如当你们做的差不多了，老板突然跟你们说我魔都那边还有一家工厂需要接入这个服务，这时候你们主要接入信息采集的服务就行了； 除此之外，微服务也方便快速迭代，版本管理等等。不是所有项目都适合用微服务，只不过你们这个项目包括现在很多互联网项目都比较适合用微服务开发。 |
|
12
OldCarMan 2023-03-31 11:24:35 +08:00
另外，如果你们是第一次接手此类项目，可以把它当作一个经典的物联网基本项目（当然当前这个可能规模不大）去开发，以此作为项目类型模板，未来如果接到类似项目，十有八九也是类似技术栈+开发部署流程
|
Select Language