抛弃与修复原理在经济管理中的应用吗

Posted 2023-04-03

参考技术A 最近在学习TRIZ理论，感觉40条发明原理很实用，具有很好的启示作用，特摘录下来，共各位同人参阅：

序 号

名称

序 号

名称

序 号

名称

序 号

名称

No.01

分割

No.11

预补偿

No.21

紧急行动

No.31

多孔材料

No.02

分离

No.12

等势性

No.22

变有害为有益

No.32

改变颜色

No.03

局部质量

No.13

反向

No.23

反馈

No.33

同质性

No.04

不对称

No.14

曲面化

No.24

中介物

No.34

抛弃与修复

No.05

合并

No.15

动态化

No.25

自服务

No.35

参数变化

No.06

多用性

No.16

未达到或超过的作用

No.26

复制

No.36

状态变化

No.07

套装

No.17

维数变化

No.27

低成本、不耐用的物体

代替昂贵、耐用的物体

No.37

热膨胀

No.08

重量补偿

No.18

振动

No.28

机械系统的替代

No.38

加速强氧化

No.09

预加反作用

No.19

周期性作用

No.29

气动与液压

No.39

惰性环境

No.10

预操作

No.20

有效作用的连续性

No.30

柔性壳体或薄膜

No.40

复合材料

No.01分割： （1）将一个物体分成相互独立的部分；（2）使物体分成容易组装及拆卸的部分；（3）增加物体相互独立部分的程度。

No.02分离： （1）将一个物体分中的干“扰部”分分离出去； （2）将物体中的关键部分挑选或分离出来。

No.03局部质量：（1）将物体或外部环境的均匀结构变成不均匀结构； （2）使组成物体的不同部分完成不同的功能；

（3）使组成物体的每一部分都最大限度的发挥作用。

No.04不对称： （1）将物体的形状有对称变为不对称； （2）如果物体是不对称的，增加其不对称的程度。

No.05合并： （1）在空间上将相似的物体连接在一起，使其完成并行的操作； （2）在时间上合并相似或相连的操作。

No.06多用性： 使一个物体能完成多项功能，可以减少原设计中完成这些功能多个物体的数量。

No.07套装： （1）将一个物体放在第二个物体中，将第二个物体放在第三个物体中，可进行下去；

（2）使一个物体穿过另一物体的空腔。

No.08重量补偿：（1）用另一个能提升力的物体补偿第一个物体的重量；

（2）通过与环境相互作用产生空气动力或液体动力的方法补偿第一个物体的重量。

No.09预加反作用：（1）预先施加反作用；（2）如果一个物体处于或将处于受拉伸状态，预选增加压力。

No.10预操作： （1）在操作开始前，是物体局部或全部产生所需的变化；

（2）预先对物体进行特殊安排，使其在时间上有准备或已处于易操作的位置。

No.11预补偿： 采用预先准备好的应急措施补偿物体相对较低的可靠性。

No.12等势性： （1）改变工作条件，使物体不需要被升高或降低； （2）等势原则原理：在势能场中，避免物体位置的改变。

No.13反向： （1）将一个问题说明中所规定的操作改为相反的操作；

（2）是物体中的运动部分静止，静止部分运动； （3）使一个物体的位置颠倒。

No.14曲面化： （1）将直线或平面部分用曲线或曲面代替，立体形用球形代替；

（2）采用辊、球、螺旋； （3）用旋转运动代替直线运动，采用离心力。

No.15动态化： （1）使一个物体或其环境在操作的每一个阶段自动调整，以达到优化的性能；

（2）划分一个物体成具有相互关系的元件，元件之间可以改变相对位置；

（3）如果一个物体是静止的，使之变为运动的或可改变的。

No.16未达到或超过的作用：如果100%达到所希望的效果是困难的，那么稍微未达到或稍微超过预期的效果将大大简化问题。

