忒修斯悖论的application

至少在过去，哲学研究涉及到提出一些表面上看似无关紧要的问题。 毕竟，知道“一艘船通过更换每一个木制部件而修复后是否还是同一艘船”真的那么重要吗？ 这是普鲁塔克在《忒修斯传》中提出的问题 此后被称为忒修斯悖论。 更一般地说，它问的是“一个物体的所有组件被替换后，是否基本上仍然是同一个物体。”（忒修斯之船，维基百科）

我们可能会对微服务提出同样的问题，当将其应用于现有的单片应用时，它会试图通过用补充服务替换功能来从本质上恢复应用。 从设计上来说，功能很小（或应该很小），因此将术语“微”应用于所产生的解耦服务。 两者的差异可以从沟通的角度来看待。 在单片应用程序中，通过引用内存中的特定地址来调用函数。 在基于微服务的应用中，通过引用网络中的特定 IP 地址来调用函数（服务）。

从概念上讲，两者是相同的，只是各个功能组件的调用机制不同。 得到的图表基本上没有什么区别，但是整体式架构的“盒子”是单个服务器，而微服务的“盒子”是整个数据中心。一个使用本地寻址，另一个使用网络寻址。 每个函数的代码可能完全相同，就像忒修斯船上的木头一样。 

但其业务功能保持一致，事实上，如果我们正确分解应用，用户应该看不到两者之间明显的区别。 有人可能会说，从忒修斯船上的乘客的角度来看，两者之间没有区别。 也不应该有。

但是哲学家们倾向于深入挖掘，而且，像他们一样，我们也必须如此，因为单体应用和基于微服务的应用程序之间的差异实际上对于操作来说非常重要。

网络运营的复杂化

微服务简化了应用开发过程的许多方面，但这样做也产生了大量操作复杂性。 基于微服务的应用不同部分之间的网络连接数量必然需要相关的开销来管理所需的各种网络特性： IP 地址、VLAN、NAT 表等。 可扩展性也成为了一项挑战，甚至连Dijkstra都可能会觉得沮丧，因为微服务和负载均衡服务的放置对性能有非常实际的影响，这取决于必须遍历网络中多少个段。

突然需要额外的策略，因为适用于直接访问敏感数据源的服务的安全策略不是保护管理首选项或会话状态的另一项服务所必需的策略。 由此产生的微安全策略网络当然提供了与微服务本身相同的许多好处，即更细粒度的控制和一种优雅的简单性，但与此同时成为一场操作噩梦，因为策略必须突然随着服务而移动，无论它们出现在架构中的哪个位置。

部署也突然变得更加困难，就像从简单的箱步舞转变为更复杂的弗拉门戈舞，舞步更多，舞池（数据中心）中的动作也更多。 编排和自动化成为确保在正确的时间将所有部分放到位所必需的一致性和可预测性的必要条件。

那些负责为应用提供这些网络和安全服务的人需要认识到，无论五万英尺的视野如何，船是不一样的。 这听起来很简单；一个应用只需十个服务即可取代。 瞧！ 该应用程序已被重新创建，就像忒修斯的船一样。 但从操作角度来看，这艘船完全不一样。 新船舶的连接处（集成）完全不同，这会改变与海水产生的摩擦力（网络），并往往导致船舶航行速度变慢。

微服务仍处于新兴阶段。 他们还没有统治世界（但是），但我们必须认识到，这并不是拆掉忒修斯的船再重建那么简单。 网络和安全服务运营团队必须采取哲学家的观点而不是乘客（用户）的观点，因为对网络和安全的影响非常非常不同。