@Ahiok 其实只要二手质量有保障，如果单纯开发写代码，生产力还是足够的；
@520discuz 嗯嗯，之前从没在淘宝 /咸鱼 /拼多多 /转转之类的买过二手的东西，又看一些买家在评论里吐槽被骗，所以才来这里发这个贴子求可靠的方式 /渠道。😂
@opengps 嗯嗯，就是不知道可靠性怎么样，淘宝可靠性，可能稍微好点，咸鱼 /转转之类的可能就难保障。
@fox0001 哈哈，也是，V 站人手一台 mbp 。个人觉得作为开发，台式机作为主力机，或者游戏机还是挺好的。当然还有很多人喜欢 diy 东西，配主机也是一个 diy 乐趣之一。
@zhangshine Mac 质量杠杆的？中途出现过问题吗？

哈哈，大家回复太真实了，果然钞票是第一生产力工具。谢谢大家。

@Pil0tXia 非常感谢建议，今天有空再排查一下，实在不行只能试下叫上门检测的服务了。昨天后来直接重置主板也开不了机了，刚好那会内存拆下来逐条排查，但全部重新装回去也一样开不了机，平时比较懒，除灰这些一般看到温度长时间 60 以上或者系统突然卡顿才会去除灰，硅脂也有段时间（ 2 年多）没换了，但直到前天晚上电脑一直都用得挺正常的，没啥意外。不过你说的系统问题，我昨天有会儿停留在 bios 也会自动关机，感觉是操作系统的可能性比较小，除非主板驱动自动更新，但按理来说主板驱动不会自动更新的吧，一般需要手动到主板官网下载安装更新。昨天我在网上搜了下，甚至看到有人最后排查的结果是插排的零线出了问题😅，看他的描述之前似乎也是用的好好突然不行的。身边没有其他替换品供检测确实麻烦。

@zakokun 断电，能听到滴的一声就全部灯关了。有点坑，新换电源才用了不到三年😅

@HugoChao 没有配独显。补充一下：重置主板开机运行一小段时间后，会慢重启（隔大概几十秒或一分钟才重新启动），之后运行几分钟又断电，然后来来回回这样重启两三次后就开不了机了，想重新开机只能重置主板放电，但放完电后又是这样的循环。

@HugoChao 谢谢回复，550w 电源配 91w cpu ，请问一般电源使用寿命大概多久呢？

@flynaj @723X 谢谢大佬们回复，请问没有可替换的配件，该如何排查？如果是电源问题的话，就有点纳闷了，之前保修期内电源坏了，京东直接换新，这才没过 3 年又坏了？😅

另外，如果你们是第一次接手此类项目，可以把它当作一个经典的物联网基本项目（当然当前这个可能规模不大）去开发，以此作为项目类型模板，未来如果接到类似项目，十有八九也是类似技术栈+开发部署流程

@doubleTrees 微服务的作用不只是简单的为了解决并发量或者吞吐量的问题，你上面提到的“容灾”在某些场景下就是微服务的一个重要功能，单体应用出了问题，一锅端，微服务则还存在部分服务可用的可能性；

另外你说的弹性伸缩大方向也是基于微服务的解耦带来的哪里需要就扩容哪里，就比如你这个项目，最大可能需要多 pods 的服务应该是设备信息采集服务；

还有微服务扩展业务也比较敏捷，比如当你们做的差不多了，老板突然跟你们说我魔都那边还有一家工厂需要接入这个服务，这时候你们主要接入信息采集的服务就行了；

除此之外，微服务也方便快速迭代，版本管理等等。不是所有项目都适合用微服务，只不过你们这个项目包括现在很多互联网项目都比较适合用微服务开发。

@FabricPath 哈哈，其实这个道理扩大到一个国家也差别类似，比如所谓的“人口红利”，当一件事物多了，跟这件事物相关的支出成本就会相对的降低，比如一间教室里有 25 个人在听课和 50 个人在听课，除了多一些课桌椅，用一样的课室和老师，但后者却输出多一倍的人才。

😂与其说是后端问题，不如说是一个人的性格或者人品的问题。现实中，这种人各行各业都有。

个人觉得服务可能不会拆分得很复杂，但应该会很明确，比如，划分为：数据采集服务,数据聚合 /分析 /展示 /监控服务,后台管理服务等，并发量看同一时间流水线上有多少个产品在传动？同时如果对方不止一个工厂 /生产线，存不存在异地多点需要数据整合及查看服务？需不需要员工值班数据接入？进而关联到员工系统，存不存在材料 /产品的出入库环节，供应商管理环节，甚至财务管理等？