No.17维数变化：（1）将一维空间中运动或静止的物体变成在二维空间中运动或静止的物体，在二维空间中物体变成在三维空间中物体；（2）将物体用多层排列代替单层排列；（3）使物体倾斜或改变其方向；（4）使用给定表面的反面。

No.18振动： （1）使物体处于振动状态； （2）如果振动存在，增加其频率，甚至可以增加到超声；

（3）使用共振频率； （4）使用电振动代替机械振动； （5）使超声振动与电磁场耦合。

No.19周期性作用： （1）用周期运动或脉动代替连续运动； （2）对周期性的运动改变其运动频率；

（3）在两个无脉动的运动之间增加脉动。

No.20有效作用的连续性： （1）不停顿地工作，物体的所有部件都应满负荷地工作；（2）消除运动过程中的中间间歇；

（3）用旋转运动代替往复运动。

No.21紧急行动：以最快的速度完成有害的操作。

No.22变有害为有益： （1）利用有害因素，特别是对环境有害的因素，获得有益的结果；

（2）通过与另一种有害因素结合消除一种有害因素； （3）加大一种有害因素的程度使其不再有害。

No.23反馈： （1）引入反馈以改善工程或动作； （2）如果反馈已经存在，改变反馈控制信号的大小或灵敏度。

No.24中介物 （1）使用中介物传递某一物体或某一种中间过程； （2）将一容易移动的物体与另一物体暂时结合。

No.25自服务： （1）使一物体通过附加功能产生自己服务于自己的功能；

（2）利用废弃的材料、能量与物质产生自己服务于自己的功能。

No.26复制： （1）用简单的、低廉的复制品代替复杂的、昂贵的、易碎的或不易操作的物体；

（2）用光学拷贝或图像代替物体本身，可以放大或缩小图像；

（3）如果已经使用了可见光拷贝，用红外线或紫外线代替。

No.27低成本、不耐用的物体代替昂贵、耐用的物体：

用一些低成本物体代替昂贵物体，用一些不耐用物体代替耐用物体，有关特性作折中处理。

No.28机械系统的替代：（1）用视觉、听觉、嗅觉系统代替部分机械系统；（2）用电场、磁场及电磁场完成与物体的相互作用；

（3）将固定场变为移动场，将静态场变为动态场，将随机场变为确定场；（4）将铁磁粒子用于场的作用之中。

No.29气动与液压：物体的固体零部件可用气体或液压零部件代替，将气体或液体用于膨胀或减振。

No.30柔性壳体或薄膜： （1）使用柔性壳体或薄膜代替传统结构；（2）使用柔性壳体或薄膜将物体与环境隔离。

No.31多孔材料：（1）使物体多空或通过插入、涂层等增加多空元素；（2）如果物体已是多空的，用这些空引入有用的物质或功能。

No.32改变颜色：（1）改变物体或环境的颜色；（2）改变一个物体的透明度或改变某一过程的可视性；

（3）采用有颜色的添加物，使不易观察到的物体或过程被观察到；（4）如果以增加了颜色添加物，则采用发光的轨迹。

No.33同质性： 采用相同或相似的物质制造与某种物体相互作用的物体。

No.34抛弃与修复：（1）当一个物体完成了其功能或变得无用时，抛弃或修改该物体中的一个元件；

（2）立即修复一个物体中所损耗的部分。

No.35参数变化：（1）改变物体的物理状态，即使物体在气态、液态、固态之间变化；

（2）改变物体的浓度或粘度；（3）改变物体的柔性；（4）改变温度。

No.36状态变化：在物体状态变化过程中实现某种效应。

No.37热膨胀： （1）利用物体的热膨胀或热收缩性质；（2）使用具有不同热膨胀系数的材料。

No.38加速强氧化：使氧化从一个级别转变到另一级别，如从环境气体到充满氧气，从充满氧气到纯氧气，从纯痒到离子氧。

