马屁股决定航天飞机的设计？

Posted 2023-04-08 机器学习Zero

路径依赖

• 1. 4英尺8.5英寸
• 2. 路径依赖
• 3. 启示

1. 4英尺8.5英寸

航天飞机燃料箱的火箭推进器，宽度为都是4英尺8.5英寸。

• 为什么会采用这个标准呢？因为需要使用火车运送火箭推进器，因此火箭助推器的宽度就和铁轨的宽度一样。
• 那为什么铁轨的宽度是这个数字呢？因为早期铁路设计者是设计电车的，而电车车轮之间的距离是4英尺8.5英寸。
• 那为什么电车的轮距是这个数字呢？因为设计电车的人以前是建造马车的，所以电车的车轮距离就沿用了马车的车轮距离。
• 那为什么马车的轮距是这个数字呢？因为4英尺8.5英寸是英国马路上的车轮印子之间的宽度。如果马车不按照这个标准建造，由于车辙痕迹很深，它的轮子就会很容易在路上被撞坏。
• 那为什么车辙的距离是这个数字呢？因为包括英国在内的整个欧洲的道路都是由古罗马人为了军队的行军而铺设的，而之所以会是这个距离，是因为古罗马人的战车宽度是4英尺8.5英寸。
• 那为什么古罗马战车的宽度是这个数字呢？因为一辆战车需要两匹马来牵引，而两匹马屁股的宽度就是4英尺8.5英寸。

因此，航天飞机火箭助推器的宽度，取决于两匹马屁股的宽度。

2. 路径依赖

这个结论体现了经济学上的一个概念，称为“路径依赖”（Path-Dependence）。路径依赖是指人类社会中的技术演进或制度变迁均有类似于物理学中的惯性，即一旦进入某一路径（无论是“好”还是“坏”）就可能对这种路径产生依赖。

人们一旦做了某种选择，就好比走上了一条不归之路，惯性的力量以及既得利益约束会使这一选择不断自我强化，并让你轻易走不出去。美国经济学家道格拉斯·诺斯，使用“路径依赖”理论成功地阐释了经济制度的演进，于1993年获得诺贝尔经济学奖。

制度变及技术演进，都存在着报酬递增和自我强化机制。这种机制使制度变迁一旦走上了某一条路径，它的既定方向会在以后的发展中得到自我强化。所以，“人们过去作出的选择决定了他们可能的选择”。

沿着既定的路径，经济和政治制度的变迁可能进入良性循环的轨道，迅速优化；也可能顺着原来的错误路径往下滑；弄得不好，它还会被锁定在某种无效率的状态之下。一旦进入了锁定状态，要脱身而出就会变得十分困难，往往需要借助外部效应，引入外生变量或依靠政权的变化，才能实现对原有方向的扭转。

• 对组织而言，一种制度形成后，会形成某个既得利益集团，出于对利益和所能付出的成本的考虑，他们对制度有强烈的要求，只有巩固和强化现有制度才能保障他们继续获得利益，哪怕新制度对全局更有效率。
• 对个人而言，一旦人们做出选择以后会不断地投入精力、金钱及各种物资，如果哪天发现自己选择的道路不合适也不会轻易改变，因为这样会使得自己在前期的巨大投入变得一文不值，这在经济学上叫“沉没成本”。

沉没成本是路径依赖的主要原因。

3. 启示

从个人选择，企业发展，再到国家制度的变迁，“路径依赖“理论可以解释很多现象，让我们更好的认识理解这个世界，帮助我们做出更好的选择。

比如，有时候需要勇气和魄力，打破路径依赖，敢于创新，敢于放弃，主动破局，赢得主动。

关于Dubbo

前序：

这段时间一直在西安往返出差，每次坐飞机都坐的我屁股蛋子生疼，看了看纵横商旅app上的飞行时间，大约在天上待了42个小时。而且我早年看过坐飞机的那一部《死神来了》电影，这导致每次飞机跌波的时候我心里是有一丝丝余悸的，心悬着，毕竟脚不着地的感觉。话不多说，好人一生平安吧。

中序：

是这样的，公司有个项目是采购的西安一家软件公司的sass产品，我司私有化部署并且在全国范围内下属幼儿园已经运行了三年。由于需求不满足现有业务的发展，打算在其基础上进行定制化需求开发。于是乎我便和其他两位素未谋面的同事前往西安与乙方联合开发。

前期由于需求尚在讨论阶段，而且来回掰扯，迟迟定不下来。把领导急坏了，怎么你们还没开始开发啊，要抓紧了。可是做项目就是这样，需求不定，搬砖人也不敢盲目开工，对于搬砖人来说，需求终归要先说断，后不乱。这样也不存在大量返工的情况，至少搬砖的心情是愉悦的，心里有底。一句话的需求坑最多，因为它可能是个黑洞，进去了再出来也是一身黑了吧。所以等到需求封板，已经是一两个礼拜之后了吧。

照这架势，我也觉得项目至少得延期，乙方同事说怕是要做到明年三月份也做不完。可是船到桥头自然直，项目分成两个阶段，招生阶段功能1月15号已经上线，也已经在各大幼儿园使用起来了，家长可以通过小程序扫描招生二维码进行意向报名并缴费，在园在班阶段相关功能1月7号也将上线，目前已经在测试阶段。

后序：

关于Dubbo:

dubbo早在2017年底就重启维护了，并且Dubbo 在国内拥有着巨大的用户群，其实Dubbo 并不是要提供一整套微服务解决方案，而是定位在 RPC 、服务扩展与治理方面：

本身分布式架构可以承受更大规模的并发流量，所以大家希望在使用 Dubbo 的同时享受SpringCloud的生态，出现各种各样的整合方案，但是因为服务中心的不同，各种整合方案并不是那么自然。直到SpringCloud Alibaba 这个项目出现，由官方提供了Nacos服务注册中心后，才将这个问题完美的解决。并且提供了Dubbo和SpringCloud整合的方案，姑且称之为Dubbo SpringCloud。

SpringCloud为什么需要RPC？

在SpringCloud构建的微服务系统中，大多数的开发者使用都是官方提供的Feign组件来进行内部服务通信，这种声明式的HTTP客户端使用起来非常的简洁、方便、优雅，但是有一点，在使用Feign消费服务的时候，相比较Dubbo这种RPC框架而言，性能堪忧。

虽然说在微服务架构中，会将按业务划分的微服务独立去部署，并且运行在各自的进程中。微服务之间的通信更加倾向于使用HTTP这种简答的通信机制，大多数情况都会使用REST API。这种通信方式非常的简洁高效，并且和开发平台、语言无关，但是通常情况下，HTTP并不会开启KeepAlive功能，即当前连接为短连接，短连接的缺点是每次请求都需要建立TCP连接，这使得其效率变的相当低下。

对外部提供REST API服务是一件非常好的事情，但是如果内部调用也是使用HTTP调用方式，就会显得显得性能低下，Spring Cloud默认使用的Feign组件进行内部服务调用就是使用的HTTP协议进行调用，这时，我们如果内部服务使用RPC调用，对外使用REST API，将会是一个非常不错的选择，恰巧，Dubbo和SpringCloud的组合给了我们这种实现方式。

Dubbo要解决的需求（摘抄自dubbo官方文档）：

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

以上是 Dubbo 最基本的几个需求。

dubbo架构简图：

到这里就大概了解了dubbo的确是个好东西，这是dubbo的第一篇->初探，后续应该会继续写吧...