哈哈，扯远了。如果并发量不大，存储方面搞个消息队列+redis+数据库应该够了，如果并发量较大，数据存储周期长等，说不定要上个 tablestore ，但这个项目听起来大概率不需要，更像是一个 mini 版的物联网应用场景，回归微服务话题，个人觉得这种类型的项目上微服务是有必要的，即使看起来它的数据量应该不会很大，但服务划分还是挺明显的，并且微服务自身带来的问题不大可能会出现在你们这种项目上，另外甲方还要求“弹性伸缩，容灾”，采用微服务未来扩容，配合服务监控也更加顺理成章。

至于需不需要容器化部署，上面说的“弹性伸缩，容灾”几乎跟容器化部署也是绝配，你如果有成本担忧，个人建议可以先采用 docker 部署，如果后续有需要，转移到其他你说的 Docker swarm 或 k8s 也不麻烦。

@youzi0516 哈哈，最直接的用 dockerdestop,一键部署，不过如果是 window 用户，wins 自带的虚拟环境（无论是 hyper-v 还是 wsl ）太坑了,经常各种兼容性问题。

@sampeng 嗯，绝大部分需要自己选择方案部署的人，要么是想搭一个自己玩的环境，要么公司有一定规模的吧，现在大部分中小型公司线上服务基本都是云业务，不过云业务也有收费的问题，tiny 规模的公司估计也用不起。

@Nnq 个人猜测这是规模效应带来的技术成本最优化选择方案吧，5000 应该是互联网中型公司踏上大型公司的一个边界起点，之所以公司一开始主要业务都上云，是因为一开始公司规模小，业务量较低，技术人员少，云服务自带的共享性和成熟的技术方案能快速解决很多初创企业面临的技术挑战，然而随着公司规模变大，技术团队规模增加，业务量大幅提高，公司自我体系内的技术基础设施 /人员设施正在不断的完善，原有的技术挑战在现有团队里越来越能成熟应对，甚至能有多余的技术力量去解决其他问题，所以搞一套自有的技术服务不会很意外，甚至规模大了可能发展成新的业务增长点；另外人多了意味着能力和成本都增加了，必须有一个成本变现的过程，来对冲成本增加压力，降本增效，做大规模；最后达到这个规模公司，除了要考虑成本问题，还要考虑可控性问题，打个比方就像国家的粮食 /能源安全战略一样，东西我可以到你那里买，但是我必须要有一个基本的“自给自足”的底线作为我保证战略安全的需要😂

@julyclyde soga,还没用过 podman ，好用吗？相比于 docker 来说。

@aloxaf 是的，只可惜，兼容性往往是一个重要的需求，当然对于那种有一定规模的脚本来说，如果引用到第三方库之类的，一般也会在脚本里声明和检测的，所以个人觉得看需求和业务量。

@OldCarMan 这么多人使用，打少个“人”。

@cnbattle soga, 谢谢。离线部署就担心一个可选择性问题还有一个镜像安全问题。不过哈哈，这么多使用，加开源，一般问题不大。如果镜像来自 GitHub 其实还好，就担心镜像源不统一，从而导致一些仓库镜像版本的问题。

@wangxiaoaer 可以先从主要架构看起，推荐看看这下面这几个：

1.https://devopscube.com/kubernetes-architecture-explained/
2.https://kubernetes.io/docs/concepts/overview/components/ （官网）
3.https://d33wubrfki0l68.cloudfront.net/f740b41ed02348ac1aaa43732d8eff3427ae28a1/47c0e/docs/images/diagram-guide-example-3.svg

至于主要功能节点有哪些对应的方案实现，可以看这里：
https://landscape.cncf.io/
https://kubernetes.io/docs/concepts/cluster-administration/addons/

技术方案可以参考大厂实践方案（不一定要用人家的服务，看看别人的技术方案就行了，特别是一些细分领域的），比如阿里的：
https://help.aliyun.com/document_detail/126295.html

@XiLingHost soga,release 确实有点坑
@richangfan nice ，我记得 containerd 是默认 cri,掉线是不是哪里没设置好。
@wangxiaoaer 技术这玩意日新月异，大变化基本几年一个周期。
@mritd @iwdmb @cnbattle 看来 k3s 深得人心
@Cola98 nice,这个搭配有遇到过什么问题吗？
@cheng6563 “k3s 不用担心 k8s.gcr.io 墙的问题”，是默认都采用了国内镜像吗？还是它在国内有自己的镜像仓库？
@baiyi docker 对于很多像我一样的人主要是历史包袱，是从 docker 开始接触 devops 的
@fioncat 新方式 get ✔
@aaronkk 确实