No.39惰性环境：（1）用惰性环境代替通常环境；（2）让一个过程在真空中发生。

No.40复合材料：将材质单一的材料改为复合材料。

Docker容器可以使用容器平台管理自动重启实现自修复吗？

 

容器的自修复功能是经常被吹嘘的。因为容器是衣服，人躺下了，衣服也躺下了，容器平台能够马上发现人躺下了，于是可以迅速将人重新唤醒工作。

而虚拟机是房子，人躺下了，房子还站着。因而虚拟机管理平台不知道里面的人能不能工作，所以容器挂了会被自动重启，而虚拟机里面的应用挂了，只要虚拟机不挂，很可能没人知道。

这些说法都没错，但是人们慢慢发现了另外的场景，就是容器里面的应用没有挂，所以容器看起来还启动着，但是应用已经不工作没有反应了。

 

当启动容器的时候，虽然容器的状态起来了，但是里面的应用还需要一段时间才能提供服务。

所以针对这种场景，容器平台会提供对于容器里面应用的 health check，不光看容器在不在，还要看里面的应用能不能用，如果不能，可自动重启。

 

一旦引入了 health check，和虚拟机的差别也不大了，因为有了 health check，虚拟机也能看里面的应用是否工作了，不工作也可以重启应用。

还有就是容器的启动速度快，秒级启动，如果能够自动重启修复，那就是秒级修复，所以应用更加高可用。

 

这个观点当然不正确，应用的高可用性和重启的速度没有直接关系。高可用性一定要通过多个副本来实现，在任何一个挂掉之后，不能通过这一个应用快速重启来解决，而是应该靠挂掉的期间，其他的副本马上把任务接过来进行解决。

虚拟机和容器都可以有多副本，在有多个副本的情况下，重启是 1 秒还是 20 秒，就没那么重要了，重要的是挂掉的这段时间内，程序做了什么。

 

如果程序做的是无关紧要的操作，那么挂了 20 秒，也没啥关系；如果程序正在进行一个交易和支付，那挂掉 1 秒也不行，也必须能够修复回来。

所以应用的高可用性要靠应用层的重试，幂等去解决，而不应该靠基础设施层重启的快不快来解决。

 

对于无状态服务，在做好重试的机制的情况下，通过自动重启修复是没有问题的，因为无状态的服务不会保存非常重要的操作。

对于有状态服务，容器的重启不但不是推荐的，而且可能是灾难的开始。

一个服务有状态，例如数据库，在高并发场景下，一旦挂了，哪怕只有 1 秒，我们必须要弄清楚这 1 秒都发生了什么，哪些数据保存了，哪些数据丢了，而不能盲目的重启，否则很可能会造成数据的不一致性，后期修都没法修。

 

例如高频交易下的数据库挂了，按说 DBA 应该严格审核丢了哪些数据，而不是在 DBA 不知情的情况下，盲目的重启了，DBA 还觉得没什么事情发生，最终很久才能发现问题。

所以容器是比较适合部署无状态服务的，随便重启都可以。

而容器部署有状态容器不是不能，而是要非常小心，甚至都是不推荐的。

虽然很多的容器平台都支持有状态容器，然而平台往往解决不了数据问题，除非你对容器里面的应用非常非常熟悉。

当容器挂了，你能够准确的知道丢了哪些，哪些要紧，哪些不要紧，而且要写代码处理这些情况，然后才能支持重启。

 

网易这面的数据库在主备同步的情况下，是通过修改 MySQL 源代码，保证主备之间数据完全同步，才敢在主挂了的情况下，备自动切换主。

而宣传有状态容器的自动重启，对于服务客户来讲是很不经济的行为，因为客户往往没有那么清楚应用的逻辑，甚至应用都是买的。

 

如果使用有状态容器，任凭自动重启，最终客户发现数据丢失的时候，还是会怪到你的头上。

所以有状态的服务自动重启不是不可用，需要足够专业才行。