负载均衡不在发送请求到这台服务器上,负载均衡认为该服务器状态不正常,智能硬件到底是什么一个产品既有软件部分又有硬件部分是不是就算智能硬件呢,硬件中电子技术和结构开发往往不会同时都懂,公司通常所说的智能不是简单的软件控制硬件,作为智能硬件产品经理,就是智能硬件产品经理了,但是这并不是一个好的解决方案。
智能硬件到底是什么
一个产品既有软件部分又有硬件部分是不是就算智能硬件呢？答案当然是否定的，很多软硬兼修的小伙伴会有误解，以为自己既懂软件知识又了解硬件开发制造流程，就可以进入智能硬件行业，就是智能硬件产品经理了。硬件里面分电子和结构，其实真正想入行智能硬件是要非常懂电子技术这块的。
公司通常所说的智能不是简单的软件控制硬件，而是指智能传感、万物互联、人机能够交互。所以还必须要了解电子传感、通讯协议这方面的知识。
比如说一款产品是家庭医疗类的机器人，它有个控制平板属于软件，有个机身属于硬件。机身可提供能量场、远红外理疗等功能，平板用来控制理疗功能的输出，比如强度、时间、温度等参数，然后平板APP中有自己的商城、会员体系等模块，有自己独立的后台。那么这算是一款智能硬件产品吗？个人觉得这只能算是一款软硬件结合的伪智能产品，没有满足智能传感、万物互联、人机交互中的任何一点。-硬件
那么判断真智能硬件产品的一个基本点就是人机交互，能够通过语音指令、手势动作、视频来对产品进行控制，产品也能通过传感器或者采集接收数据来主动给用户反馈，这样形成一个基本的交流。作为智能硬件产品经理，是要熟悉这个过程是怎么实现的。简单来说，有三个要素。-硬件
第一， 软件+后台控制。用户可以通过软件对PCB传送指令数据，可以是物理端口传送指令，比如将平板和机身接线连接，指令直接走信号线；也可以是无线通信，近距离可以通过蓝牙、射频直接对产品控制，远距离的话需要将指令发送给云端服务器，服务器再将指令传送给的PCB板的通讯模组。-硬件
第二， 硬件电子技术。产品通过传感器或者通信模组来收集数据，再通过单片机对数据进行处理从端口对整个产品发出指令。
第三， 无线通信功能。无线通信是连接软件和硬件的桥梁。同样，判断是否是智能硬件产品也可以看有没有无线通信这块，有不一定是，但没有一定不是。
那么，软硬件兼修的小伙伴，想入行智能硬件，硬件中电子技术和结构开发往往不会同时都懂，因为这两块很偏技术，不像软件产品经理入门比较简单，我们需要怎么平衡呢？
首先，电子这块决定你是否懂智能硬件这行的实现原理，结构这块决定你是否懂智能硬件产品实现制造的过程。电子的硬件产品经理更了解实现的技术原理，结构的产品经理更了解整个产品的开发过程。
所以，智能硬件产品经理是一个对综合素质要求很高的岗位。软件、电子、结构，必须同时具备至少两个方向的经验，且对另一个熟悉了解。有点像玄幻修真小说中的主角，同时修行几个方向，最后成为集大成者。
以上，就是个人对智能硬件产品的一些想法，希望大家一起交流
怎样提升电脑硬件的配置
电脑升级无非就几大块，CPU，显卡，内存，硬盘。
内存、硬盘
这里的升级优先级还要看自己的具体需求，比如，如果你想要多开那就多加一些内存，如果你想做服务器就多加硬盘等等。
内存建议购买符合自己主机的最高频率的产品，并且最好组成双通道。有条件可以直接达到上限。
硬盘升级成固态硬盘，这是必须的。升级固态硬盘后，能够极大地提高用户体验。建议尽快升级，早用早享受。哪怕是一个老破电脑也会立马换新颜。
CPU、显卡
至于CPU和显卡，这个就要区分你的终端类型了。如果是笔记本电脑，一般这两项都是集成到主板上了，一般人升级不了。但如果是台式机，那么只要主板支持，我们也可以进行相应的升级。
如果你是一个游戏要玩家，而且对游戏的画质和帧数都有比较高的要求，升级显卡还是非常有必要的。游戏优先选择N卡。
至于CPU，其实还好，一般的CPU对于日常来说都是够用的。
以上希望对你有帮助，欢迎交流沟通。
要做负载均衡，代码要满足什么条件
当我们的程序只部署一套，不再能满足访问量（调用量）的时候，最简单的横向扩容的方法就是部署多套应用环境，负载均衡将用户（客户端）的访问平均地分配到每台服务器上，这样就可以利用多台机器的资源，增加系统的负载能力。-硬件
那么要做负载均衡，对我们的系统有什么要求么？或者说我们的代码需要做什么改造么？
大部分时候我们的代码是不需要改造的，但是也要注意这么几点。
我们的服务最好是无状态的，也就是每一次的调用，不依赖于前一次的调用结果，如果前后有依赖，则需要后面的请求携带着前一次请求的结果，作为参数进行访问。
除非负载均衡开启了会话保持，或者通过一些负载均衡路由策略，让同一个 IP 的请求始终路由到同一台服务器上，但是这并不是一个好的解决方案。
通常我们需要保持服务的无状态性，如果需要做权限认证的话，建议采用 Token 或使用 Redis 做 Session 共享（推荐使用 Token）。
还有一点，可能不一定必须的，不过我觉得也是个不错的方案，供大家参考。
假如我们有两台应用服务器 A 和 B，前面挂一台负载均衡，当我们需要做应用升级的话，通常可以怎么做？
通常的办法是停掉服务器 A，这时候负载均衡会监控到这台服务器 A 已经无法使用了（比如监控到端口消失），再来的请求会发送给服务器 B；
对服务器 A 升级并启动，负载均衡监控到 A 恢复了，会将请求发送给 A 和 B；
对服务器 B 做相同的操作。
这样看似没有问题，因为在服务器升级的时候，负载均衡不在发送请求到这台服务器上；但是大家仔细想一想这个过程，如果在停服务器的那一刻，已经有请求进来了并进行处理，但是还没有返回，这时候停掉服务器，会导致这部分请求发生异常，那么这个问题如何解决呢？这就需要对程序进行一定的改造了。-硬件
应用提供一个接口，返回一个静态变量的值，只要 true 或 false 两个状态；
负载均衡不再监控端口是否消失，而是监控剪口返回的状态，返回 true 表示应用正常，false 或没有返回表示不正常；
每次停服务之前，通过接口修改当前应用静态变量的值为 false；
负载均衡认为该服务器状态不正常，将不再发送请求到这台服务器上；
等待几十秒，这段时间相当于等待当前请求都处理并返回，再停止服务。
“停止服务时，不再接受新的请求，等现有请求都处理完成后再真正停止服务”，这只是一个笨办法，想要避免以上问题还有更好的办法，并且对代码没有侵入性；有些中间件本身提供了类似的功能，我们只需执行对应的停止服务的命令即可；或者需要在代码中添加监听类，当收到 kill 信号的时候，拒绝新的请求，等待一段时间，再结束程序等等。-硬件
