关于“服务网格”和分布式系统软件复杂性 - Matt Klein

19-06-25 banq
                   

我们的行业倾向于迷恋Google,Netflix等公司的技术架构。他们已经构建了一些令人印象深刻的技术来解决罕见的扩展问题,所以这并不奇怪。但是,您的公司/系统是否需要类似的解决方案?可能不是...

对服务网格、K8S和其他原生技术的强烈抵制是合理的质疑,厂商供应商的营销和强大技术思想领先导致较小的组织没有看到森林,而只看到他们的树木,并采用过于复杂的解决方案实现他们的实际需求。

如果你有一个新的/小的分布式系统,可从下面开始选择:

 1. 单体Monolith SOA

 2. 没有类型的语言/ API,比较狂野的

 3. 单一大代码库Monorepo

 4. FaaS

 5. MongoDB?Web规模

 -1. 服务网格

 -2. K8S

 

专注于创造客户价值,尽可能保持事物的简单和无聊。但是,如果你有幸找到成功,你的开发团队将会成长,你最终将转向SOA。

无类型的语言和API将不再那么高效。 - 那个monorepo?甚至我都不会从它开始, 今天最先进的FaaS不会在可靠性,视觉障碍,网络等方面问题,特别是当你开始感受SoA网络/视力障碍时。

此时,“服务网格”将以某种方式为您服务,因为必须解决障碍,负载平衡,服务发现,一致超时,重试等问题,或者您的SoA是DOA。

你全部使用Java吗?Finagle或Hystrix是不错的选择。你是一个Go全栈吗?试试像Micro这样的东西。你是多语言吗?您可以将资源投入到每种语言的自定义库中,也可以使用边车,必须找到解决方案。

如果你采取服务网格和K8s,你需要承担的网络复杂性,因为无论供应商/会议告诉你什么,都会有痛苦,没有任何东西是免费的。

总是这样吗?我不这么认为。我实际上认为我们正处于一个桥梁时期,普通工程师必须直接与Envoy和K8S等技术进行互动才能在SoA取得成功。

我坚信,在10年的时间内,FaaS是所有人都会与之互动的。如果我是开发人员,我想提供以下代码:

- 来自数据库的读写R/W

- 调用API

- 队列/deques作业

就是这样。其他一切都是噪音。

在这种情况下,我认为在一个云足以运行Google 的FaaS世界,K8S,Envoy,“服务网格”等技术将无处不在,但几乎没有人会知道它们在哪里。这些都是管道。没有人关心管道

 

                   

1